Ahoj, dáváme klientům veřejné IP jako NAT 1:1. Vnitří síť je routovaná a až na výjimky jede na neveřejných adresách. Na WAN klientova routeru směřujeme tu veřejku a klientův router směrem do netu se za tu veřejku NATuje.
-Všechno se děje na hlavní bráně (Router OS), kde mám src-nat a dst-nat pravidla.
- Z venku je to OK a bez problémů.
- Ze vnitřní sítě je ale problém, protože když přistupuju na veřejnou IP (např. 1.1.1.10), dostanu se díky default routě na hlavní bránu, ta mě pak pošle zpátky dovnitř na neveřejnou adresou (např 192.168.1.150). A tady je ten problém (moje src adresa je např. 192.168.2.30), když klient běžně NATovaný za veřejku odpovídá zpět do sítě, odpovídá svou neveřejnou IP (192.168.1.150) a směřuje to na mou src IP (192.168.2.30) nejkratší cestou, takže to nejde přes hlavní bránu a neprovedou se SRC ani DST NATy. Tím pádem pak komunikace nefunguje - paket směřovaný na 1.1.1.10, ale odpověď přišla z 192.168.1.150.
Řešení by asi bylo řešit SRC NAT už u klienta, ale jedeme na UBNT a tam si nejsem jistý, jestli to lze.
Má to vůbec řešení? Našel jsem vlákno z roku 2012, kde se to řešilo, ale na mikrotiku.
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Zase ten NAT 1:1 - může to fungovat i z vnitřní sítě?
Ahoj, firewall na UBNT lze provozovat plnohodnotně, pošlu ti ukázku do emailu. Mě se osvědčilo to řešit naroutováním veřejky přímo k zákazníkovy. Padne na to celý subnet /30, ale nejsou žádné problémy.
0 x
Dík za mail, ale ubnt má v plánu ve stabilní verzi AirOS 8 zakázat podporu custom skriptu 
Já hlavně ani nevím, jestli by to src natovani pomohlo. Neřešil jsi někdy tu samou věc? Routování /30 je pohoda, to mi taky funguje. Na Mikrotiku to řeším tak, že udělám /30 na neverejkach a na WAN dám verejku /32, která se tam routuje díky OSPF. Na ubnt ale fakt nevím.
Já hlavně ani nevím, jestli by to src natovani pomohlo. Neřešil jsi někdy tu samou věc? Routování /30 je pohoda, to mi taky funguje. Na Mikrotiku to řeším tak, že udělám /30 na neverejkach a na WAN dám verejku /32, která se tam routuje díky OSPF. Na ubnt ale fakt nevím.
0 x
Lze a umím i když to má své limity. Pošli PM. Můžeme to probrat.
0 x
Pouzij PPPoE a nemusis davat /30 s verejnyma (a nebo /30 neverejnych a OSPF u klienta). Podstatne jednodussi.
0 x
budu dělat blbýho, pppoe jsem u zákazníku nikdy nepoužíval a nerozumím té koncepci, chápu že mu na koncentrátoru dáš ipku veřejnou na ppp tunel
1) ale kde si má nastavit terminování pppoe? na domácím wifi routeru? to bude mít radost, že ke sprovoznění bude potřebovat jméno a heslo (až mu čez vyresetuje nekvalitní wifinu)
2) nastavit ten tunel na ubnt/mk CPE? to by mu moc nepomohlo
zaprvé píše že má routovanou síť, zadruhé to snižuje mtu, jak je to s něčím jako pppoe relay když mám routovanou síť?
edit: napadlo mě dobré harakiri - z CPE udělat tunel na pppoe koncentrátor, tunel vyvést bridgem do lanu zákazníka a nechat mu pppoe
1) ale kde si má nastavit terminování pppoe? na domácím wifi routeru? to bude mít radost, že ke sprovoznění bude potřebovat jméno a heslo (až mu čez vyresetuje nekvalitní wifinu)
2) nastavit ten tunel na ubnt/mk CPE? to by mu moc nepomohlo
zaprvé píše že má routovanou síť, zadruhé to snižuje mtu, jak je to s něčím jako pppoe relay když mám routovanou síť?
edit: napadlo mě dobré harakiri - z CPE udělat tunel na pppoe koncentrátor, tunel vyvést bridgem do lanu zákazníka a nechat mu pppoe
0 x
odpovím si asi sám, trochu jsem procházel google a nějak nečekám že mě někdo vyvede z totálního omylu
Varianta 1
Mám li L2 síť tak pppoe stejně můžu použít max na identifikaci zákazníkova CPE a nemusím se zabývat nastavováním L3 ve vlastní síti, ale zákazník bude mít zatím naroutovaný (nebo hůř znovu natovaný) rozsah s DHCP serverem. Pak ale musím řešit nepříjemně L2 topologii na STP/RSTP/MSTP což nalijme si čistého vína, třeba teď máme hlavní spoje mezi AP pomocí Alcoma/Siklu aj.m ale záložní propojka mezi AP běží na 5GHz a nedejbože, že by na ní došlo k nějaké ztrátovosti v MSTP rámcích, by se to přepočítávalo furt. Pak musím mít natahaný všude vlany, protože si neumím představit nechat to úplně volný všechno všude. Další hůř se dělá shapping, musí se dělat až centrálně což přidává spoustu problémů a konfigurace a data tečou až na koncentrátor. Další nevýhodou je změna mtu.
Varianta 2
Mám plně L3 síť maximálně s L2 páteří a propojky jedou přes ospf ABR nebo klidně když je to malé tak i v jedné area. Takže AP je L3, CPE je L3, ospf na AP dělá redistribute static a vše funguje jak má, shapper PCQ a zátěž do toku 80Mbps asi 30% na RB. Dají se tak poslat i veřejky /30/...., jen je třeba to vyfiltrovat z traceroutu a nebo pak nat1:1 pro ušetření počtu ip. Původního tazatele plně chápu, proč vyhodit 3 ip z rozsahu /30 když to není nutné (ale samozřejmě plnotučná ip je lepši
)
Varianta 1
Mám li L2 síť tak pppoe stejně můžu použít max na identifikaci zákazníkova CPE a nemusím se zabývat nastavováním L3 ve vlastní síti, ale zákazník bude mít zatím naroutovaný (nebo hůř znovu natovaný) rozsah s DHCP serverem. Pak ale musím řešit nepříjemně L2 topologii na STP/RSTP/MSTP což nalijme si čistého vína, třeba teď máme hlavní spoje mezi AP pomocí Alcoma/Siklu aj.m ale záložní propojka mezi AP běží na 5GHz a nedejbože, že by na ní došlo k nějaké ztrátovosti v MSTP rámcích, by se to přepočítávalo furt. Pak musím mít natahaný všude vlany, protože si neumím představit nechat to úplně volný všechno všude. Další hůř se dělá shapping, musí se dělat až centrálně což přidává spoustu problémů a konfigurace a data tečou až na koncentrátor. Další nevýhodou je změna mtu.
Varianta 2
Mám plně L3 síť maximálně s L2 páteří a propojky jedou přes ospf ABR nebo klidně když je to malé tak i v jedné area. Takže AP je L3, CPE je L3, ospf na AP dělá redistribute static a vše funguje jak má, shapper PCQ a zátěž do toku 80Mbps asi 30% na RB. Dají se tak poslat i veřejky /30/...., jen je třeba to vyfiltrovat z traceroutu a nebo pak nat1:1 pro ušetření počtu ip. Původního tazatele plně chápu, proč vyhodit 3 ip z rozsahu /30 když to není nutné (ale samozřejmě plnotučná ip je lepši
)
0 x
PPPoE se v routované síti normálně tuneluje. Třeba pomocí VPLS tunelů (což v ROSu funguje). Nebo se používá převod na L2TP, ale ROS neumí příslušný převod PPPoE na L2TP (LAC), umí jen ukončit PPPoE tunelované přes L2TP (LNS).
Jinak kvůli veřejce nemusím posílat na koncáka spojovák veřejek /30. Pokud má RotuerBoard, jde mu naroutovat přímo /32. Zkrátka mám ho spojeného na neveřejném bloku, na jeho neveřejku routuji veřejku/32 a klient ji má nastanu na WAN portu vedle neveřejky/24 i veřejku/32 a má srcnat pravidlo, co to NATuje na tu veřejku. Na APčku je puštěné OSPF, které dělá redistribuci lokálních rout, takže nemusím OSPF tahat až na router koncáka. A pokud koncák chce router, co to takhle neumí, tak dostane na posledním hopu to PPPoE, které to řeší. Jinak už pár verzí ROS umí i PPPoE s MTU 1500, pokud přenosová trasa dá MTU1508 a bude to podporovt i koncový router zákoše, tak nedojde ke zkrácení MTU kvůli PPPoE.
Jinak kvůli veřejce nemusím posílat na koncáka spojovák veřejek /30. Pokud má RotuerBoard, jde mu naroutovat přímo /32. Zkrátka mám ho spojeného na neveřejném bloku, na jeho neveřejku routuji veřejku/32 a klient ji má nastanu na WAN portu vedle neveřejky/24 i veřejku/32 a má srcnat pravidlo, co to NATuje na tu veřejku. Na APčku je puštěné OSPF, které dělá redistribuci lokálních rout, takže nemusím OSPF tahat až na router koncáka. A pokud koncák chce router, co to takhle neumí, tak dostane na posledním hopu to PPPoE, které to řeší. Jinak už pár verzí ROS umí i PPPoE s MTU 1500, pokud přenosová trasa dá MTU1508 a bude to podporovt i koncový router zákoše, tak nedojde ke zkrácení MTU kvůli PPPoE.
0 x
pomocí vpls aj tunelů to plně chápu a jo, proč by ne (kromě mtu a i to má jak píšeš náběh na řešení), to s dvěmi ip na wanu a snatem je fajn myšlenka, jen prostě zákazním nebere pořádné routery co umí více ip na wan (typicky domácnosti s levnými routery co si tím forwardují nešifrovaně kamery, nastavování topení a jiné super novinky , protože proč kupovat dražší router když pán v elecroworldu povídal že nemusí)
edit: co nešifrovaně, ale topení na tcp portu 8080 s jménem admin/admin si říká o problémy
, protože proč kupovat dražší router když pán v elecroworldu povídal že nemusí)edit: co nešifrovaně, ale topení na tcp portu 8080 s jménem admin/admin si říká o problémy
0 x
Když už se tady probírají L2 tunely, nejlepší by bylo udělat si přes routovanou síť VLANu s veřejnýma IP a střílet to přes hlavní linky, když to díky OSPF pojede zálohou, nepojede holt ani veřejka 
Jinak koncepce PPPoE se mi moc nelíbí, jelikož je tam prostě jeden kritický prvek - koncentrátor.
Jinak koncepce PPPoE se mi moc nelíbí, jelikož je tam prostě jeden kritický prvek - koncentrátor.
0 x
To je zajímavý řešení OSPF by to v nové verzi mělo podporovat. Má s tím někdo zkušenost? VLANu skrz routovanou síť?
0 x
nějak sem poslední dva příspěvky nepochopil, funguje všechno
2 forkman:
- vpls ti dělá transparentní tunel kam potřebujete a když ho nastavíte mezi loopbacky, tak se vám bude udržovat i přes změny na trase
- ad koncentrátor - souhlasím, jeden klíčový prvek ..... také nemám rád
2 helapc
- vlan přes routovanou = to samé co forkman, nejdříve tunel/vpls, funguje, ale končí na posledním kvalitním zařízení (typicky router na AP, připojovat si CPE do mpls a ospf tedy určině nebudu)
- řešení čeho? jako /32 na wan? funguje, proč by ne, ale podrpora na routrech zakošů je nulová
2 forkman:
- vpls ti dělá transparentní tunel kam potřebujete a když ho nastavíte mezi loopbacky, tak se vám bude udržovat i přes změny na trase
- ad koncentrátor - souhlasím, jeden klíčový prvek ..... také nemám rád
2 helapc
- vlan přes routovanou = to samé co forkman, nejdříve tunel/vpls, funguje, ale končí na posledním kvalitním zařízení (typicky router na AP, připojovat si CPE do mpls a ospf tedy určině nebudu)
- řešení čeho? jako /32 na wan? funguje, proč by ne, ale podrpora na routrech zakošů je nulová
0 x
Koncentrátor ti může dělat AP úplně stejně jako teď routing (takže nemusíš ani řešit tunely, přijdeš tak ale o některé dobré věci co to umí, ale fungovat to bude stejně).
PPPoE u klienta zakončíš na jeho routeru pokud potřebuje, jinak na zařízení co má na příjem. Routování je pak na tobě, jestli použiješ OSPF a nebo statický routing (s tím, že si rozhodíš, kde můžou být jaký veřejný). Když to vezmu do extrému, tak z jednoho C můžeš připojit 256 lidí s veřejnýma (skutečně můžeš použít 0, 1 i 255 a bude to fungovat, ale osobně bych 0 a 255 nedával).
Vždyť je jedno, jestli zdechne router a musím zadat IP a nebo jméno a heslo.
Nevím proč se tady vždy objeví někdo, kdo říká že je to naprd a nezkusil si to ani na stole. Jinak problém s MTU? Jaký konkrétní problém máte (a odpověď že je menší je blbost, protože, čemu to vadí?)? Opět, zkusit na stole a pak můžete něco k tomu říkat. Jo když je velká síť a jsou připojeni další ISP apod. tak tam samozřejmě PPPoE není.
Někde jsem tu i psal výhody PPPoE a bylo tu i vlákno na několik stránek kde se to řešilo (je tam ale dost balastu). A až budete přecházet jednou na IPv6, tak budete za PPPoE ještě rádi, že vám ulehčí spoustu práce.
Rozhodně nikoho přesvědčovat o tom nebudu, každý k tomu musí dorůst a dospět sám, že je to nejjednodušší řešení.
PPPoE u klienta zakončíš na jeho routeru pokud potřebuje, jinak na zařízení co má na příjem. Routování je pak na tobě, jestli použiješ OSPF a nebo statický routing (s tím, že si rozhodíš, kde můžou být jaký veřejný). Když to vezmu do extrému, tak z jednoho C můžeš připojit 256 lidí s veřejnýma (skutečně můžeš použít 0, 1 i 255 a bude to fungovat, ale osobně bych 0 a 255 nedával).
Vždyť je jedno, jestli zdechne router a musím zadat IP a nebo jméno a heslo.
Nevím proč se tady vždy objeví někdo, kdo říká že je to naprd a nezkusil si to ani na stole. Jinak problém s MTU? Jaký konkrétní problém máte (a odpověď že je menší je blbost, protože, čemu to vadí?)? Opět, zkusit na stole a pak můžete něco k tomu říkat. Jo když je velká síť a jsou připojeni další ISP apod. tak tam samozřejmě PPPoE není.
Někde jsem tu i psal výhody PPPoE a bylo tu i vlákno na několik stránek kde se to řešilo (je tam ale dost balastu). A až budete přecházet jednou na IPv6, tak budete za PPPoE ještě rádi, že vám ulehčí spoustu práce.
Rozhodně nikoho přesvědčovat o tom nebudu, každý k tomu musí dorůst a dospět sám, že je to nejjednodušší řešení.
0 x
forkman píše:Jinak koncepce PPPoE se mi moc nelíbí, jelikož je tam prostě jeden kritický prvek - koncentrátor.
Jak jsem napsal v predchozim prispevku, PPPoE server ti muze delat kazdy AP ktery ted routuje. Navic s PPPoE muzes mit na hlavnim bode treba 5 serveru, takze i kdyz chcipnou 4 tak to porad pojede.
0 x
to jsem přehlídl, zajímavá myšlenka a přes radius delat auth. Akorát pořád mám předávacím rozhraním pppoe a ne ethernet z čehoš zakoš nemá radost
0 x