Sziasztok!
Előzmény:
A legutóbbi MikroTik MTCWE oktatáson arról beszélt az oktató, hogyha nem akarjuk, hogy lássák egymást a WIFI kliensek, kapcsoljuk ki a "default forwarding" opciót.
Ha 2 WIFI AP van az eszközben, a 2 AP kliensei még láthatják egymást. Erre megoldás Split Horizon, ami elszigeteli egymástól 2 interfészt L2 szinten.
Ötlet:
Ezt nagyobb vezetékes (irodai) hálózatban az access rétegben is meg lehet valósítani büntetlenül?
Tehát minden access switch minden portján bekapcsolom a split horizont azonos horizon értékkel, kivéve az uplink portján.
Így nem látják egymást közvetlenül az irodai számítógépek. Hivatalból nem kell egymást látniuk. Külön VLANban és subnetben lévő szerverekkel beszélgetnek, amit az uplinken keresztül érnek el.
Teszt:
Mikrotik HEX 2 portján azonos horizont beállítottam, megszakadt a ping. Amint eltért a 2 horizon érték vagy nem volt, a ping ment. A tcpdump is igazolta az L2 elszigetelődést.
HW switch chippel rendelkező mikrotikben ez gondolom port isolation funkcióval helyettesíthető.
Cél:
windows a mellette lévő windowst ne buzerálja. Ha bekap az egyik egy crypto vírust, ne fertőzze le valami sebezhetőséget kihasználva.
A gépek ne fűrkésszék a hálózatot, semmi közük hozzá. Van gateway, menjenek arra, majd az ottani tűzfal policy szabályoz.
Tehát már L2 szinten szeretném elvágni a félrekolbászoló csomagokat a hálózaton.
Ellenérv:
Van bármi? Windowsos kollégák szerint a windows nem fog jól működni. A sajátgép nem fog működni, mert a beragad a hálózatfelderítés során.
Az egész felesleges, mert az AD felé mindenki elmondja, hogy létezik, az AD meg úgy is elmondja mindenkinek, hogy ki vannak a hálózaton.
Sőt, az AD szerver segítségével ki tudják kerülni az egész L2 védelmet, rajta keresztül elérik egymást a kliensek.
Ezeket én nem nagyon tudom hova tenni linuxos fejjel. Kellene egy kis tapasztalat a való életből.
Tudom, hogy a split horizon eredetileg nem erre való. Lehet, hogy túl egyszerűen gondolkozom, de nem alkalmas a fenti feladatra? Ha nem, akkor mi a bevett gyakorlat erre?
- 273 megtekintés
Hozzászólások
Ez a Horizon beállítás tapasztaaltom jól működik vezetékes hálózaton is (és ugyan úgy kell állítani, a "/interface birdge port"-nál). Én PPPoE kliensek elszigetelésére használom nagy volumenben, csak a PPPoE szerver felé beszélhet mindenki (teljesség végett: ezen felül csak pppoe-discovery és pppoe-session csomagok mehetnek). Így lehet rádugni a végpontra fordítva router-t, DHCP szerverrel, vagy akármi mást, senkivel semmit nem tud kezdeni egy-egy végpont.
A Te leírásodban a Windows-os kollégáid szerintem tévednek. És a tévedésnek semmi köze a Windows-hoz meg az AD-hez. Ugyanis ha a gépek /32-nél tágabb subnet-tel kapják az IP címüket, akkor azon belül mindenkit elérhetőnek tekintenek, és nem küldenek csomagot a GW felé (ami nem feltétlen az AD szerver ráadásul). Ha mégsem éri el a szomszédot így, akkor egyszerűen elérhetetlennek tekinti a keresett gépet (mintha ki lenne kapcsolva/nem létezne), nem próbálkozik "mégis" a GW-en keresztül megszólítani.
Azt nem is értem, hogy az AD hogy jön ilyen L2/L3 relációban ide...
Az más kérdés, hogy a Windows lelki béjékét mennyire borítja fel, ha nem tud a saját alhálózatában beszélni senkivel. Logikusan nem kellene számítania ennek, mert ha csinálsz egy olyan szegmenst amiben csak egyetlen gép van, akkor az simán jól működik, nem sír, hogy nincsenek szomszédok. Ezzel a Horizon-os izolációval szerintem pont azt éred el, hogy minden gép azt hiszi, csak egyedül ő van bekapcsolva a saját alhálózatában, mert nem lát mást.
- A hozzászóláshoz be kell jelentkezni
Ez a Horizon beállítás tapasztaaltom jól működik vezetékes hálózaton is (és ugyan úgy kell állítani, a "/interface birdge port"-nál). Én PPPoE kliensek elszigetelésére használom nagy volumenben, csak a PPPoE szerver felé beszélhet mindenki (teljesség végett: ezen felül csak pppoe-discovery és pppoe-session csomagok mehetnek). Így lehet rádugni a végpontra fordítva router-t, DHCP szerverrel, vagy akármi mást, senkivel semmit nem tud kezdeni egy-egy végpont.
a dhcp "problémára" ott a dhcp snooping (ami csak adott porton engedi a DHCP lekérdezéseket/kiszolgálást). A PPPoE frame-ekre pedig switch-chip szinten lehet filterezni emlékeim szerint.
Azt nem is értem, hogy az AD hogy jön ilyen L2/L3 relációban ide...
Fixme, de a windows a helyi hálót megpróbálja felderíteni "neigbor discovery" jelleggel - az AD pedig úgy jön ide, hogy a gép bejelentkezik AD-re, akkor az AD-től (is) megkapja ezt a discovery infót.
Szerintem van arra is lehetőség, hogy DHCP-vel /32 netmask-ot küldesz a kliensnek, akkor csak a gateway-el akar majd kommunikálni.
- A hozzászóláshoz be kell jelentkezni
A PPPoE esetben egyszerűbb volt csak a kétféle pppoe csomagot átengedni, minden más drop. A bridge filter-t meg a ROS intézi, ahol van HW támogatás, ott úgy, ahol nincs, ott meg CPU-ból (CRS3xx switch-ek vannak, azokon van HW support ilyesmire).
Azt érem, hogy az AD DC-től kaphat sokféle infót a kliens, de ez semennyiben sem befolyásolja azt, hogy akár az AD-ből nyert infó alapján, akár maga által gyűjtött infó alapján eléri vagy sem a többieket. Hiába mondja neki a DC, hogy van még 3 gép a szegmensében, ha az izolálás aktív, akkor nem fogja elérni, mert a DC ebben nem tud neki segíteni. Nincs olyan automatizmus (tudtommal), hogy ha egy gép nem éri el a DC által látott többi gépet, akkor a DC bevonásával próbálkozna az elérésükben.
Ezzel csak arra akarok utalni, hogy az AD DC (szerintem) nem tud segíteni a munkaállomásnak a port izoláció kijátszásában.
- A hozzászóláshoz be kell jelentkezni
cisco-ban nem a protected switchport / private vlan ennek az eredetije?
- A hozzászóláshoz be kell jelentkezni