OpenVPN OpenVPN routing probléma
#1
Elküldve: 2008. 12. 02. 14:49
Segítségetek kérném a következőben. Már csomó doksit elolvastam, de nem jöttem ra.....
Szóval:
Van egy OpenVPN szerver (debian) egy A hálózaton (192.168.2.0/24) egy router (mikrotik - 192.168.2.1) mögött egy DSL kapcsolat végén. Ez megy is frankón, kliensek bejelentkeznek, látnak minden belső IP címet. Van viszont egy B hálózat (192.168.1.0/24) egy OpenVPN klienssel (debian), ami egyben router is, meg samba server, meg minden. Ez egy kábelmodemes internetre csatlakozik. A szerver mint vpn kliens fel is tud csatlakozni a VPN szerverre, a szerverről lehet is pingetni minden A hálózatban lévő gépet. Viszont ennek a szervernek a kliensei (akik dhcp-vel kapnak IP-t) már nem tudják pingetni az A hálózatban lévő gépek egyikét sem! Pedig ezt szeretném elérni. Feltételezem, hogy a VPN szerver konfigja jó, mert akkor nem lehetne sem az egyéb (wines) felcsatlakozó kliensekről, sem pedig B háló szerveréről pingetni A-ba bármit is. B háló szerverébe FORWARD be van kapcsolva, routing táblázatba benne van a 192.168.2.0/24-es haló a vpn-es IP átjáróval....
Remélem precízen leirtam...igyekeztem röviden!
Valami ötlet rá? Routing tábla? Nat-olás?
Köszönöm!
Golya
#2
Elküldve: 2008. 12. 02. 14:52
Our shadows taller than our soul.
“It is often said that before you die your life passes before your eyes. It is in fact true. It's called living.”
#3
Elküldve: 2008. 12. 02. 15:20
"Ez van bazdmeg, ha nem tetszik, el lehet menni."
#4
Elküldve: 2008. 12. 02. 15:21
Idézet: bogdan - Dátum: 2008. dec. 2., kedd - 15:20
Vagy NATnak kell lenni, vagy routeolasnak visszafele.
Our shadows taller than our soul.
“It is often said that before you die your life passes before your eyes. It is in fact true. It's called living.”
#5
Elküldve: 2008. 12. 02. 15:32
de nem szolok ennel tobbet bele: nem csinaltam meg ilyet. csak elvi megallapitas volt, lehet, hogy hibas.
"Ez van bazdmeg, ha nem tetszik, el lehet menni."
#6
Elküldve: 2008. 12. 02. 15:35
Idézet: bogdan - Dátum: 2008. dec. 2., kedd - 15:32
de nem szolok ennel tobbet bele: nem csinaltam meg ilyet. csak elvi megallapitas volt, lehet, hogy hibas.
Az VPN ilyen szempontbol csak egy plusz csatorna a ket halozat kozott.
Termeszetesen ha B halozat routere A halozat fele natolja a klienseit, akkor A halozat felol nem lesznek cimezhetoek B gepei, vagyis szerver jellegu szolgaltatast nem fog tudni nyujtani egy host B-bol A-nak.
Our shadows taller than our soul.
“It is often said that before you die your life passes before your eyes. It is in fact true. It's called living.”
#7
Elküldve: 2008. 12. 02. 15:43
"Ez van bazdmeg, ha nem tetszik, el lehet menni."
#8
Elküldve: 2008. 12. 02. 18:24
Idézet: bogdan - Dátum: 2008. dec. 2., kedd - 15:43
Csak tenyleg egyertelmusites vegett: azert a NAT mogul pingelni lehetne

Our shadows taller than our soul.
“It is often said that before you die your life passes before your eyes. It is in fact true. It's called living.”
#9
Elküldve: 2008. 12. 02. 20:46
"Ez van bazdmeg, ha nem tetszik, el lehet menni."
#10
Elküldve: 2008. 12. 02. 21:40
Idézet: bogdan - Dátum: 2008. dec. 2., kedd - 20:46
Nem

(B hostok) --- (B szerver) -[--VPN--]-(A VPN gw) --- (A hostok)
A bal oldal nem tudja pingetni a jobbat, holott ha B szerver natolja B halozatot, akkor a jobb nem tudna pingetni a balt.
De varjuk meg a topicnyitot

