Portál AbcLinuxu, 24. května 2024 17:44


Dotaz: Směrování – „exit node“ pro PPTP VPN a ztrácení datagramů po cestě

⧠ A = 0 avatar 5.3.2017 10:25 ⧠ A = 0 | skóre: 10 | blog: Technokratovo_zrcadlo | Helsinki
Směrování – „exit node“ pro PPTP VPN a ztrácení datagramů po cestě
Přečteno: 193×
Odpovědět | Admin

Pokouším se rozjet PPTP VPN (protože Android), avšak s poněkud zvláštním požadavkem, že veškerý IPv4 provoz směřující ven ze sítě půjde nikoliv přímo přes stroj, na němž běží pptpd, nýbrž skrz jednoho z klientů.

Čili mám řekněme tři stroje,

Sice se mi daří směrovat provoz z klienta ven přes mastera a vpnexit, dokonce i zpět zvenku přes vpnexit na mastera, ale nějak mi nejde poslední krok z mastera na klienta.

Co je ještě divnější, některé datagramy mi tam asi jdou, ale ty důležité asi nikoliv (webová stránka se nenačte), viz příslušné výpisy z paralelně běžících tcpdump:
root@master # tcpdump -i ppp1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp1, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20 packets captured
20 packets received by filter
0 packets dropped by kernel
09:08:52.318740 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [S], seq 1542567412, win 13600, options [mss 1360,sackOK,TS val 2356920 ecr 0,nop,wscale 7], length 0
09:08:52.418343 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [S.], seq 3388870745, ack 1542567413, win 28960, options [mss 1400,sackOK,TS val 577376877 ecr 2356920,nop,wscale 9], length 0
09:08:52.447993 IP 192.168.93.123.58675 > text-lb.esams.wikimedia.org.https: Flags [S], seq 3260400714, win 13600, options [mss 1360,sackOK,TS val 2356944 ecr 0,nop,wscale 7], length 0
09:08:52.477905 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2356948 ecr 577376877], length 0
09:08:52.477925 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [P.], seq 1:196, ack 1, win 107, options [nop,nop,TS val 2356948 ecr 577376877], length 195
09:08:52.548313 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58675: Flags [S.], seq 4176392288, ack 3260400715, win 28960, options [mss 1400,sackOK,TS val 577376911 ecr 2356944,nop,wscale 9], length 0
09:08:52.578306 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], ack 196, win 59, options [nop,nop,TS val 577376919 ecr 2356948], length 0
09:08:52.593368 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1:1349, ack 196, win 59, options [nop,nop,TS val 577376919 ecr 2356948], length 1348
09:08:52.593390 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1349:2697, ack 196, win 59, options [nop,nop,TS val 577376919 ecr 2356948], length 1348
09:08:52.608331 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [P.], seq 2697:3407, ack 196, win 59, options [nop,nop,TS val 577376919 ecr 2356948], length 710
09:08:52.608399 IP 192.168.93.123.58675 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2356962 ecr 577376911], length 0
09:08:52.670332 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2356968 ecr 577376919,nop,nop,sack 1 {2697:3407}], length 0
09:08:52.813343 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1:1349, ack 196, win 59, options [nop,nop,TS val 577376976 ecr 2356968], length 1348
09:08:52.818338 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1349:2697, ack 196, win 59, options [nop,nop,TS val 577376976 ecr 2356968], length 1348
09:08:53.376381 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1:1349, ack 196, win 59, options [nop,nop,TS val 577377101 ecr 2356968], length 1348
09:08:53.550303 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58675: Flags [S.], seq 4176392288, ack 3260400715, win 28960, options [mss 1400,sackOK,TS val 577377161 ecr 2356962,nop,wscale 9], length 0
09:08:53.630083 IP 192.168.93.123.58675 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2357064 ecr 577376911], length 0
09:08:54.331404 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1:1349, ack 196, win 59, options [nop,nop,TS val 577377351 ecr 2356968], length 1348
09:08:56.339213 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1:1349, ack 196, win 59, options [nop,nop,TS val 577377853 ecr 2356968], length 1348
09:09:00.413340 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], seq 1:1349, ack 196, win 59, options [nop,nop,TS val 577378856 ecr 2356968], length 1348
# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
12 packets captured
12 packets received by filter
0 packets dropped by kernel
09:08:52.318718 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [S], seq 1542567412, win 13600, options [mss 1360,sackOK,TS val 2356920 ecr 0,nop,wscale 7], length 0
09:08:52.418361 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [S.], seq 3388870745, ack 1542567413, win 28960, options [mss 1400,sackOK,TS val 577376877 ecr 2356920,nop,wscale 9], length 0
09:08:52.447976 IP 192.168.93.123.58675 > text-lb.esams.wikimedia.org.https: Flags [S], seq 3260400714, win 13600, options [mss 1360,sackOK,TS val 2356944 ecr 0,nop,wscale 7], length 0
09:08:52.477885 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2356948 ecr 577376877], length 0
09:08:52.477895 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [P.], seq 1:196, ack 1, win 107, options [nop,nop,TS val 2356948 ecr 577376877], length 195
09:08:52.548324 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58675: Flags [S.], seq 4176392288, ack 3260400715, win 28960, options [mss 1400,sackOK,TS val 577376911 ecr 2356944,nop,wscale 9], length 0
09:08:52.578344 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [.], ack 196, win 59, options [nop,nop,TS val 577376919 ecr 2356948], length 0
09:08:52.608355 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58674: Flags [P.], seq 2697:3407, ack 196, win 59, options [nop,nop,TS val 577376919 ecr 2356948], length 710
09:08:52.608340 IP 192.168.93.123.58675 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2356962 ecr 577376911], length 0
09:08:52.670317 IP 192.168.93.123.58674 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2356968 ecr 577376919,nop,nop,sack 1 {2697:3407}], length 0
09:08:53.550315 IP text-lb.esams.wikimedia.org.https > 192.168.93.123.58675: Flags [S.], seq 4176392288, ack 3260400715, win 28960, options [mss 1400,sackOK,TS val 577377161 ecr 2356962,nop,wscale 9], length 0
09:08:53.630070 IP 192.168.93.123.58675 > text-lb.esams.wikimedia.org.https: Flags [.], ack 1, win 107, options [nop,nop,TS val 2357064 ecr 577376911], length 0
... čili zatímco na mastera přijde 20 paketů, ten pak odešle na klienta jenom 12 a stránka na wikipedii se nenačte. Přitom provoz v rámci VPN funguje bez problémů. Nevíte, v čem by mohl být problém? Konfigurace směrování na masterovi:
# ip rule list
0:      from all lookup local 
32764:  from 192.168.93.0/24 lookup pppexit 
32766:  from all lookup main 
32767:  from all lookup default 

