Routing provozu z více WAN

[r223]

Zdravím,

mám rozsáhlejší routovanou síť, která má obecně více WAN.
Mám určitý problém s tím, jak zajistit, aby, pri pristupu z venku, šla odpověd pres stejnou WAN i ven, protoze se stane to, že pokud je to někde dále v síti a je nějaká WAN blíž, jde to default routou ven zde.
Zkouše jsem source-NAT vzdy na GW, ale nejak nejsem schopen to správně poskládat...

[Reklama]

[Hobbit]

Tohle fungovat nebude, protoze ten src nat na vstupu sice zafunguje, ale nebude ti sedet connection tracking, podle ktereho klient rozpoznava, ze se mu vraci odpoved od serveru, ktereho se na neco ptal.

Takhle se zeptas nejakeho serveru a odpoved se ti vrati z uplne jine IP adresy. Nu a to klient pohotove zahodi.

[RDa]

Tohle udelat v mesh siti bude trocha narocnejsi.

Je moznost svest veskery provoz do jednoho uzlu? (minimalne pro ty prichozi spojeni z vnejsku, tj. "servery" naslouchajici..).

Alternativne pak pro N routru ve vasi siti udelat N kopii naslouchacich lokalnich portu na M strojich, a pak na kazdem routru nastavit podle zdrojoveho portu delegaci skrze patricny hranicni router. Parovani gatewaye tedy bude skryto v individualizaci portu sluzby - port forwarding bude jiny na kazdem routru.

[metabug]

Zdravím,

mám rozsáhlejší routovanou síť, která má obecně více WAN.
Mám určitý problém s tím, jak zajistit, aby, pri pristupu z venku, šla odpověd pres stejnou WAN i ven, protoze se stane to, že pokud je to někde dále v síti a je nějaká WAN blíž, jde to default routou ven zde.
Zkouše jsem source-NAT vzdy na GW, ale nejak nejsem schopen to správně poskládat...

Nešlo by přiložit náčrtek sítě a případně dodat víc informací typu jestli máš vlastní veřejné, jestli se na GW provádí port forward, jak se řešený a tak podobně?
Čím víc informací dáš, tím líp.

[Petr Bahula]

Doporučuji nakouknout do:
https://www.root.cz/clanky/policy-based-routing-v-linuxu-smerovani-provozu-pod-kontrolou/nazory/
Pan Radek Zajíc mi velice pomohl ;-)

[Reklama]

[r223]

Zdravím,

mám rozsáhlejší routovanou síť, která má obecně více WAN.
Mám určitý problém s tím, jak zajistit, aby, pri pristupu z venku, šla odpověd pres stejnou WAN i ven, protoze se stane to, že pokud je to někde dále v síti a je nějaká WAN blíž, jde to default routou ven zde.
Zkouše jsem source-NAT vzdy na GW, ale nejak nejsem schopen to správně poskládat...

Nešlo by přiložit náčrtek sítě a případně dodat víc informací typu jestli máš vlastní veřejné, jestli se na GW provádí port forward, jak se řešený a tak podobně?
Čím víc informací dáš, tím líp.

Mám jeden centrální centrální s veřejnými IP, a pak větší množství sítí, které se k tomu připojují VPN tunelem. Jednoduše se dá říct, že potřebuju zpřístupnit některé služby z těch koncových sítí na tom veřejném serveru.

[metabug]

Mám jeden centrální centrální s veřejnými IP, a pak větší množství sítí, které se k tomu připojují VPN tunelem. Jednoduše se dá říct, že potřebuju zpřístupnit některé služby z těch koncových sítí na tom veřejném serveru.

Výborně. Na routeru ve vzdálené síti kde chceš zpřístupnit služby bych si dle příchozího interface označkoval packet a podle té značky pak poznáš, že ho máš odroutovat zpět odkud přišel.

Kód: [Vybrat]

iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-mark 1
ip rule add fwmark 1 table wan1
S tím že v tabulce wan1 budeš mít default routu skrz VPN na centrální prvek.

[Filip Jirsák]

Mám jeden centrální centrální s veřejnými IP, a pak větší množství sítí, které se k tomu připojují VPN tunelem. Jednoduše se dá říct, že potřebuju zpřístupnit některé služby z těch koncových sítí na tom veřejném serveru.

Ten source NAT dělejte na tom centrálním serveru s veřejnými IP adresami – na jeho interní adresu, ať se odpověď vrátí interní sítí.

Druhá možnost by byla ten provoz nějak značkovat, ale pak byste musel zajistit, aby se ta značka přenesla do odpovědi – ten source NAT bude jednodušší.

[r223]

Ten source NAT dělejte na tom centrálním serveru s veřejnými IP adresami – na jeho interní adresu, ať se odpověď vrátí interní sítí.

Ano, to byla moje původní myšlenka.

[Filip Jirsák]

Ten source NAT dělejte na tom centrálním serveru s veřejnými IP adresami – na jeho interní adresu, ať se odpověď vrátí interní sítí.

Ano, to byla moje původní myšlenka.

Pak nerozumím tomu, v čem je problém. Teoreticky by to fungovalo i tehdy, kdybyste veškerý příchozí provoz SNAToval, akorát u některého by to asi bylo zbytečné. Pokud se tomu zbytečnému SNATování chcete vyhnout, tak SNATujte jenom ten provoz, který přišel z internetu a směruje do těch VPN.

[M_D]

