OT: záhadne chovani nekterych zarizeni v siti

[Dan Lukes]

On 01/30/13 15:19, Zbyněk Burget:
> Misto toho, aby se packet v tichosti
> ztratil, protoze na siti uz neni prijemce, ozve se domaci routrik uplne
> jineho zakaznika, ktery vyhodnoti, ze ten packet k nemu proste prisel
> spatne a je potreba to napravit. A proto ho odesle zpet routeru (s
> originalni zdrojovou i cilovou IP adresou). No a router se packet opet
> snazi dorucit... Co mam povidat, sit to zaplavi tak, ze je nepouzitelna.
> Do doby, nez vyexpiruje (nebo je smazan) arp zaznam v routeru one
> puvodne vypnute stanice.

Problem vznikne jen v kombinaci nekolika okolnosti.

Na te fyzicke siti jsou je nakonfigurovana vic nez jedna logicka IP sit. 
Tim se k routriku klienta muze dostat paket, jehoz IP adresa nepatri do 
zadne site, kterou tento router zna.

S takovymi mix-sitemi je vzdycky trochu potiz, prinejmensim v oblasti IP 
  broadcastu (obzvlast s nespecifickym 255.255.255.255) ale vetsinou to 
samo o sobe jeste neznamena katastrofu.

Teprve kdyz se to spoji s dalsimi okolnostmi.

Paket o kterem je rec a ktery na routrik dorazi, nema jeho cilovou MAC. 
Za normalnich okolnosti by karta v nepromiskuitnim modu takovy paket ani 
neprijala a vsechno by bylo naprosto v pohode. Problemem jsou ruzne 
podivne router-bridge s takovymi featurami jako je klonovani vnitrni MAC 
ven a tak - tam je casto karta trvale prepnuta v promiskuitnim modu a 
softwarovy filtr, ktery by kontrolu cilove MAC implementoval je vadny 
nebo zcela chybi. Tim se paket, ktery nemel byt vubec prijat dostane do 
vyssich vrstev - a ty, uz legitimne a korektne, reaguji forwardovanim (a 
pripadnym ICMP_REDIRECT). Takovy routrik lze povazovat za vadny neb za 
rutinniho provozu by se nemelo na hodnotu cilove MAC kaslat a ignorovat ji.

No, a kdyz se spoji mixovana sit (tvoje chyba) se zarizenim s touto 
vadou (problem nekvalitniho zarizeni vyrobce), vznikne katastrofa.


> Resenim bude fyzicke oddeleni a odroutovani jednotlivych subnetu

Ano. Dostatecnym "fyzickym" oddelenim muze byt i zavedeni VLANu.

> Workarround by byl zkratit dobu platnosti zaznamu v arp tabulce (nevim,
> jak dalece je to rozumne - a taky jsem zatim napatral po tom, jako toho
> na FBSD dosahnout).

Castejsi ARP dotazy budou vytezovat sit, vcetne vsech zakaznickych linek 
(ARP je broadcast). Nastaveni je trivialni ukon:

sysctl net.link.ether.inet.max_age=(cas v sekundach)

> No a samozrejme nejlepsi resenei je pochopit proc se to deje a tem
> zarizenim vysvetlit, ze se tak nemaji chovat.

A to ja si celkem myslim, ze vim co se tam deje. Potiz je v tom, ze ten 
zarizenim to budes tezko vysvetlovat. Mozna se ti podari najit takovou 
kombinaci (de)aktovovanych featur kdy vnejsi karta v promiskuitnim modu 
nepojede, nebo treba pojede, ale nejaky kod dal bude spravne zahazovat 
pakety, ktere na routrik prijit nemely.

Ale mozna se ti takovou kombinaci najit nepodari - nebo ano, ale vypnes 
tim uzivateli neco, co bude chtit. A taky to na kazdem zarizeni bude 
jinak. A i kdy to zvladnes, uzivatel by uz nesmel do konfigurace nijak 
zasahovat (protoze i mala nevinna zmena muze zpusobit navrat puvodniho 
chovani).


  ----------------

Zkraceni ARP muze problem castecne resit. Presneji zkrati dobu po kterou 
je v cele siti kvuli problemu akutni pretizeni.

Dalsi moznost je zkratit TTL u paketu, ktere do tohoto segmentu posilas. 
Omezis tam delku "kolovani" a tudiz i mnozstvi paketu, ktere v 
konkretnim okamziku sit pretezuji. Myslim, ze na tohle neni ve FreeBSD 
nastroj, ale mohlo by byt pomerne jednoduche to jako "hack" dodelat.

Dalsi potencialni reseni je nahradit chybejici/vadny filtr konfiguraci 
na koncovem portu tveho switche (ktery vede do takoveho vadneho 
routriku) a routriku zadne pakety s MAC adresou, ktera neni jeho, 
nepredavat (broadcasty a multicasty nepocitam). To neni bezna schopnost 
switchu, takze si nejsem jisty, jestli to neni cista teorie.

Nicmene, jedinym "nehackovym" resenim je skutecne "de-mixovat" tu sit. 
Tedy - nemit na jedne L2 siti vic ruznych L3 siti kdy koncova zarizeni 
vzdy znaji jen nektere z nich.

Dan

P.S.
Mila Sos wrote:
> maximálně dát ICMP redirect a ne poslat packet zpět

Pokud vim, tak ne - vyznam ICMP_REDIRECT neni "paket jsem zahodil" ale 
"tentokrat jsem to preposlal, ale priste to posilej primo". Takze 
preposlani paketu je korektni (kdyby slo o paket, ktery byl routeru 
adresovan, coz v nasem pripade neni).