PF a NAT pro lokalni sit / MTU

[Dan Lukes]

On 23.3.2019 0:54, Miroslav Lachman wrote:
>> To bys prave dobre videl v tom dumpu ;-)
> 
> Do toho tcpdumpu jsem ted koukal pomerne dlouho, ale mam pocit, ze do 
> toho cumim jak husa do flasky.

> Takhle to vypada, kdyz zkusim telnet na port 80, pak zadat GET / 
> HTTP/1.0, dvakrat ENTER a na treti ENTER dojde k disconnectu.

"GET / HTTP/1.0" nasledovany jednim prazdnym radkem je legitimni 
HTTP/1.0 pozadavek. Ten treti ENTER je tam v tomto ohledu uz navic.

V tvem pripadu ale nehraje roli, protoze server spojeni uzavira ve 
skutecnosti uz po druhem ENTERu.

Od pozadavku, ktery zasila browser se navic lisi nepritomnosti "Host: 
....." hlavicky, takze telnetem se ptas "defaultniho" WWW serveru, 
kdezto browserem se ptas nejakeho virtualu (nerikam, ze to nakonec 
neskonci u stejneho defaultniho serveru - jen rikam \v cem se telnet 
pozadavek lisi od browseroveho).

> tcpdump jsem porizovat na vnejsi sitovce (bge0) a telnet jsem delal ze 
> stanice v LAN (LAN je na bge1)

Ja mluvil o dvou dumpech a jejich porovnani, tohle je jen jeden a ja 
nevim ktery z nich. Zda se mi, ze ten uspesny. Alespon ze sitoveho 
hlediska se uspesny zda.

> 03.129676 IP AA.50181 > WW.80: Flags [S], seq 779984406, ..., length 0
> 05.634234 IP WW.80 > AA.50181: Flags [S.], seq 895119811, ..., length 0
> 05.634611 IP AA.50181 > WW.80: Flags [.], ack 1, ..., length 0

Toto je standardni 3-way TCP setup handshaking.

> 08.641792 IP WW.80 > AA.50181: Flags [S.], seq 895119811, ..., length 0
> 08.642325 IP AA.50181 > WW.80: Flags [.], ack 1, ..., length 0

Zda se ale, ze serveru treti paket nedosel, proto svuj (druhy) paket 
opakuje a klient mu na nej znovu tretim paketem odpovida.

Opakovani samo o sobe problem neni, TCP se ztratami paketu pocita, ale 
ztrata pakety v LAN podezrela je - nekde se deje neco, co by se v LAN 
spis dit nemelo. Obzvlast pokud by se opakovanymi dupmpy ukazalo, ze 
neslo o "udalost, ktera se v nasem ustavu stane jen jednou za deset 
let", ale o neco, co se opakuje casteji.

Kazdopadne, v teto chvili je TCP spojeni navazane.

> 08.650351 IP WW.80 > AA.50181: Flags [.], ack 1, ..., length 0

Uprava velikosti okna, nezajimave.

> 09.038862 IP AA.50181 > WW.80: Flags [P.], seq 1:17, ack 1, GET / HTTP/1.0\r\n
> 10.982234 IP WW.80 > AA.50181: Flags [.], ack 17, ..., length 0

Prenos prvniho radku pozadavku, vse v poradku.

> 10.982609 IP AA.50181 > WW.80: Flags [P.], seq 17:19, ack 1, ... \r\n
> 11.182130 IP WW.80 > AA.50181: Flags [F.], seq 846, ack 19, ..., length 0

Prenos prazdneho radku (druhy ENTER) - server prijem dat potvrdi a 
vzapeti zahaji sekvenci pro uzavreni spojeni (flag FIN).

Tim muzeme zbytek dumpu povazovat za nezajimavy.

