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
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
