Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Filip 20. 01. 2019, 21:11:33
-
(B)
Mam OpenVPN server 10.0.10.253
jeho tun0 interface je na siti 10.1.10.0/24
lokalni PC dejme tomu je (B)10.0.10.200
--
(A)
druha strana je OpenVPN Client fungujici jako gateway na siti tun0 10.1.0.0/24 a eth0 10.0.0.52
OpenVPN client gateway ma nastaveno pouze
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
a net.ipv4.ip_forward=1.
lokalni pc na teto strane treba (A)10.0.0.100 a ma nastavenou gateway pro 10.0.10.0/24 na 10.0.0.52
Ted k problemu. Vsechno tohle se spoji a vse funguje.
PING z (A)10.0.0.100 na (A)10.0.10.200 -> funguje
Vzdalena plocha z (A)10.0.0.100 na (B)10.0.10.200 -> funguje
Pokud necham pingat vyse uvedene a restartuji OpenVPN Client gateway, ping ma timeout, ale za chvili by mel naskocit. Nenaskoci, presto ze vzdalena plocha do te site a na ten PC(B) bezvadne funguje. Pomuze jedine prestat pingat, par minut pockat a pak ten ping zase funguje. Moc to nechapu. Nesetkal se nekdo s timhle ? Pripadne jak to odhalit.
TCPDump na A je videt IMCP req na tun0 ale na druhou stranu uz se nedostane.
po vypnuti pingani a pockani par minut a znovu ping uz vse jede, na obojim tun0 je req/reply a na vzdalene strane je taky vse videt pri tcpdump.
-
(B)
Mam OpenVPN server 10.0.10.253
jeho tun0 interface je na siti 10.1.10.0/24
lokalni PC dejme tomu je (B)10.0.10.200
to je nějaké divné.?
chápu to správně, že na fyzické síťovce máš dvě IP, 10.0.10.200 - výchozí, a 10.0.10.253, která je jen pro openVPN? A tyhle síťě jsou taky /24?
-
10.0.10.200 je PC v te siti kde je VPN server.
10.0.10.253 je dalsi "PC" ve stejne siti
takze dve ruzna zarizeni.
-
takze dve ruzna zarizeni.
ok. Myslím, ze by to melo byt zhruba takhle:
v siti A:
* pc(10.0.0.0/24) routa 10.0.10.0/24 via 10.0.0.52 (pokud uz to neni def. gw)
* na boxu s ovpn klientem (eth:10.0.0.52;tun:10.1.10.N (poslední byte neuveden)) routa 10.0.10.0/24 via 10.1.10.M
v siti B:
* pc(10.0.10.0/24) routa 10.0.0.0/24 via 10.0.10.253 (pokud uz to neni def. gw.)
* na boxu s ovpn serverem (eth:10.0.10.253;tun:10.1.10.M (poslední byte neuveden)) routa 10.0.0.0/24 via 10.1.10.N
nejsem si jistý, proč tam máš ten NAT.
-
Tam nie je ziadna zahada. Restartujes gateway , strati routu a beziace icmp ma ulozene v starej tabulke spojeni.. Nakopnes gateway ale vzhladom na to ze icmp mas stale pustene v ramci toho isteho spojenia tak je z toho mimo. Ked to icmp vypnes alebo sa vytimeoutuje tak to znovu frci. Preto ti tcp spojenia pekne frcia , lebo kazde jedno je defakto nove.
-
Super, diky moc, to jsem nevedel, myslel jsem, ze mam nekde neco spatne. Ted uz je to jasne.
-
Tam nie je ziadna zahada. Restartujes gateway , strati routu a beziace icmp ma ulozene v starej tabulke spojeni.. Nakopnes gateway ale vzhladom na to ze icmp mas stale pustene v ramci toho isteho spojenia tak je z toho mimo. Ked to icmp vypnes alebo sa vytimeoutuje tak to znovu frci. Preto ti tcp spojenia pekne frcia , lebo kazde jedno je defakto nove.
tvoja teoria nesedi s tymto:
... na A je videt IMCP req na tun0...
ako moze icmp vytimeoutovat? v ramci akeho "toho isteho spojenia"? pises bludy...
-
Ja to jeste nakreslim, at je to jasnejsi.
-
ja tomu rozumiem. bezne to pouzivame, ale takto sa nam to nesprava sprava. nejaky stavovy firewall...?
-
*ale takto sa nam to nesprava
-
pises bludy...
Ty si uz niekedy skusal trochu experimentovat s iptablami, routami, icmp a inymi protokolmi? Je mi jasne ze nie, tak prosimta najskor sa na dve hodinky zavri za virtualbox a nejaky ten linux, poskusaj si iptables atd potom sa ozvi,. Dakujem.
-
Ale dobre este pre typkov ako samalama sa jedna o "connection tracking" konkretne parameter net.ipv4.netfilter.ip_conntrack_icmp_timeout = cislo. V skratke - iptables maju haluze s iptablami, meniacimi sa routami a maskovanim. A ano kym sa "vytimeoutuje" spojenie tak to nejde. Pretoze icmp spojenie nie je pre iptables 1 request a 1 reply.
-
*server ma haluze s iptablami.
-
ja tomu rozumiem. bezne to pouzivame, ale takto sa nam to nesprava sprava. nejaky stavovy firewall...?
-
Pokud necham pingat vyse uvedene a restartuji OpenVPN Client gateway, ping ma timeout, ale za chvili by mel naskocit. Nenaskoci, presto ze vzdalena plocha do te site a na ten PC(B) bezvadne funguje. Pomuze jedine prestat pingat, par minut pockat a pak ten ping zase funguje. Moc to nechapu. Nesetkal se nekdo s timhle ? Pripadne jak to odhalit.
TCPDump na A je videt IMCP req na tun0 ale na druhou stranu uz se nedostane.
po vypnuti pingani a pockani par minut a znovu ping uz vse jede, na obojim tun0 je req/reply a na vzdalene strane je taky vse videt pri tcpdump.
Nejdriv bych se mrkl kde se ten ping ztraci? dorazi to z A na "OpenVPN Client gateway" (tcpdump -vn -i any icmp) nebo to vidis jen na A?
- Jak vypada arp tabulka na "OpenVPN Client gateway" a "A" pred a po a kdyz to pak zacne fungovat?
-
projistotu, taky zkontroluj jakej je rozdil v iptables pred a po restartu "openvpn gateway".