PPPoE pro kliose

[kdavid]

Dalsi velky ISP resi ftth ponem s tim, ze CPE je pouze pruchozi prevodnik z pon na eth a pak cista statika verejka s /24 a mensim rozsahem. Zadna blokace na MAC atd..

Ok a klasika tet s cim se setkavam, klios preklepne svou IP pripadne zada Branu misto sve IP... Tu se pak resi problem s kolizemi IP adres.

to by me taky zajimalo jak to resi, oni maji mozna nejak jeste vazanou mac na ten PON kram. To uz nevim. Ze muzou mit svazanou mac s tou IP...

Svazat to muzou, ale kdyz se nahodi stejna IP tak se kolizi nevyhnou. a Svazani IP/Mac je L3 firewalling. Klois kliedne muze posilat falesne MAC do site + zasirat linku pres broadcast a pod.

[basty]

o by me taky zajimalo jak to resi, oni maji mozna nejak jeste vazanou mac na ten PON kram. To uz nevim. Ze muzou mit svazanou mac s tou IP...[/quote]

Svazat to muzou, ale kdyz se nahodi stejna IP tak se kolizi nevyhnou. a Svazani IP/Mac je L3 firewalling. Klois kliedne muze posilat falesne MAC do site + zasirat linku pres broadcast a pod.[/quote]

jasny no, to maji asi takto dost neosetreny...

[Majklik]

Ono vždy půjde o to, jaký šrot, co umí a jak je nastaven v konkrétním případě...
I u Mikrotiku jde udělat, že mám jako ISPík jen jeden router a všichni zákazníci v celé síti mají stejné nastavení znějící IP klienta 192.168.1.2/24, brána 192.168.1.1 a bude to fungovat. Jen je to hnusná pakárna to nastavovat.
Řada přtístupových technologií umí fungovat i tak, že je úplně jedno, jakou IP adresu má klient, co má nastaveno jako bránu a také mu to pojede...

Nebál bych se o xPON sítě a kabelovky, to jsou všechno point-multipoint sítě, takže komunikovat spolu dva koncáci přímo nemůžou a jde to přes hlavní bod, který to může správně profiltrovat. Nu, na klasickém Ethernetu buď musím použít inteligentní switche, které si s tím umí poradit nebo oblíbenou techniku vlan co zákazník a opět mám izolaci, kterou pak vyřeším na tom centrálním routeru....

[okoun]

no já bych se xPONu bál už jen kvůli pořizovací ceně za kteoru ti běžní smrtelníci vůbec nedají na jevo spokojenost

[Majklik]

U toho xPON jsem to myslel z pohledu možnosti snadno bránit těm různým atentátům od uživatelů... Ne ekonomickou stránku věci.

Jinak ani použití PPPoE není všespásné, pokud to nepodepřu patřičně nastavením krabic po cestě, kdy je vhodné opět mít aktivní izolaci klientů od sebe, jinak nějaký vtipálek si může nahodit svůj PPPoE server a bořit mi síť ()plus to, že by prvky neměly pustit nic jiného, než jen PPPoE provoz). Ale je fakt, že to už musí být úmysl. U normálního broadcastového ethernetu bez nějakých opatření stačí, aby nějaký vůl si přehodil doma kabel z WAN do LAN portu a naboří kde co na daném segmentu...

[okoun]

no počkej jak by zbořil síť, on když si udělá svůj vlastní NAS tak co se stane? maximálně nastane konflik adres ale uživatelé se tam neautorizují protože nebude znát jméno a heslo a nebude znát ani heslo k radiusu, takže smůla. ospf je také pod MD5 takže tam by neměl nic pustit, takže nevím jak to myslíš. leda jedině jestli se tam uživatelé nebudou furt dokolečka pokoušet o autorizaci a tímpádem nikdy nezkusí požadavek na ten pravý NAS?

[basty]

WAN a LAN myslel ve spojeni s dhcp server myslim.

[Majklik]

