nefunguje forwarding

[Dan Lukes]

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