lpr

rga rga na centrum.cz
Pondělí Červen 8 16:06:48 CEST 2009


>> Server sestavuje TCP spojení na tiskárnu, ohlašuje MSS=1400
>> tiskárna odpovídá, ohlašuje MSS=1460.
>> Server začne posílat IP datagramy o velikosti 1460 B.

> Proč server hlásí 1400, ale pak posílá 1460?

Jejda... já se upsal, 1440 "je" MTU, 1400 pak MSS,
tedy datagramy 1440 na 1420 B + 20 B to mělo být.

No každopádně jsem asi objevil pudla, naše servisní organizace má
asi "rozumně" nakonfigurován firewall/VPN, viz dále.

>> VPN je fragmentuje na 1440 B + 20 B, takto doráží na tiskárnu.
>> Tiskárna odpovídá zpět ICMP Type 12 Code 0, Pointer je nastaven na 36.

> Bajt č. 36 by byl nejspíš v TCP hlavičce, konkrétně by to byl kontrolní součet.
> Na jiném místě píšete, že ten povedený firewall fragmentuje pakety s nastaveným DF.
> Možná to tiskárna nedokáže pořádně složit dohromady.

Podle všeho to tak vypadá, taky jsem došel na to, že IP header + TCP header,
tedy offset 36 = TCP header checksum.

> Mám pocit, že problémy s MTU jsou u hogo-fogo VPN naprosto běžné.
> (A jsou i horší: zažil jsem situaci, kdy každým směrem procházela jiná velikost
> a ještě se ten limit v čase nějak záhadně měnil.)

Abych shrnul závěry, snad jen pro zajímavost.
Firewall je nakonfugorován, ač nám tvrdili něco jiného, jak PMTU Black Hole Router.
Packety s DF bitem "odznačkuje" a klidně si je fragmentuje, pokud je potřeba.
Dále ignoruje ICMP 3:4. Bohužel je tak dnes nakonfigurováno čím dál tím víc routerů.

Jádrem problému je, že VPN tunel je nakonfigurován tak, že provádí MSS Clamping
TCP SYN packetů v obou směrech na hodnotu 1400, když se ale podívám snifferem
na jedné straně, odchází datagramy o velikosti 1440 B (MTU 1440/MSS 1400)
s nastaveným DF bitem, na druhé straně dostávám fragmentované datagramy
na 1420 B (omlouvám se za chybu, 1440 jsem napsal špatně) + 20 B.
Z toho mi vyplývá, že MTU pro VPN tunel je 1420, tím pádem by měli mít nastaveno
v MSS Clampingu 1380. Tím pádem veškeré IP datagramy větší než 1420 B 
obsahující TCP packety tekoucí přes VPN jsou fragmentovány.
UDP neřeším vůbec. Díky PMTU Black Hole Routeru druhá strana není schopná
zjistit přes Path MTU Discovery Path MTU a k fragmentaci UDP packetů tak
bude docházet taky.

Bohužel, tiskárna opravdu asi není schopná zvládat fragmentované packety,
proto ta stížnost ICMP 12:0, pointer 36 na TCP header checksum.
Tu ale firewall taky blokuje. Divím se, že tahle firma kompletně nezakázala
i ICMP Echo Request/Reply... podle nich je nebezpečné snad úplně všechno.

Reportoval s neschopností zpracovat fragmentované packety
jsem už reportoval výrobci, čekám, co oni na to.
Každopádně opravením VPN tunelu problémy zmizely.

Jinak, je možné zapnout PMTU Black Hole Router Detection, určitě uvítám, kde v Linuxu
(sem to nepatří, ale Windows tuhle možnost mají povolitelnou v registrech už od NT 3.5,
ale povolená je tato funkce jako výchozí až u Vista/2008 a u XP SP3 a 2003 SP2),
to pak ve chvíli, kdy host neobdrží ACK na zaslané packety
a zároveň ani ICMP 3:4, pak předpokládá, že je v cestě PMTU Black Hole Router,
předpokládá, že Path MTU je 576 a posílá packety s MSS 536 maximálně.
Nevyužívá se tak kapacita linky, ale "alespoň to funguje".

Díky aktuálnímu problému jsem se o sítích přiučil tolik, co snad nikdy doteď.
Škoda, že to nemám možnost servisní organizaci "za jejich služby" možnost vyúčtovat... ;-)





Další informace o konferenci Linux