Zase ten NAT 1:1 - může to fungovat i z vnitřní sítě?

[loopie]

Hezký den,
vidím, že se hezky rozběhla diskuse o PPPoE My jsme přecházeli z DHCP na PPPoE před cca 4mi roky a byla to zatím nejlepší věc, kterou jsme pro síť udělali. Tenkrát jsme ještě měli VLANovou switchovanou síť, teď už skoro dva roky používáme MPLS/VPLS pro přenos VLAN z accessu do core, kde jsou centrální PPPoE servery. Za sebe musím vyzdvihnout několik pozitiv stávajícího řešení:

1) Backbone je routovaná OSPF s BGP pro signalizaci VPLS tunelů. Je to jednoduché na správu, dobře to škáluje a je to přehledné.
2) Centrální PPPoE servery mají neomezené škálování a redundanci. Není potřeba nic konfigurovat, veškerá funkcionalita je přímo v PPPoE protokolu.
3) Po backbone se nešíří žádné "uživatelské" routy. To má za následek minimální routovací tabulku a rychlou konvergenci při změně topologie.
4) Každá uživatelská PPPoE sessiona je v izolovaném L2 segmentu vyhrazeném pouze pro toho zákazníka. Zákazník může odpojit svůj router, začít sniffovat, broadcastovat, může dělat co chce ale neovlivní ostatní zákazníky. Bez ověření na PPPoE do mojí sítě neprojde ani bit.
5) Díky accountingu u PPPoE máme kompletní přehled o zákazníkovi a jeho historii, což je občas potřeba. Přesně vím, kdy byl zákazník připojen a kdy ne.
6) Každý zákazník má veřejnou v4 adresu, routingem bychom spotřebovali adres mnohem víc. Na naší topolgii bychom mohli nasadit i centrální DHCP, které by to řešilo, ale přišli bychom o výhody z bodu 5.
7) MPLS je úsporné na výkon routeru. Mikrotik poslední dobou hodně propaguje fastpath - MPLS provoz je fastpath odjakživa už z podstaty věci.

Jedinou nevýhodu vidím v konfiguraci - ne každý na to má žaludek. MPLS podpora v Mikrotiku je poměrně základní, ale funkční. Po důkladném testování jsme v reálném provozu neměli žádné problémy.

Jarda

[radik]

Tak tak, kdo prejde na PPPoE, tak se pak mlati, ze to neudelal driv.

Jinak jak pises, tak kazda sit to ma trochu jinak. Nekdo transportuje pres MPLS, nekdo pres VLAN (a pak nekdo to resi tak jak xDSL, ze izoluji porty od sebe na switchich - ale to lze udelat rozumne jen kdyz se jedna o kabelovy pripojky).

[pgb]

tak jsem laboroval a funguje to hezky, jen jsem narazil na několik logistických (z pohledu dat) problémů

a teď k popisu od loopie ....
1) super, více méně mám funkční vpls mezi mezi access a core, funguje to hezky
2) super, co jsem koukl na protokol tak si to samo vybere pppoe server
3) fajn, málo bordelu, vše v vpls

4) problém - pokud naběhne, je izolována v L2, ale do té doby je otevřený vpls tunel skrz kompletní rozvod naprosto bez řízení skrz celou síť až k pppoe serverům za podmínek
- pokud děláte qos až dle ppp profilů a ne cestou
- pokud se bavíme o centrálních pppoe serverech a ne malých serverech na access řízených radiusem

5) a 6) napadají mě varianty konfigurace CPE (ubnt/mikrotik sxt ......), teď v tom mám krásný pořádek a s pppoe mi vzniká zmatek
- zákazník nemá router, ale windows, vyplňujete mu pppoe nebo prostě necháte pppoe na CPE v modu router a k němu dhcp ?
- možnosti připojení zákazníkova routeru jsou přes jeho CPE na střeše v módu router (PPPoE ověření na wanu, zákazník nedostává dhcp ip na svůj router)
- zákazníkův router přes CPE na střeše v modu bridge (management na separe vlan) a následně pppoe na něm

7) ano

konfigurace není problém, pokud vím co chci

[radik]