Our shadows taller than our soul.
“It is often said that before you die your life passes before your eyes. It is in fact true. It's called living.”
#11
Elküldve: 2008. 12. 05. 11:23
Idézet: kroozo - Dátum: 2008. dec. 2., kedd - 20:40

(B hostok) --- (B szerver) -[--VPN--]-(A VPN gw) --- (A hostok)
A bal oldal nem tudja pingetni a jobbat, holott ha B szerver natolja B halozatot, akkor a jobb nem tudna pingetni a balt.
De varjuk meg a topicnyitot

B halozat szervere pingeti az A halozat NAT-olt gepeit is, mint egy normal kliens.
tehat:
(/24)
(A hostok) --- (A VPN szerver - 192.168.2.5)
\ (10.1.1.1) (192.168.1.1, 10.1.1.2) (/24)
(A mikrotik router - 192.168.2.1) - [-VPN-] -> <- [-VPN-] - (B VPN kliens, router) - (B hostok)
A cel csak a B hostokrol az A hostok elerese, visszafele nem kell. Es a B vpn kliens, routerrol megy is a ping A barmely hostjara.
tehat B routerrol ping 192.168.2.1 ok, 192.168.2.5 ok. B hostok barmelyikerol ping nem jon. tcpdump: B router NAt-olt ether interfeszen elveszik. nem megy ki tun0-ra, vagy a net feloli ether-re.
B host routing tabla:
labor:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 10.1.1.5 255.255.255.0 UG 0 0 0 tun0
localnet * 255.255.255.0 U 0 0 0 eth0
84.3.182.0 * 255.255.254.0 U 0 0 0 eth1
default catv5403B601.po 0.0.0.0 UG 0 0 0 eth1
labor:~#
otlet?
#12
Elküldve: 2008. 12. 05. 11:38
Idézet: golya23 - Dátum: 2008. dec. 5., péntek - 10:23
tehat:
(/24)
(A hostok) --- (A VPN szerver - 192.168.2.5)
\ (10.1.1.1) (192.168.1.1, 10.1.1.2) (/24)
(A mikrotik router - 192.168.2.1) - [-VPN-] -> <- [-VPN-] - (B VPN kliens, router) - (B hostok)
A cel csak a B hostokrol az A hostok elerese, visszafele nem kell. Es a B vpn kliens, routerrol megy is a ping A barmely hostjara.
tehat B routerrol ping 192.168.2.1 ok, 192.168.2.5 ok. B hostok barmelyikerol ping nem jon. tcpdump: B router NAt-olt ether interfeszen elveszik. nem megy ki tun0-ra, vagy a net feloli ether-re.
B host routing tabla:
labor:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 10.1.1.5 255.255.255.0 UG 0 0 0 tun0
localnet * 255.255.255.0 U 0 0 0 eth0
84.3.182.0 * 255.255.254.0 U 0 0 0 eth1
default catv5403B601.po 0.0.0.0 UG 0 0 0 eth1
labor:~#
otlet?
...kozben probaltam....
tcpdump: tun0-ra kimegy a csomag, es ott elveszik. nem tudja, h. az ut a 10.1.1.1-en keresztul vezet....
koszi!
#13
Elküldve: 2008. 12. 05. 11:48
Our shadows taller than our soul.
“It is often said that before you die your life passes before your eyes. It is in fact true. It's called living.”
#14
Elküldve: 2008. 12. 07. 12:43
OpenVPN-nel akadtam el egy kicsit. Hogyan működik ez a kulcsos dolog? Tehát eddig sikeresen belőttem a szervert, meg mindent, de végtelenül zavar az, hogy nem tudom, hogy pl. hogyan kell eltávolítani egy certificat-ot, vagyis hogyan tudok egy usert törölni.
Google-zom ezerrel, de mindenhol csak az van, hogyan kell új kulcsokat létreozni, de hogy törölni hogy kell, arról semmi szó nem esik.
#15
Elküldve: 2008. 12. 07. 20:13
Kiadod a source vars parancsot, majd utána:
./revoke-full demo
Ahol demo a tanúsítvány/user neve, amit vissza akarsz vonni.
#16
Elküldve: 2008. 12. 08. 01:21
Idézet: Mono - Dátum: 2008. dec. 7., vasárnap - 20:13
Kiadod a source vars parancsot, majd utána:
./revoke-full demo
Ahol demo a tanúsítvány/user neve, amit vissza akarsz vonni.
Köszi, ezt kipróbálom. Tehát akkor ezek szerint jól vettem észre, hogy a kulcsok noha a fájlrendszerben vannak, valahonnan máshonnan tudja, hogy milyen kliens kulcsok vannak. Mert csak a szerver kulcsok miatt sírt, mikor azt átneveztem, a kliensek miatt nem, és ugyanúgy működött a program. (gondolom adatbázisban vannak akkor).
Na most ma ketten próbáltunk ugyanazzal a kliens kulccsal csatlakozni a szerverhez, és ha jól gyanítom, akkor egy kulccsal egyszerre csak egy ember tudott bent lenni. Erre van valmi megoldás? Vagy ez csak ideiglenes hiba volt? Mert nekem fontos lenne, hogy többen be tudjanak lépni ugyanazzal a kulccsal.
Amúgy tényleg köszi a helpet. Asszem régebben postfixban már segítettél nekem. Jó ez a fórum, mert a hup-on bármit kérdezel, sosem válaszolnak, csak beszólnak. Szóval köszi.
#17
Elküldve: 2008. 12. 08. 07:03

