(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.
Citace od: Filip kdy 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
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.
Citace od: Filip kdy 20. 01. 2019, 22:08:16
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.Mv 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.
Citace od: snuff1987 kdy 21. 01. 2019, 06:01:21
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
Citace od: samalama kdy 21. 01. 2019, 13:52:45
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.
Citace od: samalama kdy 21. 01. 2019, 15:46:48
ja tomu rozumiem. bezne to pouzivame, ale takto sa nam to nesprava sprava. nejaky stavovy firewall...?
Citace od: Filip kdy 20. 01. 2019, 21:11:33
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".