A omezenim rychlosti to zalezi na tobe, ale vetsina lidi co to resi, tak jen omezi rychlost na serveru a ma trasy udelany ze staci a nebo se to na nich poagreguje samo. V praxi to zas takovy problem neni.

PPPoE zakonceno tak aby to bylo inteligentne:
- Pokud tam mam svuj mikrotik/ubnt apod. tak na nem, i kdyz tam ma svoji wifinu, ta se necha jako brdige
- pokud chce verejnou primo k sobe na router, tak radio do bridge a mgmt do solo vlan se muze dat (a nebo pres mactelnet v pripade mikrotiku)
Malo kdo z klientu ma primo kabel do PC, vetsinou je pred tim routeru. kdyz neni tak se doda, stoji par korun (kdyz je to problem tak pak uz jedina do PC a vytocit PPPoE).

[loopie]

tak jsem laboroval a funguje to hezky, jen jsem narazil na několik logistických (z pohledu dat) problémů

a teď k popisu od loopie ....
1) super, více méně mám funkční vpls mezi mezi access a core, funguje to hezky
2) super, co jsem koukl na protokol tak si to samo vybere pppoe server
3) fajn, málo bordelu, vše v vpls

4) problém - pokud naběhne, je izolována v L2, ale do té doby je otevřený vpls tunel skrz kompletní rozvod naprosto bez řízení skrz celou síť až k pppoe serverům za podmínek
- pokud děláte qos až dle ppp profilů a ne cestou
- pokud se bavíme o centrálních pppoe serverech a ne malých serverech na access řízených radiusem

5) a 6) napadají mě varianty konfigurace CPE (ubnt/mikrotik sxt ......), teď v tom mám krásný pořádek a s pppoe mi vzniká zmatek
- zákazník nemá router, ale windows, vyplňujete mu pppoe nebo prostě necháte pppoe na CPE v modu router a k němu dhcp ?
- možnosti připojení zákazníkova routeru jsou přes jeho CPE na střeše v módu router (PPPoE ověření na wanu, zákazník nedostává dhcp ip na svůj router)
- zákazníkův router přes CPE na střeše v modu bridge (management na separe vlan) a následně pppoe na něm

7) ano

konfigurace není problém, pokud vím co chci

1-3) Ano

4) Nevím jestli bylo správně pochopeno. Základam je izolovaný L2 segment nad kterým se potom vytáčí PPPoE. Izolace se dosáhne zapnutím izolace portů na access switchích, pokud se jedná o wireless, tak se na mikrotiku vypne default forward. Ubiquiti tomu říká client isolation. Pak je ještě potřeba nastavit horizonty na bridgích, ve ktrých končí VPLS tunely. Tím se dosáhne toho, že zákazník po L2 "vidí" jenom PPPoE server. Ten na interfacu směrem k zákazníkovi nemá nastavenou IP adresu, takže dokud nedojde k ověření PPPoE, zákazník nemůže přenést žádná data. Řízení toků v MPLS síti je podle nejkratší cesty v OSPF. Pokud by byla chuť, je možné nasadit TE tunely a mít tak toky kompletně pod kontrolou.

5-6) Pokud se budeme bavit o CPE ve wireless přístupové síti, tak používáme dvě konfigurace. Obyčejný klient má PPPoE na wlanu CPE a do LANu je DHCP a NAT. Zvídavý klient má CPE v bridge modu s managementovou VLAN a PPPoE vytáčí na vlastním routeru. Zákazníka na LAN rozvodech bez routeru máme jednoho. Není to problém, PPPoE umí všechny mě známé operační systémy.

Moje prvotní inspirace byla tady - https://www.youtube.com/watch?v=Q8AF-Srulmk Všechno potřebné info v jedné přednášce - vřele doporučuji.

Jarda

[Majklik]

Hle, člověk si odskočí na pár hodin do hospody a jak se to tu rozvine.
K popisu od loopie, také je dobré nezapomenout na filtraci protokolů, a to co nejblíže k zákazníkovi filtr, co do toho L2 pustí jen Ethernet rámce patřící pro PPPoE, to hned zahodí bordel od zákazníka, pokud tam pustí něco jiného. Umí slušnější switche a i bridge firewall v ROSu.

