Administrace komentářů

lidsky? ehm to asi nepujde nikdy.

prisel ti tcp(PROTO=) paket. chtel byt doruceny na cil(DST=) a tcp port(DPT=). nekdu mu bud prikraslil nebo jsou to skutecny(50:50 - to nelze u ipv4 rict s jistotou) hodnoty odchozi ip(SRC=) stroje a odchoziho tcp portu(SPT=). v tcp hlavicce mel jeste nastaveny bity v tcp flags(ACK rika, ze je platna hodnota v poli sekvencniho cisla pro potvrzeni prijeti paketu s takovym tcp sekvencnim cislem a FIN rika, ze zavira z jeho strany spojeni) v datech paketu nezacinaji prednostni data, ktera by mohly v socketu predbehnout jina drive prijata na temze socketu(URGP=) LEN= rika, ze je to minimalni ip hlavicka + tcp halvicka a prazdna data. TOS= a PREC=, ze se nechce specialni zachazeni po ceste skrz tvuj router. TTL= - spocitej si, kolik mas hop-u ke zdroji a jestli se lisi o >3 od (google:ttl os defaults) tak to bude jen nepatrne divnej paket. no DF bit v ip hlavicce rika, ze se paket nema fragmentovat a da se podle nej odhadovat, ze posilajici pouziva pMTU discovery. id a res naprosto nic nerikajici pole. WINDOW= je velikost tcp okna - kolik bytu se muze poslat bez prijeti potvrzeni. MAC, IN, OUT - zkontroluj prichozi sitovou adresu (1. 1/2 mac cisla bez ukoncovaci dvojnuly (00:60:97:96:db:8d)), abys vedel, ktera ethernetova sitofka to poslala. prijalo to zarizeni v IN a neodchazelo to zadnym zarizenim OUT=. firewall s tim provedl zahozeni bez odpovedi DROP. ID a RES? asi naprosto k nicemu cisla.