Omezení a řízení přístupu na LAN rozvodech po domě.

[martyr-m]

Zdravím, mám dotaz, jak nejlépe řídit přístup uživatelů na LAN domovních rozvodech.
mám panelové domy, kam pomocí optiky nebo radio reléových, wifi spojů dodám konektivitu.

Rozvod po domě provedu utp kabely a jsou zakončené ve switch.

Nejjednodušší a nejlevnější je utp kabel ze switche zakončit v zákaznickém PC,
ale pokud chci omezit uživatele, z případného odpojení, nebo omezení rychlosti, tak omezím přístup na MAC adresu PC, nebo uživateli přidělím IP adresy, což je dost těžkopádné.

Další možnost je omezení na switchi dát všude administrovatelné switche, ale pokud se někdo připojí na kabel, tak zase není nejlepší.
Poslední asi podle mě nejlepší možnost je dát k zákazníkům routery, jejich MAC si ukládat a omezovat MAC přidělených routerů.
Jak toto řešíte vy? jak to je nejlepší?
díky za radu.

[svestka]

velky vlan switche, do kazdeho bytu jeden vlan (tedy treba byt s tremi zasuvkami, vsechny v jednom vlanu). na dalku pak neplaticum apod. zakazes jeden vlan, cimz odpojis zminene zasuvky v byte a je po ptakach. jen to chce mit poradek v tom, kam ktery drat vede:)

[hapi]

tagujem vlany ale zákazníkům je neposíláme, odstraňuje je switch na paneláku u nich. Jeden vlan na centrálním routeru pak znamená jeden zákazník potažmo jeden subnet a jedno dhcp. Jeden router řídí třeba 100 userů, poskytuje 100 vlanů a na nich 100 dhcp serverů. Jednoduchým efektivní, lehce rozšiřitelný. Pak by se s tim dalo dělat třeba to že DHCP mu dá jenom třeba 3 IPčka a další ne. V mkčku jde navíc locknout dhcp lease s arp tabulkou kdy defakto to co nedá dhcp nejede.

Ale je určitě víc způsobů jak omezit, třeba i nějakým přihlášením typu hotspot.

[zdenek.svarc]

PPPoE + volitelně private VLAN na switchi.

[ludvik]

Řešení s VLANy může občas narazit na množství těch VLAN. Ono ne každý switch umí použít všech 4 tisíce možností. Některé končí i dost nízko, třeba na 64.

[zdenek.svarc]

Řešení s VLANami per klient naráží v první řadě na nesystémovost. RFC3580 sice připouští možnost, jak vytvářet dynamické VLANy v rámci ověřovacího procesu 802.1x, ale v praxi jsem to u žádného operátora neviděl. Opravdu není asi jediný důvod, protože obyčejná jedna Private VLAN úskalí izolace klientů na metalické/optické síti elegantně řeší.

A jsme zpátky u toho. Proč pořád vymýšlet bastly, když můžu vzít standardní telekomunikační řešení PPPoE a izolaci klientů vyřešit na drátové síti přes Private VLAN a na bezdrátové síti default forward no? Ušetřený čas určitě každý z nás využije mnohem lépe jinde.

[Walkeer]

Řešení s VLANami per klient naráží v první řadě na nesystémovost. RFC3580 sice připouští možnost, jak vytvářet dynamické VLANy v rámci ověřovacího procesu 802.1x, ale v praxi jsem to u žádného operátora neviděl. Opravdu není asi jediný důvod, protože obyčejná jedna Private VLAN úskalí izolace klientů na metalické/optické síti elegantně řeší.

A jsme zpátky u toho. Proč pořád vymýšlet bastly, když můžu vzít standardní telekomunikační řešení PPPoE a izolaci klientů vyřešit na drátové síti přes Private VLAN a na bezdrátové síti default forward no? Ušetřený čas určitě každý z nás využije mnohem lépe jinde.

A co pak vytaci to PPPoE? budto by musel mit kazdy klient nejaky router (navic dost vykonny, kdyz poskytujes treba 100Mb), coz prodrazuje, nebo to vytacet z woken, coz je mega opruz pro klienty.

[zdenek.svarc]

A co pak vytaci to PPPoE? budto by musel mit kazdy klient nejaky router (navic dost vykonny, kdyz poskytujes treba 100Mb), coz prodrazuje, nebo to vytacet z woken, coz je mega opruz pro klienty.

Zahoďte předsudky, tohle už na fóru proběhlo, viz viewtopic.php?f=58&t=8512&start=15#p83686 a pokračující vlákno. Navíc se názvu původního dotazu vyskytuje i požadavek na řízení klientů, což VLANy z titulu věci stejně neřeší.

[Walkeer]

Jako pravda je ze RB751 nestoji mnoho a klient obvykle najakou wifi + switch stejne potrebuje, takze to neni uplne zcestne. Navic se usetri za VLAN switche PPPoE mezi ROS-ROS by navic mohlo i docela dobre fungovat, takze asi proc ne. blby je ze to znamena dalsi NAT v ceste, takze v pripade, ze klient chce verejnou IP, je to trochu vice prace..

[zdenek.svarc]

... to znamena dalsi NAT v ceste, takze v pripade, ze klient chce verejnou IP, je to trochu vice prace..

PPPoE nevyžaduje, ani nemá přímou souvislost s překladem adres. Kde je problém?

[lukas-svk]

Ak nechcete pppoe tak treba mat switche ktrore vedia ACL resp IP Source guard.
Povolite na danom switchporte len uzivatelovu IP adresu. Ak pouzivate DHCP na adresaciu v panelaku tak potom DHCP Snooping + IP Sourceguard a DAI ...

Alebo potom naozaj to pppoe ..

[Walkeer]

... to znamena dalsi NAT v ceste, takze v pripade, ze klient chce verejnou IP, je to trochu vice prace..

PPPoE nevyžaduje, ani nemá přímou souvislost s překladem adres. Kde je problém?

Mam na mysli NAT na klientksem routeru, ktery vytaci PPPoE.

Ten IP source guard vypada vazne dobre. Neni potreba sr*t se s VLANama nebo s PPPoE, staci nastavit tu tabulku, provazat to s DHCP pres MAC a je to hotovo. Klient muze mit libovolny router ci koncovou stanici, musi ale nahlasit MAC.

[lukas-svk]

Nemusi, bezne mas pri DHCP naviazanu mac adresu <-> ip adresu , ale pri option 82 vies viazat napr circuit ID <-> ip addresu. ( switch pri prechode DHCP requestu doplni do requestu ako option ID switcha a portu na zaklade ktoreho DHCP priradzuje IP adresu. Takze uzivatelova ip adresa nie je viazana na mac adresu koncoveho zakaznickeho zariadenia ale na jeho koncovy port, zkaznik si moze vymienat box lubovolne a stale dostane rovnaku ip adresu. Toto napr mikrotikacke DHCP nepodporuje, ono sice vidi Circuit ID/ Agent ID, ale staticku lease tam priradit na zaklade toho ID nedokaze.. skoda taky kusocek chyba

PPPoE ma zasa ine vyhody.. to je proste individualne