PPTP, VPN tunel, NAT a MTU (delsi)

[Lars]

Dobry den,

resim problem s nasledujici konfiguraci:

klienti
WXP (wifi)    -->   HW AP (NAT) -->  Linux VPN tunel s maskaradou -->
router do UPC (NAT) ->
192.168.2.0/24    192.168.1.4           192.168.1.0/24
           UPC DHCP

Vypada to divoce, ale neni to tak straslive a chodi to. VPN tunel se
pripojuje pres PPTP do firmy a maskaraduje klienty na lokalni siti
(tedy vlastne jen jednu IP, nebot klienti uz za jednim NATem jsou).
Zjednoduseni site neni v tuto chvili mozne.

Na Linuxu je kernel 2.6.15 a nakonfigurovane PPTP spojeni. Klienty je
nutne bud skryt za NAT nebo maskaradu, coz je nastavene pomoci
iptables:

(sit triton je 10.0.0.0/8)

-- skript ip-up ----
/sbin/route add -net triton/8 window 16384 dev ${IFNAME}

# fix path MTU discovery
/sbin/iptables --append FORWARD --protocol tcp --tcp-flags SYN,RST SYN
\
   --jump TCPMSS --clamp-mss-to-pmtu

/sbin/iptables --append OUTPUT --protocol tcp --tcp-flags SYN,RST SYN \
   --jump TCPMSS --clamp-mss-to-pmtu

# output to triton
/sbin/iptables --insert OUTPUT 1 \
   --source 0.0.0.0/0.0.0.0 \
   --destination triton/8 \
   --jump ACCEPT --out-interface ${IFNAME}

/sbin/iptables --append INPUT -m state --state ESTABLISHED,RELATED
--jump ACCEPT
/sbin/iptables --append OUTPUT -m state --state ESTABLISHED,RELATED
--jump ACCEPT
/sbin/iptables --append FORWARD -m state --state ESTABLISHED,RELATED
--jump ACCEPT

#input from triton
/sbin/iptables --append INPUT \
   --source triton/8 \
   --jump ACCEPT --in-interface ${IFNAME}

# forward from any to triton
/sbin/iptables --append FORWARD \
   --destination triton/8 \
   --jump ACCEPT --out-interface ${IFNAME}

# forward from triton to any
/sbin/iptables --append FORWARD \
   --source triton/8 \
   --jump ACCEPT --in-interface ${IFNAME}

# masquerade ppp0
/sbin/iptables --table nat --append POSTROUTING \
   --destination triton/8 \
   --out-interface ${IFNAME} --jump MASQUERADE
------------------------------------

vypis kompletnich iptables

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state
RELATED,ESTABLISHED
ACCEPT     all  --  triton/8             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
TCPMSS     tcp  --  anywhere             anywhere            tcp
flags:SYN,RST/SYN TCPMSS clamp to PMTU
ACCEPT     all  --  anywhere             anywhere            state
RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             triton/8
ACCEPT     all  --  triton/8             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             triton/8
TCPMSS     tcp  --  anywhere             anywhere            tcp
flags:SYN,RST/SYN TCPMSS clamp to PMTU
ACCEPT     all  --  anywhere             anywhere            state
RELATED,ESTABLISHED

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             triton/8

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

-------------------------------------

Nereste prosim bezpecnost danych pravidel, o to zatim nejde. Az mi
vsechno pujde spravne, budu utahovat srouby.


Mam potize s velikosti paketu pro to PPTP spojeni. Z one Linuxove
gatewaye si bez problemu pinknu treba 35k velikym paketem - posledni
NAT a UPC to zvlada:

# ping www.seznam.cz -s 35000
PING www.seznam.cz (212.80.76.18) 35000(35028) bytes of data.
35008 bytes from www.seznam.cz (212.80.76.18): icmp_seq=1 ttl=58
time=1098 ms
35008 bytes from www.seznam.cz (212.80.76.18): icmp_seq=3 ttl=58
time=845 ms
35008 bytes from www.seznam.cz (212.80.76.18): icmp_seq=6 ttl=58
time=1100 ms

Do site triton ale plati maximum MTU (nastavene v /etc/ppp/options.pptp
na 1400) minus 32:

# ping 10.0.1.204 -s 1368
PING 10.0.1.204 (10.0.1.204) 1368(1396) bytes of data.
1376 bytes from 10.0.1.204: icmp_seq=1 ttl=128 time=72.2 ms
1376 bytes from 10.0.1.204: icmp_seq=2 ttl=128 time=71.9 ms

--- 10.0.1.204 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 71.919/72.080/72.242/0.313 ms

# ping 10.0.1.204 -s 1369
PING 10.0.1.204 (10.0.1.204) 1369(1397) bytes of data.

--- 10.0.1.204 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms


Potiz je v tom, ze kdyz aplikace na klientu posle vetsi paket nez je
limit na tunelu, tak ten je tise zahozen a aplikace se o tom nedozvi,
takze posila znova a pak skonci.
Omezeni MTU na klientech neni mozne.

Ma otazka tedy zni - jak zajistit, aby se bud klienti dozvedeli o
omezeni MTU, nebo se pakety na VPN tunelu transparentne fragmentovaly a
defragmentovaly (je-li to vubec mozne)? Mam v uvedene konfiguraci
nejakou chybu? Mate nejaka doporuceni?


Dekuji predem za tipy,

Jirka