Takže spojení z Itnernetu jde na centrální server, zde provedeš DSTNAT pro poslání směrem k internímu serveru za VPN? A na stejném místě jsi zkusil i SRCNAT pro to, aby ti to šlo zpět správně? Ten VPN server je identický stroj s tím, co dělá to DST/SRCNAT v centrále? Co to je zač a jaký typ VPN je použito? Ono občas nejde kombinovat některé věci v jednom, často je problém NAT a čistý IPsec tunel, pokud to je na jednom stroji, protože si vzájemně lezou v pořadí zpracování blbě do zelí.
Čím realizuješ tu stranu VPN klienta? Routuješ správně na straně těch vzdálených sítí do tunelu tu IP,  kterou použiješ v tom SRCNAT na centrále? Samozřejmě by bylo hezčí řešení, pokud ten VPN klient na pobočkách je zároveň i wan brána do inetu, tak na něm pomocí značkování spojení si vést, co vracet do tunelu a co pustit přímo ven.

[r223]

Takže spojení z Itnernetu jde na centrální server, zde provedeš DSTNAT pro poslání směrem k internímu serveru za VPN? A na stejném místě jsi zkusil i SRCNAT pro to, aby ti to šlo zpět správně? Ten VPN server je identický stroj s tím, co dělá to DST/SRCNAT v centrále? Co to je zač a jaký typ VPN je použito? Ono občas nejde kombinovat některé věci v jednom, často je problém NAT a čistý IPsec tunel, pokud to je na jednom stroji, protože si vzájemně lezou v pořadí zpracování blbě do zelí.
Čím realizuješ tu stranu VPN klienta? Routuješ správně na straně těch vzdálených sítí do tunelu tu IP,  kterou použiješ v tom SRCNAT na centrále? Samozřejmě by bylo hezčí řešení, pokud ten VPN klient na pobočkách je zároveň i wan brána do inetu, tak na něm pomocí značkování spojení si vést, co vracet do tunelu a co pustit přímo ven.

Takže spojení z Itnernetu jde na centrální server, zde provedeš DSTNAT pro poslání směrem k internímu serveru za VPN? A na stejném místě jsi zkusil i SRCNAT pro to, aby ti to šlo zpět správně? Ten VPN server je identický stroj s tím, co dělá to DST/SRCNAT v centrále?
Ano.

Čím realizuješ tu stranu VPN klienta?
Mikrotik na obou stranách.

Routuješ správně na straně těch vzdálených sítí do tunelu tu IP
Ano, zda s, že vše funguje správně

protože si vzájemně lezou v pořadí zpracování blbě do zelí.
Ajno, myslím, že to bude nějaký problém tohoto typu. Ale nevím, jak to debugovat. Torch v MK se mi zdá nefunguje korektně, když to nejde pres fyzická rozhraní.

[Filip Jirsák]

No, když jsou ty VPN vyústěné na tom samém routeru, a ještě je to Mikrotik, to vám nezávidím…

Tak z druhé strany, ta rychlejší odbočka do internetu je předpokládám vždy jen router na druhé straně té VPN, není tam těch odboček po cestě víc. Routery na druhém konci VPN máte ve své moci? Nemůžete pro ten provoz, který má být směrován z veřejné IPv4 adresy do VPN, vyhradit v té VPN samostatnou IPv4 adresu? Že byste pak na routeru v té VPN nastavil pravidlo, že provoz z téhle speciální IPv4 adresy nemá jít na výchozí bránu, ale má jít do toho VPN koncentrátoru.

Tj. dnes vám ten server ve VPN, který chcete zpřístupnit i do internetu, běží třeba na 192.168.1.10. Vy byste mu přiřadil ještě 192.168.1.250 a provoz z toho centrálního serveru, který přišel z internetu, byste místo na 192.168.1.10 směřoval na 192.168.1.250. No a na routeru sítě 192.168.1.x/255 byste pak nastavil source policy, že pro provoz z adresy 192.168.1.250 se má použít jiná routovací tabulka, a která by jako výchozí bránu měla VPN tunel vedoucí na centrální server.

(Čím to je, že se v poradně nikdy neobjeví ti lidé, kteří v jiných diskusích tvrdí, že IPv6 nikdo nepotřebuje?)

[r223]

Nemůžete pro ten provoz, který má být směrován z veřejné IPv4 adresy do VPN, vyhradit v té VPN samostatnou IPv4 adresu?

Ne, to možné není.

[M_D]

Mikrotika bych ještě do žita neházel (je to neekologické). Nebyl uveden ten typ VPN, ale dle toho povzdechu nad Torch, tak asi jde o čistý IPsec tunel. S tím to fungovat nebude. Na straně VPN serveru to proběhne dobře pro příchozí pakety z Internetu, ale až se provoz vrací tunelem zpět, tak prochází stackem trochu jinak, že se neuplatní plně reverzní operace k těm prvotím NATům a paket se pošle do WAN s blbejma IPčkama (to je i vidět přes Torch).
Pokud trvám na IPsec, třeba kvůli HW akceleraci šifrování, tak bych použil GRE tunel a ten obalil pomocí IPsec transportu (nebo pokud ti koncoví klienti jsou za CGNAT nebo nemají pevné IPčka, tak spíče kombinaci L2TP/IPsec). Tím donutím vracející se paket plně projít stackem a bude to fungovat.
Také se to lépe chytá tím Torchem, protože do GRE nebo L2TP iface vidí. :-)
V druhém kole se můžu zbavit toho SRCNAT způsobem, jak bylo zmíněno. Označkuji si spojení došlé na VPN klientovi došlé z tunelu pomocí connection mark a pak na základě connection mark nastavím router mark na alternativní routovací tabulku, které pak vratí provoz natvrdo zpět do tunelu.