Daniel Dvorak wrote:
> A-->--C--><--B
> Postizeny router C nema firewall.
> echo reply dorazi z B na iface 2 routeru C, kde vsak take je naposledy
> spatren v tcpdumpu a na iface 1 routeru C je videt jen ten request.
Predpokladam, ze problem neni vazan prave a pouze na icmp-echoreply, ze
kdyz se pingne z B na A tak se uplne stejne ztrati uz ten request.
> FreeBSD 6.2-STABLE
Ponekud odvazna volba pro produkcni stroj.
> Nic proste nic nedonucuje ten system poslat echo reply na Acko pres
> iface 1 Ccka zpet.
Tak to rozebereme na komponenty. Aby paket "prosel" musi ho jedna
sitovka prijmout, predat jadru k odroutovani, v routovaci tabulce musi
byt spravny zaznam odchoziho smeru a protoze v tomto pripade je cil v
lokalni siti tak roli hraje i arp tabulka. Nakonec musi paket odeslat
druha sitova karta.
Potrebujeme, kupodivu, overit hned to prvni i kdyz pises, ze to's uz
udelal. To, ze paket byl v tcpdumpu videt neznamena, ze ho sitova karta
prijima i v dobe, kdy na ni nikdo nekouka. Pokud u tcpdumpu nepouzijes
option '-p' pak je karta prepnuta v promiskuitnim modu, coz efektivne
odstavuje radu internich hardwarovych filtru, ktere jsou jinak aktivni.
Muzes pridat i '-v' kdy je tcpdump trochu sdilnejsi a rekne ti,
napriklad, ze pozorovany paket ma chybne kontrolni soucet.
Dale nas zajima
netstat -ibdhW
Konkretne ty sloupce, ktere hovori o chybach - ani tak nas nezajima
absolutni hotnota jako to, zda se udaj s postupne se ztracejicimi pakety
meni - nebo naopak - zda se cislo, ktere by se s prochazejicimi pakety
menit melo, nemeni.
Na dalsi urovni nas zajima
netstat -s -p ip
a pozdeji (pokud stale pozorujeme icmp-request/reply)
netstat -s -p icmp
I tady nas spis nez absolutni hodnoty zajimaji (ne)zmeny.
Pak tu mame jeste routing - kopudovi nas celkem nezajima quagga. Ta se
na routovani primo nepodili - ta jen nastavuje systemovou routovaci
tabulku. Navic jde v tomto pripade o komunikaci d directly-connected
stroju. Takze quagga muze byt i zcela odstavena.
Klicove prikazy jsou
route get A
arp A
V neposledni rade nas zajima, zda se problem projevuje vyhradne pri
komunikaci pres tyto dva zminene interface (a navic se zda, ze jen v
jednom smeru) nebo zda se pakety pri forwardu ztraceji i tehdy, kdyz je
cilovy respektive zdrojovy interface jiny - nejlepe nikoliv bezdratovy.
I to by pomohlo omezit domenu ve ktere je treba problem hledat.
No az se na tohle vsechno podivas tak se uvidi co se uvidi nebo ze se
nic nevidi.
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
