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

radik

Opravdu to tak trochu nabírá směr off topic :)

Co mám ku příkladu dělat, když routuju na L3 switchi? Ono každý router nemusí být mikrotik a na L3 switchi PPPoE server prostě neudělám. Pokud by to šlo formou NATu, asi bych se s tím spokojil. Nebo rozjedeme IPv6 a pak je to bude mrzet

No offtopic to zas tak neni, kdyz se resilo jak pridelovat verejny.

S L3 switchem: Bud si hodne majetny a divim se, ze delas ISP a nebo kecas.

Kdyz to vezmu kolem a kolem, tak jsou L3 switche co umi i PPPoE server (ano, a jsou drahy). Jinak zalezi samozrejme jak mas udelanou topologii, ale nemyslim si, ze mas na bode nekolik AP za za tim L3 switch a tak dal. To by bylo trochu neekonomicke.

Takze jak to teda je? Nebo zas tady nekdo placa a vymysli blbosti, ktery neexistuji? Pokud je L3 switch az nekde dal, tak prece muzes do toho switche pripojit PPPoE server, ktery to resi.

Jen se spis divim, ze tady opet vsichni pisou nesmyslny kraviny a jsou o tom presvedceni.

radik

ad radost: protože nemáme spoustu klientských routrů pod palcem a oni nejraději styl připojíš a jede, ne že budou opisovat ze smlouvy IP/auth do pppoe (proto ho má O2 ve firmwaru v defaultu) a dá se poslat dhcp na 1 IP z /30

ad testování: není potřeba, není proč by to nefungovalo tak jak říkáš, zajímá mě spíš logická architektura a vhodnost nasazení

A jinak s tim O2 vymytim jeste jeden blud a v podstate u vsech XDSL linek. PPPoE tam opravdu neni jak si vetsina lidi mysli, aby se naemuloval nejaky ethernet apod. Vzhledem k tomu, ze je to "over Ethernet", tak to znamena ze tam ten "Ethernet" uz je, takze to slouzi opravdu jen pro AAA. DSL muze fungovat i bez PPPoE se statickou/dynamickou adresou bez PPPoE.

radik

- proč používat pppoe? pokud ho chci k identifikaci zákazníka, tak musím používat něco centrálního ala radius a ne ppp profily na jednotklivých "AP Routrech" (třeba 100x "APRouter")

- použití k distribuci veřejné ip chápu, ale jak je to ptp tak tam potřebuješ udat /32 na zákazníka a /32 na straně "APRouteru" což znamená třeba 100xIP v čudu (jako variantu vidím protáhnout to přes vpls až někam do centrály a lidi s veřejkama prostě pustit přes 1 kontrolér ale to bylo zavrhnuto)

Tady by to chtelo rozdelit vlakno...

Proč PPPoE si najdi na foru, jinak ve stručnosti:

- je to dynamičtejsi nez DHCP

- uplny prehled o klientech

- nezavislost na vendoru (kdyz je udelany spravne)

- neplytva se IP

- historie

V pripade, kdy se chce dostat pouze verejna ke klientovi, tak staci lokalne uzivatele (to je co se tu resilo). Nekde muze byt radius skutecne problem (mala sit a nema svuj server).

Druhy dotaz moc nechapu. Ale zase zalezi jak to mas udelany. Vesmes stejne mas na tom AP nejakou verejnou IP a ta slouzi klidne jako brana pro vsechny PPPoE. Klienti pak dostavaji verejny/neverejny. Navic IP brany nemusi byt ani verejny (ale proc to delat, neni jediny duvod a vypada to pak skarede).

Takze priklad, pripojis 4 uzivatele z toho 2 maji mit neverejnou IP a 2 verejnou. Na AP uz ted kvuli routingu mas IP 1.1.1.1, takze to pouzijes i jako branu pro PPPoE. Takze klienti budou vypadat takto:

Neverejni: IP 100.64.0.254 + brana 1.1.1.1, IP 100.64.0.253 + brana 1.1.1.1

verejni: IP 2.2.2.254 + brana 1.1.1.1, IP 3.3.3.3 + brana 1.1.1.1

Jako ono nema tady cenu moc kolem toho resit, protoze vzdy se zas objevi nekdo kdo tomu nerozumi a nezkusil a bude do toho kecat.

Pokud by byl zajem a pokud se vlakno rozdeli, tak se muze udelat treba diskuzeo tom zda je zajem o tuhle problematiku a celkovyho navrhu site, ze by se nekde udelal sedanek a muze se to probrat i se konkretnim problemem situace + i zkusenosti a porovnani s tim kdo na PPPoE presel.

Klidne muzu tuhle problematiku osvetlit taky, ale sam urcite ne...

EDIT: na sedanku se muze i probrat jak to delaji velci operatori na xDSLkach, IP connect, transporty apod. pokud by byl zajem a jak je celkove udelany.

pgb

2 radik: díky za vyčerpávacící odpověď a i za ten príklad proč pppoe ano

Protože dle popisu topologie co jsem kreslil "AP Router" nemá veřejnou IP a je tam ještě CGNat. To, že je možné dát na PPPoE gw s neveřejnou IP mě od stolu vůbec nenapadlo a děkuji za narovnání představ.