Timto dumepm tedy moc nepozname - zde je nejaky problem az na aplikacni 
urovni - s timto klientem se dany (defaultni) WWW server proste nechce 
bavit. At uz poroto, ze je to obecna vlastnost toho defaultniho serveru 
(se kterym se nikdo normalne nebavi) nebo je to nejaky sofistokovanejsi 
problem - jako treba to, ze klient nema reverz a server ma nastaveno, ze 
s takovymi se nema bavit. Detailni duvod odmitnuti by mohl byt v error 
logu serveru.

Pro ucely nasi analyzy bys musel pokladat dotaz ekvivalentni tomu, ktery 
poklada browser - tedy nejmene Host: parametr hlavicky.

Tenhle dump nam tedy s analyzou primarniho problemu moc nepomuze, tenhle 
dump ma svuj vlastni, nezavisly a samostatny, problem.

> Tak jsem zkusil Jirkuv tip na velikost packetu... a maximalni velikost, 
> kterou jsem z toho stroje schopen pingat, je 552. Na 553 uz mi neprijde 
> odpoved.

Z hlediska specifikace je takova LAN legitimni a i zde by mela 
komunikace probihat (za predpokladu, ze firewall nebrani pruchodu ICMP 
nutnych pro PMTU), ale jde o cislo neobvykle male. Jsou tu tedy dva 
problemy - primarni, zrejme ty nebo nekdo jiny blokujes neco, co je pro 
TCP nutne a druhy, ze velikost paketu, kter eprochazeji, je neobvykle 
mala. To druhe problem byt nemusi, mozna nejaka technologie nekde po 
ceste pruchod vetsich paketu opravdu neumoznuje, ale je to rozhodne 
vyrazna neobvyklost.

Budem se ale venovat nejprve te prvni. To se ti bude nejlepe analyzovat 
znovu dumpem (sorry), konkretne dvema - jednim porizenym na strane 
klienta, druhym, ze stejneho okamzikuk, porizenym na strane serveru.

A rovnou ti reknu co v nem hledas a nejspis najdes. V urcite fazi 
komunikace jedna ze stran (spis server, ale nikoliv nutne) posle velky 
paket (oznaceny "don't fragment" coz je u TCP standard). Paket, zrejme, 
neprojde a odesilateli by melo prijit ICMP "fragmentation needed" 
odeslane tim, pro koho byl ten paket velky.

No a to ICMP neprijde. Nejspis ho nekde po ceste nejaky spatne nastaveny 
filtr sezere. Je potreba zjistit kdo po ceste je zere (spis nez ping 
pouzivajici ICMP je na tohle lepsi traceroute -F -P TCP ... packetlen) a 
zajistit napravu.

Muze to byt i tvuj firewall, ale ja bych to videl spis na firewall na 
strane serveru. Duvod, proc se problem projevuje tobe a nikomu jinemu je 
ta nizka maximalni velikost paketu - ty na limit narazis. Ostatni 
nejspis ne a tak jim nepruchodnost filtru pro ICMP nevadi.

> A ted mi nekdo reknete, cim to muze byt?

Skoro to vypada, ze to je rozbity. ;-)

> ifconfig na bge0 hlasi mtu 576 (ale proc?)

A jde rucne zvysit ? Pokud ano, tak to neni tvrde omezeni, ale nekdo 
nebo neco tam to cislo nakonfigurovalo. Nejsem si jisty, jestli to 
nemuze udelat treba DHCP - kazdopadne, puvodce je treba najit a eliminovat.

Nejde zvysit (a po nastartovani v single-mode je uz takhle mala ?) - tak 
to je nejaky hardware-related problem. Do dalsich spekulaci bych se 
pustil az to bude potvrzeno.

> Kazdopadne specialni dik pro Jirku, protoze me by asi vazne nenapadlo 
> hledat problem ve velikosti packetu / MTU.

Casem to naopak v tehls eisuacich budes povazovat za "pricinu prvni 
volby". Ja po tobe ten dump chtel predevsim proto, ze preci jen existuji 
i dalsi mozne priciny a z dumpu je videt jak problem s MTU tak ty mozne 
dalsi.

Dan