K otázce přihlašování jménem a heslem. Existuje funkce PPPoE Intermediate Agent, což je obdoba DHCP option 82. Některé switche to umí, pak mi switch v baráku do procházejícího PPPoE přihlašování vloží idnetifikci switche a ID linky z které to přichází. Zákazníka pak dle toho ověřím v RADIUS serveru bez ohledu na to, co si tam dá z jméno/heslo stejně, jak dělá O2 na xDSL (nebo jméno/heslo beru v potaz a navíc i kontoluji, zda je to použito na správné lince a ne u souseda).
Řvěte na Mikrotik, už před časem mi odkejvali, že je to naprosto legitimní požadavek, aby byla funkce PPPoE helperu součástí bridge, aby to šlo dát třeba do koncového SXT před router zákazníka nedo do CSR switche v baráku, takže funkci doplní, když bude o ni větší zájem.
https://www.broadband-forum.org/technic ... TR-101.pdf Chapter 3.9.2 PPPoE Intermediate Agent

[pgb]

loppie

4) Nevím jestli bylo správně pochopeno. Základam je izolovaný L2 segment nad kterým se potom vytáčí PPPoE. Izolace se dosáhne zapnutím izolace portů na access switchích, pokud se jedná o wireless, tak se na mikrotiku vypne default forward. Ubiquiti tomu říká client isolation. Pak je ještě potřeba nastavit horizonty na bridgích, ve ktrých končí VPLS tunely. Tím se dosáhne toho, že zákazník po L2 "vidí" jenom PPPoE server. Ten na interfacu směrem k zákazníkovi nemá nastavenou IP adresu, takže dokud nedojde k ověření PPPoE, zákazník nemůže přenést žádná data. Řízení toků v MPLS síti je podle nejkratší cesty v OSPF. Pokud by byla chuť, je možné nasadit TE tunely a mít tak toky kompletně pod kontrolou.

tohle je samozřejmě základ ale bez toho co dál píše Majklik to je polovičaté řešení, samozřejmě že mám zapnutou izolaci a na access routeru mám firewall který řídi kam provoz může

majklik

K popisu od loopie, také je dobré nezapomenout na filtraci protokolů, a to co nejblíže k zákazníkovi filtr, co do toho L2 pustí jen Ethernet rámce patřící pro PPPoE, to hned zahodí bordel od zákazníka, pokud tam pustí něco jiného. Umí slušnější switche a i bridge firewall v ROSu.

tohle jsem měl na mysli, prostě tam udělat filtr na L2, který to řeže, jinak "zavirovaný zákazník" může generovat ohromný provoz třeba v udp ať už je přihlášený k pppoe nebo ne. Dneska mám izolaci L2 + firewall L3, pppoe přidá další bezpešnotní vrstvu. S pppoe bych měl L2 filtr + pppoe auth do vpls tunelu

další důležitou věcí na wireless je qos ideálně na access routeru (nejblíže k kde se schází datový tok wireless interfacu), protože více queue může v součtu převýšit maximum AP ..... ať žije PCQ , nebo ppp aby profil nastavil queues do skupině dle wireless interfacu. Když se to nastaví s rezervou tak to funguje všem. Bez QOS to jede pár lidem a zbytek na sektoru děj se vůle boží.

[basty]

Není to dlouho co vypadlo 80℅ sítě fryzlovi, které jeli na pppoe u cibsu. Ale tak počítám že máte ty radiusy zdvojené na jiné lokace aby se předešlo výpadku.

[loopie]

pgb:
Tohle všechno bude záležet na tom jak jsi velký. My jako miniISP fungujeme bez L2 filtrů už několik let bez incidentu, větší síť předpokládám bude potřebovat silnější ochranu. Co se týká QOSu na wireless, tak to máme implementované přesně jak píšeš podle PPP profilu. Praxe ale ukázala, že k žádnému přetěžování nedochází, takže to mám vypnuté a šetřím tak výkon routerů. Tohle si asi na větší síti nemůžeš moc dovolit