ad lokálně ppp profil - už mi docvaklo, že mysliš na malou síť a pak redistribucí, ale v první chvíli mě takové zjednodušující řešení vůbec nenapadlo

radik

Protože dle popisu topologie co jsem kreslil "AP Router" nemá veřejnou IP a je tam ještě CGNat. To, že je možné dát na PPPoE gw s neveřejnou IP mě od stolu vůbec nenapadlo a děkuji za narovnání představ.

ad lokálně ppp profil - už mi docvaklo, že mysliš na malou síť a pak redistribucí, ale v první chvíli mě takové zjednodušující řešení vůbec nenapadlo

No, stejne pokud by jsi chtel dat verejnou primo klientovi, tak budes resit (muzes routovat i po neverejnych ale je to skaredy, RFC to neporusuje, ale je to hnus kvuli diagnostice z druhe strany) jak dostat na ten neverejnej router verejnou adresu (pak tam muzes delat NAT ostatnim a uz mas problem s tim, ze se vsme zmeni IP ven apod.). No a pak se ti to zase vsechno komplikuje a jen dalsi duvod proc PPPoE a tahat to necim dal az na PPPoE server. Tahle problematika je individualni sit od site a vse ma sve pro a proti.

Vesmes tim, ze dostanes verejnou az na klienta tak si usetris spoustu prace, protoze u sebe na routeru nemusis resit NAT 1/1 nebo NATovani jednotlivych portu k neomu. Vis ze ma klient nejakou IP a je to jeho zarizeni na kterym se pak delaji NATy. Potrebuje smerovat port, fajn dostnae verejnou IP (jo je to na jednu stranu plytvani, ale zas tolik lidi to nepotrebuje a usetri spoustu nervu a bordelu v NATu na brane). Takze asi nejcistejsi reseni a nejprehlednejsi.

pgb

děkuji, myslím že už jsi pochopil jak to myslím a co hledám, nějaké řešení mám, ale není nad to se neustále vzdělávat

Ano, routing /30 po neveřekách není hezký .... ale na tuhle možnost jsem uporoznil někde na začátku, funguje, ale plýtvá se.

Mě zajímala další varianta koncepce a rozšíření možných způsobů jak to udělat. To že dávat každému /30 je dneska v mém případě (málo IP) nesmyslné řeší nat1 (nebo PPPoE, u některé konkurence pro mě překomplikované /32 na wanu zák routeru s ospf a jiné podivuhodnosti). Takže teď si odlaboruji koncepci (předpokládám že lze pustit L3 i pppoe server na jednom rozhraní, budu laborovat, bude zábava :) )

Neveřejný klient => vzduch => AP Router privátní ip => privání páteř => Hraniční Router vč CGNAT => Internet

Veřejný klient => Vzduch => AP router + pppoe server + radius pro "veřejkáře"=> vpls tunel přes privátní páteř => Hraniční router bez nat => Internet

není v mé moci předělat všechny zákaznické wifiroutery na pppoe, ale ti s veřejkou by to přivítali určitě, že by měli přímou ip bez nat1

radik

Jo tak nejak to udelat muzes, ale casem zjistis, ze ti to prinese vic uzitku nez problemu a postupne premigrujes. Neni nad tu krasku, kdyz klient pak chce verejnou a ty v podstate nic neresis, jen v databazi/RB nastavis, ze klient ma adresu xyz a dostane ji(Nemusis resit pridavani adresy na routeru, kterou pak musis rucne NATovat). Potrebuje zmenit rychlost, tak zas nic moc neresis a zmenis jen v DB/RB a ma to nastaveno - nemusis hleda v queue apod (je to vlastnost, ze se queue dela dynamicky). Tyhle zmeny jsou teda az po reconnectu PPPoE.

Delat tunel nemusis, muzes klidne rutovat na to AP co neverejny (ale je to uz na tobe). Ani ten radius nemusis mit a resit zbytecne pokud nepotrebujes nutne. PPPoE kliedne muze bezet na iface, kde ti bezi IP provoz.

pgb

Co tak pozoruji, tak spousta lidí má jako hlavní GW RouterOS, mám tam linux a je to tak mocný, že není s ničím problém a doprogramuji si co potřebuji. Teď je to udělané tak, že přidám v DB jednoho nového klienta a o víc se nestarám, když chci přidat veřejku tak pouze v DB přidám položku jakou ip má nat1 vytvořit. U pppoe to dostává ale trochu jiný hezčí rozměr.

radik

Ano, musis mit ale nejaky slozitejsi system co ti to obhospodaruje (najde forntu, zmeni omezovac, priradi na DHCP IP apod). S radiusem to jen zapises do DB a uz se o vse postara za tebe. Nejsi zavisli v podstate na systemu (neotrebujes slozity system, ale jen v podstate tupy ktery ti zapise do tabulky radiusu) a ani vendoru (muzes pak misto Linuxu dat treba cisco, juniper, mikrotik ...).

pgb

jj, nemám osobně moc rád používání vlastností, které nejsou standardizované, protože když se to musí opravovat, je to práce navíc (jako moje gw na linuxu :) )

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

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

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.

« Předchozí stránka Další stránka »