# ip route list table pppexit
192.168.93.123 dev ppp0  scope link 
192.168.93.0/24 dev ppp0  scope link 
default via 192.168.94.120 dev ppp1

# ip route list
192.168.94.120 dev ppp1  proto kernel  scope link  src 192.168.93.1 
10.19.84.2 dev tun0  proto kernel  scope link  src 10.19.84.1 
192.168.93.123 dev ppp0  proto kernel  scope link  src 192.168.93.1 
10.19.84.0/24 via 10.19.84.2 dev tun0 
default dev venet0  scope link 
Na vpnexit používá na vnější provoz IP masquerading:
iptables -t nat -A POSTROUTING  -o wlan0 -j MASQUERADE
Tuší někdo, v čem by mohl být problém? Předem děkuji.
Nevolte zmrdy.
Nástroje: Začni sledovat (1) ?Zašle upozornění na váš email při vložení nového komentáře.

Odpovědi

5.3.2017 11:14 NN
Rozbalit Rozbalit vše Re: Směrování – „exit node“ pro PPTP VPN a ztrácení datagramů po cestě
Odpovědět | | Sbalit | Link | Blokovat | Admin
Kdyz pustim jen ping z klienta na vpnexit tak se to chova v poradku?
⧠ A = 0 avatar 5.3.2017 11:35 ⧠ A = 0 | skóre: 10 | blog: Technokratovo_zrcadlo | Helsinki
Rozbalit Rozbalit vše Re: Směrování – „exit node“ pro PPTP VPN a ztrácení datagramů po cestě
Ano, mezi klientem a vpnexit se chová vše bez problémů. Problém nastává, pokud jsou to datagramy směřující na klienta přicházející zvenku.
Nevolte zmrdy.
6.3.2017 20:17 Vantomas | skóre: 32 | Praha
Rozbalit Rozbalit vše Re: Směrování – „exit node“ pro PPTP VPN a ztrácení datagramů po cestě
Odpovědět | | Sbalit | Link | Blokovat | Admin
Problém bude v tom, že se špatně dělí pakety, které jsou o velikosti 1500 a PPTP má menší MTU než toto.

Zkusil bych nastavit clamp-mss, třeba jako o tom píšou tady: http://lartc.org/howto/lartc.cookbook.mtu-mss.html nebo si najít nějaký jiný postup a odůvodnění proč to je potřeba.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.