basty:
Radius server je server jako každý jiný, tohle každý řeší/neřeší jinak. Taky už jsem se několikrát setkal s představou, že nedostupnost radius serveru znamená odpojení klientů. Tak to opravdu není. Pokud umřou všechny radius servery, tak po dobu než nějaký obnovím ze zálohy pouze nemohu připojovat nové klienty. U již připojených lidí pouze přicházím o accounting.

[pgb]

2 loopie:

malý/velký je vcelku jedno, jde o to jak jsi pečlivý a nadšenec do techlogie a pokroku .... příklad ať se to hezky počítá .... 802.11a propustnost 30Mbps. 10 klientů všichni klienti 15Mbps siple queue, přijde první ... ok, druhý .... ok .... třetí a latence letí doprd.... Na wireless interface nasdíš pcq per src ip z dynamickýho listu a máš po starostech a všichni jsou vcelku spokojeni.

802.11a jen pro příklad

Jako nejzajímavější považuji průšvih s motherF virem a jejich klony (protože pokud tu síť máte dobře navrženou (a jste lajdák a nemáte všude 100% nejnovější verze .... lol (každý dobrovolným betatesterem ), tak prostě žádný problém). Proto jsem se tolik ptal jak/kde zakončujete pppoe tunely v kombinaci wireless CPE. Protože pokud máte všechny klienty s veřejnou IP a zakončujete je na wlan CPE, tak je třeba mít dobře napsané firewally na CPE a mít tam povolenou konfiguraci zároveň. Zkusil jsem vystavit WAN nanostationu M5 na veřejku v době útoku motherF viru a nakazil se za asi 30 minut. Nejvíce se mi líbí myšlenka PPPoE zakončena na routerech zákazníků a konfigurace CPE na separe vlan s privátními ip.

[loopie]

Nadšení a pokroku samozřejmě nelze stát v cestě. Ono je pořád co zlepšovat Příkladu s agregací na sektoru rozumím a přesně to jsem měl na mysli tím, že každá síť je jiná. Někdo tohle prostě řešit nemusí.

K ubnt viru mám co říct, jelikož nějaké ubnt sektory provozujeme a jak jsem zmínil, každý zákazník má veřejnou IP, nejčastěji právě na CPE. U nás rozlišujeme dynamické (zadarmo) a statické (za 49) adresy. Na všechny dynamické se aplikuje nějaký základní firewall na PPPoE serveru, který virus odstínil. Statické IP (bez firewallu) lidé chtějí většinou na svůj router, takže s nimi nebyl problém. Jediné napadené jednotky byli zákazníci s dynamickou IP a vypnutým firewallem (třeba kvůli VPN). Díky topologii sítě se z nich virus nemohl nikam šířit, takže jsem těch pár jednotek celkem snadno odviroval. Na CPE vůbec žádný firewall nemám, zatím jsem nepřišel na nic co nevyřeším jednodušeji na centrálním prvku.

Zakončování PPPoE na zákaznických routerch není po zkušenostech úplně ideální. PPPoE klient v Mikrotiku se po odpojení za sekundu připojí zpět, ale zákazník co si koupil v Tescu v akci Tendu za 199 si počká delší dobu a možná se nedočká vůbec. Zákazníkům v této konfiguraci je potřeba dodat hAP lite

[radik]

Tak tady uz nema moc co dopisovat, aby uz z toho nebyl balast, jak se prave stava... Ale jen tak pro upresneni, co jste napsali a jak to funguje.

Resit L2 filtry na accessu (at uz wifi nebo kabel) pro PPPoE se nemusi kvuli bezpecnosti za urcitych podminek resit(navic kdyz se to vymysli dobre, tak tam muze bezet reklama a klient se pripoji a neco mu jede).

Pokud je to udelany stylem co AP to solo nejaky "tunel" (VLAN, MPLS, L2T, EoIP...), tak je to jednodussi pro mgmt zarizeni (protoze se nemusi pak izolovat uplinkovy porty a mgmt se vidi mezi sebou, pri izolaci portu je problem mgmt). Navic clovek hnedka vidi z kama se klient pripojil (ano, jak se psalo je PPPoE "helper", ale neni na vsech switchich coz treba VLANy ano a nekdo dela MPLS primo z AP), protoze se na radius vraci nazev interface + nazev service a z toho je to jasny. Izolace portu u klientu se resi pouze z duvodu toho, aby klient nemohl podvrhnout PPPoE server a ukrast heslo/data apod. + teda aby se nevideli, kdyz si sousedi daji stejny subnet a chteli by tahat data.

Jen tak pro to, aby ostatni vedeli co vlastne pppoe intermediate-agent delat, tak je to, ze do packetu PPPoE s overenim prida par bytu, kde napise <nazev switche>/<port>:<cislo VLANy>. Pokud je pak vsude switch co to umi, tak se muzou klienti sesypat klidne do jedne VLANy a vidi se presne kde kdo je pripojeny a nic se nemusi rucne evidovat.

Potreba si to uz jen osahat, zkouset a zkouset moznosti, protoze s tim jdou resit krasne veci.

EDIT: + pppoe intermediate-agent si jeste resit izolaci PPPoE packetu, takze se pak nemusi resit izolace portu, ale nedoporucuji, zase kvuli tomu, aby byla konfigurace vsude jednotna + se nevyresi problem sousedu se stejnym subnetem

[pgb]

díky za info s cpe, nějak mi nedošlo, že když dáváte dynamickou veřejku, že tam pořád děláte firewall na trase. Měl jsem zavirovány dvě zařízení v době útoku viru. Obě dvě byly veřejky terminované na CPE a "zapomenuté" (původně terminováno jinde na routeru zákazníka a pak na cpe + zák router v bridge módu).

To s tím znovuobnovováním tunetu mě trochu trápí. Pokud nemám pppoe a dojde k restartu na trase, tak se to srovná "samo". Proud tu vypadává dost často, ups/bateriové pole chytnou dost, ale když to nejde několik hodin, tak to jede zálohou (mám zakruhováno asi 75% sítě) a musím důkladně promyslet ty vpls tunel ..... Hap lite je levný a super na ethernetu.

Terminace na ubiquity Vám funguje taky dobře nebo se seká?

Napadl mě první problém s mtu, který možná není problémem, musím odzkoušet:
- vícero zákazníků má veřejnou ip protože prostě chtějí, tu mají nahlášenou jejich zaměstnavateli a z pc si vytáčení l2tp+ipsec a teď popravdě budu muset odlaborovat, jestli win10 přijdou na to, že po cestě je jiné mtu. Měl jsem s tím nějaké problémy na pppoe, když jsem nahazoval ipsec z cisca (kde bylo zároveň zakončeno pppoe) a stačilo přidat pravidlo, aby se data do tunelu řezala o dalších x bitů (ip tcp adjust-mss). Otázkou je, jak jsou v defaultu nastaveny win.

[radik]

Treba Mikrtoik si MSS resi... Problem bude, jen ten, ze bude trochu vetsi rezie, ale to uzivatel stejne nepozna. Ale pokud by to mela byt firma, kde bude server pro VPN apod., tak tam bych to treba neresil pres PPPoE, ale dal normalne /30 spojovacku. Zalezi uz pak vzdy na situaci, ale to uz je o designu cele site a celkove koncepci (ono totiz pak i obcas zjistite, ze vsechno nejde tahat pres MPLS).

[okoun]

Napadl mě první problém s mtu, který možná není problémem, musím odzkoušet:
- vícero zákazníků má veřejnou ip protože prostě chtějí, tu mají nahlášenou jejich zaměstnavateli a z pc si vytáčení l2tp+ipsec a teď popravdě budu muset odlaborovat, jestli win10 přijdou na to, že po cestě je jiné mtu. Měl jsem s tím nějaké problémy na pppoe, když jsem nahazoval ipsec z cisca (kde bylo zároveň zakončeno pppoe) a stačilo přidat pravidlo, aby se data do tunelu řezala o dalších x bitů (ip tcp adjust-mss). Otázkou je, jak jsou v defaultu nastaveny win.

nu já už jsem právě zavedl pravidlo, kdo má veřejku tak má automaticky i pppoe s MTU 1500 a je pokoj, cílem bude aby to mtu 1500 mělo 99% lidí aby byl bezproblémový přechod na ipv6