Jo, pokud mám klienty s PPPoE na WAN a klioš omylem přehodí kabel do LAN, tak nenakopne lidi kolem, co jsou ve stejné L2 doméně, protože obvykle PPPoE server nemá u sebe puštěn.
Pokud ovšem si chce cíleně hrát, tak si PPPoE server pustí. I když jen tupě, tak to naboří pár klientů, kteří, pokud bude jeho PPPoE server odpovídat rychleji, se budou snažit připojit k němu a přijdou o spojení (v podstatě podobně, jak když tam prdne omylem svůj DHCP server a nefiltruji to, pár lidí může dostat časem jeho vnitřní adresy a poslání k němu domu, kde to dál cestu nemá). A nebo si PPPoE server nastaví tak, že bude naopak přijmat jakékoliv jméno/heslo, nastaví si použití PAP ověření a s trocohu snahy takto časem posbírá přihlašovací údaje dalších lidí, místo kterých se může pak vydávat (dá se v podstatě udělat smyčka, že souseda takto chytím na svůj PPPoE server a dál se přihlašuji k skutečnému PPPoE serveru ISP a čumím do toho, co mi tam teče).
Takže je vhodné mít to podchyceno i u PPPoE linek, i když zde spíše pro jistotu proti hračičkám, u nativnímho ethernetu i proti možné blbosti lidem. Nedávno mi zrovna jedne ISPík psal, že mu takto klient unesl část sítě úplně jinam. Klioš si pořídil na zkoušku druhé připojení přes ADSL, někde zamotal kabel a na linku od bezdrátu připojil LAN stranu toho ADSL a unesl tak kus města, co byla v stejné L2 doméně přes sebe k O2.

[okoun]

no dobrý, ale jiná obrana než mít chytrý l2 switch není, že

[basty]

Mne se celkem libilo reseni co jsem psal o maxprogresu. DHCP pro VLANY, kdy proste prihazuji verejny na zaklade vlany at je na druhym konci cokoliv. Nemusi se resit mac na strane klientu a separace je taky udelana.

Zase jsem v MK nenasel moznost jak pridelovat IP z dhcp jednotlivym vlanam z jednoho rozsahu /24 treba...

Ale v tomto ohledu asi ano. Je potreba chytry L2 SW.

[Majklik]

no dobrý, ale jiná obrana než mít chytrý l2 switch není, že

Myslíš u toho PPPoE řešení? Všechno jde, když se tomu trochu pomůže... Snad každý switch s minimem inteligence umí izolací portů, takže izolace klientů od sebe brání úspěšnému převzetí PPPoE serveru jiným klientem. Pokud ani tohle switch neumí, tka VLAN co port a nahoru třeba QinQ. Snad aspoň switch s korektní VLAN podporou jsi ochoten koupit. A nahoře nemusíš cpát PPPoE server na každou tu VLANu - pokud tam máš MKčko, tak uděláš bridge, PPPoE server dáš na bridge a do bridge zapojíš všechny ty VLANy s tím, že jim nastavíš všem horizon=1 a máš izolaci i s jedním PPPoE serverem (stejně jde dát forward filtr pravidlo do L2 firewallu)...
Pokud switch umí filtrovat i použité protokoly, tak mu nastavíš, že má pustit jen PPPoE data discovery, ať ti tam klioš neposílá nežádoucí bordel....
Pokud budeš mít hodně chytrý switch, co má PPPoE helper, tak ti do PPPoE autorizačních žádostí klienta doplní identifikaci fyzického portu na kterém žádosti přichází a pak v radiusu můžu kašlat na jméno/heslo a ověřuji dle ID portu.
A je dalších pár věcí, ale už většinou okrajových.

Zase jsem v MK nenasel moznost jak pridelovat IP z dhcp jednotlivym vlanam z jednoho rozsahu /24 treba...

Jako máš jeden segment /24 a chceš ho použít na X VLANách současně? Aby se to jevilo fiktivně jako jeden L2 segment, ale ve skutečnosti byli klienti izolováni od sebe a případná jejich vzájemná komunikace filtrována routerem?
Toho se asi u MK dá dosáhnout. Pokud nepotřebuji řešit konkrétmí IP na konkrétní VLANu a nemám podporu dalšího (switch s DHCP light relay, radius, ...), tak obdobou výše zmíněného. Udělám bridge, na ten dám IP brány toho /24 a společný DHCP server, do bridge připojím všechny VLANy se stejným horizon a pokud mají klienti se mezi seobu mít možnost bavit, tak na bridge se zapne proxy-arp a ve firewallu poladím, co si přímo můžou posílat. Asi b yuž mohlo fungovat i pro IPv6 s nastevením, že sdílený IPv6 /64 segment je off link (ale nebude to ideál, když klient bude míc jak jeden kompl doma).

[basty]

Tak pocitam s tim, ze kdyz uz se davaji verejky, tak standardne jedna a proste user musi mit router. Pokud nechce verejnou, tak mu muzu dat nejakej neverejnej rozsah...

No uz si nepamatuju presne tu situaci, ale kdyz jsem chtel dat vlany na MK do spolecnyho bridge, tak se router pokazde restartoval. Ale mozna to myslis jinak. Ono je pak i asi dulezity, aby ty IP byly staticky... aby se nestalo... .teda klasicky abych mohl rict, tomuto uzivateli davej stejnou IP, a tady tem at se to klidne meni...