nefunguje forwarding

[Daniel Dvořák]

Ahoj Dane,

díky za odpověď, postupoval jsem dle tvých rad.

Dan Lukes napsal(a):
> 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.
>   
Predpokladas spravne, ze v tom rozhrani vedoucim k A na routeru C uz se
ztrati i ten request z B. Nicmene co je zajimave Ccko  Acku odpovida
zpravou icmp ICMP time exceeded in-transit, kdyz se na B pinga z A nebo
jeste z neceho jineho za Ackem treba Xko X..........A-->--C--><--B.
>> FreeBSD 6.2-STABLE
>>     
>
> 	Ponekud odvazna volba pro produkcni stroj.
>   
No, sam si nekolikrat uz uvadel ze nekde bezis i current, tak to je
jeste vetsi hazard nez ten stable ne ?
Ale samozrejme je to pravda na produkcni by se to davat nemelo, nicmene
ten stroj ma dnes 55 dnu uptime od instalace resp. od kompilace toho stable.
>> 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.
>   
Prepinac -p potlacujici promiskuitni mod mam jako zaklinadlo, to
pouzivam porad.
> 	Dale nas zajima
> netstat -ibdhW
>   
Tady uz to zaclo byt zajimave, h prepinac tedy human readable form byl
nepouztelny, protoze tech paketu tim prosly uz miliony takze nez bych se
dockal nejakych zmen ...
Kazdopadne bez nej se cisilka fakt menila rychleji :). Ne ale tak jak
bych ocekaval sloupce Ierrs a Oerrs jak u ath0 spojeno s B tak u ath1
spojeno s A0 nevykazovaly zadne zmeny s naopak pribyvajicim poctem Ipkts
a Opkts na ath0 i ath1. Pochopitelne i Ibytes a Obytes na ath0 a ath1 se
menily.
> 	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
>   
Zde nastal prulom, protoze vystup obsahuje tento radek:
1504340867 packets forwarded (1504083983 packets fast forwarded)
(rozdilu si nevsimat, jak dale uvedu ...)
Kde mi to pripomnelo ze pouzivam fastforward (pameti mam dost tak co ?)
a prepnul jsem net.inet.ip.fastforward z 1 na 0
... no ano to zaclo najednou pingat !!!! :-O
Kdyz cron v 3 minutovem intervalu zavolal sysctl reload (mam fastforward
na 1 v sysctl, nejak se mi nepodarilo to zapinat lepe nez takto, v
default/rc.conf na to nic neni)
a tak prepnul z 0 zpet na 1, ping prestal. Zopakoval jsem to jeste
jednou, abych si byl jisty a potvrdilo se to.

server C# netstat -s -p ip
ip:
        1513709033 total packets received
        0 bad header checksums
        0 with size smaller than minimum
        0 with data size < data length
        0 with ip length > max ip packet size
        0 with header length < data size
        0 with data length < header length
        0 with bad options
        0 with incorrect version number
        314876 fragments received
        522 fragments dropped (dup or out of space)
        756 fragments dropped after timeout
        61323 packets reassembled ok
        6231785 packets for this host
        9 packets for unknown/unsupported protocol
        1504348338 packets forwarded (1504091454 packets fast forwarded)
        70508 packets not forwardable
        4224 packets received for unknown multicast group
        0 redirects sent
        6262956 packets sent from this host
        2084202 packets sent with fabricated ip header
        70615 output packets dropped due to no bufs, etc.
        70261 output packets discarded due to no route
        64338 output datagrams fragmented
        346374 fragments created
        0 datagrams that can't be fragmented
        0 tunneling packets that can't find gif
        0 datagrams with bad address in header

> a pozdeji (pokud stale pozorujeme icmp-request/reply)
> netstat -s -p icmp
>   
Sem jsem se ani uz nedostal, ale postuji vypis:

server C# netstat -s -p icmp
icmp:
        4424642 calls to icmp_error
        4875 errors not generated in response to an icmp message
        Output histogram:
                echo reply: 3433
                destination unreachable: 4189105
                time exceeded: 230658
        0 messages with bad code fields
        0 messages < minimum length
        0 bad checksums
        0 messages with bad length
        0 multicast echo requests ignored
        0 multicast timestamp requests ignored
        Input histogram:
                echo reply: 100362
                destination unreachable: 1966
                echo: 3433
                time exceeded: 101
        3433 message responses generated
        0 invalid return addresses
        1462 no return routes
        ICMP address mask responses are disabled

Hodne zajimave je to Output time exceeded.
> 	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
>   
server C# route -n get A
   route to: A
destination: A
  interface: ath1
      flags: <UP,HOST,DONE,LLINFO,WASCLONED>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu    
expire
       0         0         0         0         0         0     
1500       710

Je to korektne ath1.
> 	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.
>   
Problem se vyskytuje jen mezi ath0 a ath1, na zadnych jinych iface se
neprojevuje. Cely ten haluz zacal tim, ze jsem na ath1 tedy spojeno s A
pred tydnem a neco scanoval
okoli kismetem jestli nejsme ruseni. No a protoze nekde cesou klekly
routy nebo routery tak mi ssh okenko zustalo mrtve vyset ... kdyz jsem
se tam prihlasil kismet stale bezel
takze jsem ho musel ukoncit, bohuzel jediny co na nej zabralo bylo kill
-9 PID (korektni -3 nevzal vubec do uvahy). Ovsem uniklo mi, ze ten
proces hlavni kismet ma jeste taky dalsi podprocesy a ty tam vysely
jeste 4 dny pote nez jsem na to nahodou prisel pri vypisu procesu, takze
jsem to opet kill -9 musel pozabijet ty zbytky no a pak jsem si rikal ze
uz snad by to mohlo jet. Jakou souvislost ma kismet s fastforwardingem
netusim vubec, ale zjistil jsem ze pri zapnutem fastforwardu to proste
po tom incidentu s kismetem uz pakety nepredava na ath1 kdyz se pinga z
B do A.



> 	No az se na tohle vsechno podivas tak se uvidi co se uvidi nebo ze se 
> nic nevidi.
>
>
>   
Ja to ted vidim jako ze nevidime nic. :D
Proste fastforward je pricina a co to podelalo asi kismet. Jak muze
nejaka chyba v kismetu zasadne ovlivnit chovani kernelu mi moc jasny uz
teda fakt neni ?
> 						Dan
>
>   

Dan