Zdar
Omezení ARP zivota: sysctl net.link.ether.inet.max_age
já v domácí síti používám 60s místo defaultních (tuším) 2700, nemyslím
si že by to mělo přinést nějakou komplikaci
To že se jedná o různé výrobce neznamená že nemají shodný firmware.
obávám se že ze síťového pohledu je rozjíždění více subnetů v rámci
jedné VLAN čuňárna
Pokud disponujete switchem CISCO, pak předpokládám že by klienty stačilo
oddělit konfiguračně na tomto switchi pomocí VLAN do skupin (na základě
adres subnetů) a pak spoj na router řešit jako TRUNKový spoj všech VLAN
To nic nemění na tom že routříky by ten provoz měly zahodit, maximálně
dát ICMP redirect a ne poslat packet zpět.
S pozdravem Mila
On 2013/01/30 15:19, Zbyněk Burget wrote:
Zdravím vespolek,
omlouvam se za prokazatelne OT, ale vim, ze tady najdu asi nejvic
odborniku a tudiz nejvetsi sanci na odpoved.
Uz jsem to pred nedavnem zesil soukromne s Danem a po vymene jednoho
podezreleho strojku jsem si myslel, ze mam po problemech. Bohuzel jsem
se pletl. V poslednich dnech se mi na siti objevily hned dalsi dve
zarizeni, ktere se chovaji uplne stejne.
Popisu situaci problem, jak se mi ho podarilo analyzovat. Jedna se o
prevazne bezdratovou sit, kde je z historickych duvodu nekolik subnetu
na jednom fyzickem sitovem prostoru.
Zacne to tak, ze nekdo doma vypne PC vcetne bezdratoveho zarizeni.
Dana IP, vcetne MAC adresy tedy zmizi ze site. Po nejakem case
vyexpiruje prislusny zaznam v MAC tabulce na centralnim switchi
(Cisco), ale v arp tabulce routeru zaznam prozatim jeste je. Ted se
stane to, ze nejaky libovolny klient (ktery ale je v jinem subnetu)
posle packet tomu vypnutemu klientovi. Ten dojde na router, ktery
zjisti, ze v arp tabulce ma prislusny zaznam a packet odesle. Switch
ale uz bohuzel nevi, do ktere vetve site ho ma odeslat a tak ho posle
na vsechny strany.
A tady prichazi kamen urazu. 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.
Veskere IP i MAC adresy jsou v poradku, takze nejaky utok typu MITM
bych vyloucil. Pri prvotnim vyskytu problemu jsme i se zakaznikem,
kteremu se takto jeho domaci routrik choval vyhodnotili, ze je ten
routrik vadny. Byl vymenen a problem zmizel.
Ted se mi na siti zjevily dalsi dva domaci routery, ktere se chovaji
uplne stejne. Ve vsech trech pripadech se jedna o jineho vyrobce
routeru, jedna se o zakazniky na jinych fyzickych vetvich site i
jinych subnetech. Coz ve mne nahlodalo myslenku, ze se mozna nejedna o
vadu zarizeni, ale ze se z nejakeho mnou zatim nepochopeneho duvodu ty
zarizeni chovaji spravne a ja hledam pricinu v jine kupce sena.
Resenim bude fyzicke oddeleni a odroutovani jednotlivych subnetu, na
cemz se pracuje, ale predstavuje to rozsahlejsi rekonfiguraci site
(vcetne zmen ve fyzicke topologii) a neni to otazkou nekolika dni.
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).
No a samozrejme nejlepsi resenei je pochopit proc se to deje a tem
zarizenim vysvetlit, ze se tak nemaji chovat.
Kdyby mel nekdo podobnou zkusenost pripadne nekoho napada, co s deje,
pisnete mi, prosim.
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
