PF a NAT pro lokalni sit / MTU

[Miroslav Lachman]

Dan Lukes wrote on 2019/03/23 07:02:
> On 23.3.2019 0:54, Miroslav Lachman wrote:

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

Ano, to bylo schvalne. Kdyz to dlouho nic nedelalo, zkusil jsem dalsi 
enter...

> 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).

I to je v podstate zamer a zkousel jsem to na server, kde vim, co se 
stane po poslani HTTP 1.0 requestu - ze mi ma vratit normalni HTML 
stranku a ne nejaky redirect atd. (vrati to defaultni "Welcome to 
nginx!" stranku)

Z logu ciloveho webserveru:

WW.XX.YY.ZZ - - [22/Mar/2019:22:54:16 +0100] "GET / HTTP/1.0" 200 612 
"-" "-" "-"
WW.XX.YY.ZZ - - [22/Mar/2019:22:55:03 +0100] "GET / HTTP/1.0" 200 612 
"-" "-" "-"
WW.XX.YY.ZZ - - [22/Mar/2019:22:56:32 +0100] "GET / HTTP/1.0" 200 612 
"-" "-" "-"
WW.XX.YY.ZZ - - [22/Mar/2019:22:57:14 +0100] "GET / HTTP/1.0" 200 612 
"-" "-" "-"

> 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.

Mam tady tech dumpu ulozeno tolik, ze mi staci, kdyz reknes, ktery 
presne chces a mile rad ti ho poslu.

Zachytaval jsem packety na xl0, rl0, em0 v pripade se starym routerem, 
kdy vsechno funguje a nasledne pro stejny telnetovy prikaz i na bge0, 
bge1 a em0

Takze chces porovnat dva dumpy ze stanice v LAN, nebo ze sitovky do 
vnitrni site na routeru (rl0 a bge1) nebo z vnejsi sitovky routeru (xl0 
a bge0)?

> 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.

Jak jsem popsal vyse, server na takove dotazy bez hlavicky Host normalne 
odpovida a zadne chyby v logu nema.

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

Zkousel jsem to i s hlavickou Host, ale protoze to na funkci rostlinare 
nemelo vliv, tak jsem na to pak kaslal a usetril tech par stisku klavesnice.

> 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.

Ja nic neblokuju, tedy urcite ne zamerne a urcite ne firewallem, protoze 
ten jsem zkousel i uplne shodit, nebo nastavit na pass all. Porad mi ale 
vrta hlavou, proc jeden stroj pouzije mtu 1500 a druhy, kterym ho 
nahradim, ma mtu 576.

> 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.

OK, zkusim to nejak odpoledne znovu.

>> 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.

Viz predchozi e-mail - kdyz ho zvysim, probehne novy dotaz na DHCP a pak 
se mtu opet nastavi na 576

>> 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.

Ja nastesti podobne sitove problemy resim "jednou za deset let", tak 
doufam, ze dalsich deset let me tohle nepotka a do te doby zase na 
nejake MTU zapomenu :)

Mirek