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).
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