Ezt már én is ki akartam próbálni, mert szerettem volna, ha így is működik, azaz egyszerre egy kulcs egy ember. De ennek örülök is, hogy így van.
Nálam pont az volt a szempont, hogy minden ember számára külön kulcs legyen. Ekkor ha vállalati környezetben megszakad a kapcsolat a VPN klienst használó emberrel (elmegy, kiteszik, stb.), akkor visszavona a kulcsát biztosan nem tud majd már illetéktelenül bejönni, a többieket viszont nem érinti ez. - Szemben a hagyományos "egyjelszavas" VPN-nel, mert ez esetben kb. annyit lehetne tenni, hogy megváltoztatom az egy szem jelszót és egy ember miatt 28 másiknak kell megtanulniuk az új passwordot. Emellett, hogy felhasználóként külön kulcs van, könnyen is lehet rájuk szűrni a logokban, nekem ez is fontos volt. Hadd ne nyomozgassam már az otthoni asztali gépének a MAC címe alapján, hogy mikor ki volt bent...
#18
Elküldve: 2008. 12. 08. 11:56
Idézet: Mono - Dátum: 2008. dec. 8., hétfő - 7:03

Ezt már én is ki akartam próbálni, mert szerettem volna, ha így is működik, azaz egyszerre egy kulcs egy ember. De ennek örülök is, hogy így van.
Nálam pont az volt a szempont, hogy minden ember számára külön kulcs legyen. Ekkor ha vállalati környezetben megszakad a kapcsolat a VPN klienst használó emberrel (elmegy, kiteszik, stb.), akkor visszavona a kulcsát biztosan nem tud majd már illetéktelenül bejönni, a többieket viszont nem érinti ez. - Szemben a hagyományos "egyjelszavas" VPN-nel, mert ez esetben kb. annyit lehetne tenni, hogy megváltoztatom az egy szem jelszót és egy ember miatt 28 másiknak kell megtanulniuk az új passwordot. Emellett, hogy felhasználóként külön kulcs van, könnyen is lehet rájuk szűrni a logokban, nekem ez is fontos volt. Hadd ne nyomozgassam már az otthoni asztali gépének a MAC címe alapján, hogy mikor ki volt bent...
Persze. Elvileg az lenne logikus, hogy mindenkinek külön kulcsa van. Viszont nálam ez most egyáltalán nem fontos. A lényeg, hogy egy olyan OpenVPN telepítőt csináltam, amibe intergráltam már a kulcsokat. Szóval ha hálózatban akarunk játszani valakivel, akkor elküldöm az exe-t, és megyis, nem kell ezen felül másolgatni fájlokat, plusz szerver oldalon sincs beállítanivaló. Lényegében ismerősökről van szó, tehát kitiltás nem lenne. Mindenesetre majd letesztelem két ünnep között ezt a több kulcsos megoldást, és visszaírok, hogy alapértelmezésben mi a helyzet ezzel. De a tegnapi tapasztalatom alapján egy kulccsal egyszerre csak egy ember lehet bent.