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