Jak řešit routing z vnitřní sítě ,aby šel na TUN a ne na WAN

[Vietnamka]

Zdravec, jak by se  na routeru vnitřní sítě správně řešil  routing  , aby  odchozí pakety nechodily na hlavní rozhraní do internetu ale, přes TUN?  Příchozí spojení pěkně dorazí do zařízení, ale odchozí má tendenci odcházet  špatným rozhraním.
Stručně: je to dím, že nemám v iptables žádné pravidlo FW/CONN/MARK nebo prohibit nebo supressprefix_length?
Obousměrně funkční spojení je funkční pouze  na ip adresu routeru (10.0.0.1) na rozhraní tun. Není funkční na ip rozsah vnitření sítě(ani routeru 192.168.0.222)
Potřebuji zachovat IP adresy remote hostů(takže nejde použít kombo  PREROUTING DNAT 80->192.168.1.9:8080 +  POSTROUTING SNAT  --to-source 10.0.0.2, takže router na vnitřní síti uvidí traffic z vpn rozsahu)
(Rozvedu, toto byl jen stručný úvod)

Na domácím routeru je TUN obsluhované ssh -w 1:2 Vzdálený bod je VPS (IP 1.2.3.4), kde jsou forwardované porty ( iptables -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.9:8080
)

/etc/iproute2/rt_tables : mám "10 vpn"
ip rule: 32765:  from 10.0.0.0/24 lookup vpn

ip route show table vpn
default via 10.0.0.2 dev tun8 (ip samotná je 10.0.0.1)
192.168.1.0/24 via 192.168.1.222 dev eth0

ip link:eth0  =lokální síť, tun =tunel, wan= rozhraní do internetu

Pozorování: Pakety  dovnitř krásně dojdou  (5.4.3.2 je nějaká remote host)

5.4.3.2:54321 -> 1.2.3.4:80 (in: vps-eth0)
5.4.3.2:54321 -> 192.168.1.9:8080 (vps forward out: tun-x, pravidlo -j DNAT)
----
tunel
----
5.4.3.2:54321 -> 192.168.1.9:8080 (router forward in: tun-y)
paket do zařízení v lokální síti
zařízení odpoví  192.168.1.9:8080 -> 5.4.3.2:54321
192.168.1.9:8080 -> 5.4.3.2:54321 (router forward in eth0)
192.168.1.9:8080 -> 5.4.3.2:54321 (router out : wan) - neaplikuje se ani  ip rule from 10.0.0.0/24

Jak routeru říct že tento paket má jít do tun-x a ne do wan  Logicky tam musí být nějaký conntrack, a poznamenat  si že flow z port 54321 přišel z  tun a ne z WAN. Samotné zařízení v síti pak nemá ponětí, že pakety pochazí z WAN

Nebo druhé řešení nějaký prapodivný nat že bych (na VPS) místo -jDNAT 192.168.1.6 dával  -j DNAT 10.99.0.6 a v routeru by se to pak muselo podruhé z natovat pravidlem  10.99.0.Q na  192.168.1.Q?


Co vychází lepe, ten extra-nat nebo nějaký MARK?



(Chci to právě zprovznit na holém tun, tedy ne wireguard).   -jMARK jsem nikdy nepoužíval...
četl jsem toto Policy-based routing v Linuxu: směrování provozu pod kontrolou



---ta funkce " Mezitím vypršelo sezení. Odešlete příspěvek znovu. Tento formulář jste již odeslali je  kvzteku. Už se to stalo zase stalo."  Reload zobrazí samou stránku bez dialogu prohlížeče odeslání POST Dat jelikož je přesměrován na  GET. Tlačítko zpět ho sice zobrazí ale zobrazí se pak čištá formulář

[Reklama]

[František Ryšánek]

Problém mě zaujal, ale odpusťte starému člověku, jsem už pomalejší... nějak si z Vašeho popisu nedokážu poskládat topologii. A ono nakonec asi není ani vhodné, abychom znali konkrétně Vaše adresy = dalo by Vám práci, namalovat obrázek, a zároveň substituovat za veřejné adresy, aby Vám nikdo neťukal na vrátka, minimálně dokud si tu konfiguraci nedoladíte...

Takže víceméně namátkou pár řečnických doplňujících dotazů (a poznámek):

- ke směrování provozu se používají routovací pravidla. V linuxu příkaz "route". Nebo též "ip route". Specifikujete "destination subnet", a přiřadíte mu "next hop", kam se má posílat.

- "holý tun" mi přijde jako lehký nesmysl. Jedna ruka netleská. Netdevice typu "tun" je obvykle zakončením nějakého tunelu. Říkáte, že wireguard ne... tak co tedy? "device tun" si obvykle namapuje nějaká serviska, která dělá tunel, nebo virtualizaci nebo tak něco. Tzn. třeba u VPN ta serviska řeší enkapsulaci/dekapsulaci paketů do nějaké tunelové relace. Máte snad napsáno něco zcela svého, co ten "tun" nahodí, a nějak to handluje s jeho provozem?
Netdevice typu "tun" enkapsuluje 3.vrstvu. Tzn. minimálně point-to-point spoj. Potřebujete, aby na tom "tun" zařízení vyvstal nějaký subnet, minimálně /30 (možná by šel zařídit i /32 tzn. lokální konec "unnumbered".). Pak se můžete v příkazu "route" odkázat na vzdálený konec (jakožto next hop), aby kernel do toho "tun device" začal házet nějaké pakety tím směrem.

- třeba OpenVPN na "server" straně by default přiřadí tunelu subnet a automaticky ho přihodí do routovací tabulky lokálního kernelu. Vzdálené straně umí kromě přidělení IP Adresy na její konec tunelu navrch "pushnout" jeden či více dodatečných routů. Tzn. instance OpenVPN na klientské straně je nasype do kernelové směrovací tabulky na svém konci.

- connection marking má smysl používat až v situaci, na kterou standardní routing nestačí. Třeba když máte tentýž destination subnet viditelný více směry, a u příchozích spojení chcete, aby se opačný směr (traffic náležející téže relaci) posílal "zpátky tou cestou, odkud relace přišla". Osobně jsem to použil v situaci, kdy jsem měl dvě konektivity od dvou různých providerů... to ale není Váš případ...?

- taky se dá zařídit, v rámci prostého routingu, třeba když máte nějakého cestujícího VPN klienta, aby po navázání tunelu se default route přehodil dovnitř do tunelu - a na místní default gateway na LAN zůstane ukazovat jenom specifický route na veřejnou IP adresu vzdáleného VPN access koncentrátoru v divokém internetu. Přístup do internetu pak vzdálenému VPN klientovi řeší "centrála". Toto je třeba konfigurovatelná fičura OpenVPN = netřeba s těmi routy šachovat ručně, OpenVPN to zařídí.

- NAT může zůstat mezi LAN a WAN. Stačí obecná maškaráda. Na tomtéž routeru může být jeden konec tunelu, do kterého se dovnitř neNATuje.

Kladete poměrně pokročilé dotazy na IPtables. Je možné, že jenom nedohlédnu výšin Vašeho geniálního záměru. Upřesnění a dotazy vítány :-)

[_Jenda]

Řešení problému neznám (taky jsem na něj narazil a vyřešil jsem to tím NATem, který tazatel nechce), ale alespoň ho popíšu krátce svými slovy, třeba tak bude pro ostatní stravitelnější a někdo s řešením přijde.

Tazatel přesměruje pakety z internetu ("klient.cz" mířící na "vps.cz") skrz tunel do lokální sítě která je "za-natem.cz". Zařízení v lokální síti dostane paket se zdrojovou adresou "klient.cz" a odpoví na něj - posláním odpovědi na "klient.cz". Výsledkem je, že klient.cz dostane paket se zdrojovou adresou za-natem.cz, ale netuší, že to je odpověď na jeho paket, který poslal na vps.cz. Potřeboval by, aby ten paket měl jako zdrojovou adresu vps.cz, aby si to dokázal spojit.

- "holý tun" mi přijde jako lehký nesmysl. Jedna ruka netleská. Netdevice typu "tun" je obvykle zakončením nějakého tunelu. Říkáte, že wireguard ne... tak co tedy?

Píše že ssh -w.

[kolemctouci]

Dobry den, kdysi jsem resil mozna podobnou vec - jeden pocitac se dvema pripojenimi do internetu a snaha, aby se kazde jednotlive spojeni udrzelo na interface, pres ktere prislo, nikoli, aby se vzdy pouzila default route a vsechny odchozi pakety odchazely pres jeden interface. Chapu-li to dobre, je to presne problem, s kterym bojujete.

Moje situace byla ponekud jednodussi, zadna VPN, ale v principu by bylo mozne, ze by toto slo aplikovat i u Vas, kdy bychom vlastne rekli, ze cilovy pocitac musi odpovidat vzdy pres interface, pres ktery byl na danem spojeni osloven.

Tehdy jsem to vyresil pres dve routovaci tabulky, kdy se pomoci chytrejsiho prikazu ip (nekteri s sedivymi vousy se zavislosti na ifconfig asi nikdy nezbavi :-) ) vytvori druha routovaci tabulka, druhy interface se pripoji na ni a default route v teto tabulce pak odsmeruje paket na druhy interface. Primarni routovaci tabulka zustane tak jak je, obsluhuje veci souvisejici s prvnim interface.

Popsane jsem to nasel tady (asi lepe, nez bych to dokazal sam):
https://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming

[Vantomas]

Párkrát jsem tenhle problém řešil, kdy jsem potřeboval vracet pakety do stejného interface odkud přišel požadavek. Přesně z hlavy to nedám, neřešil jsem výkonnost, ani nějaké hlubší problémy, které nejsou na první pohled zřejmé, vždy to byla jen taková dočasná řešení na 14 dní, než se překlopí nějaké VPNky, zprostupní vlany v trunku a tak.

Ve zkratce, v default routovací tabulce se dá default gw na jednu konektivitu, pak se přes ip route vytvoří druhá routovací tabulka, kde je default gw do druhé konektivity, přes iptables se omarkují pakety chodící z jednoho interface a pak jinak z druhého interface, je tam nějaká operace pro přenos marku z connection na packet a pak přes ip rule nasměrovat označené pakety do správných routovacích tabulek.

Teď se mi k tomu podařilo v rychlosti vygooglovat https://serverfault.com/questions/1107846/how-to-route-a-reply-packet-to-the-device-it-coming-from

[Reklama]

[Vietnamka]

Díky všem za rady, zkusím to projít všechnou, doufám že z toho vykřešu správné rozuzlení. Současný stav (po aplikaci mangle a rule fwmark) je, že příchozí pakety jsou značkované, ale odpověď stále má tendenci jít přes wan, Takže si myslím že problém bude v obsahu tabulky vpn (default via 10.0.0.2 dev tun2) inicované pravidlem  fwmark 1234 lookup vpn -- buď nějak vyhodnocování routy neskončí u tabulky vpn nebo  selže pravidlo all fwmark 1234...

Dokonce si myslím, že bych si vystačil i s pravidlem ip rule add iif tun2  -jMARK 1234 ; ip rule add fwmark 1234 oof tun2 (schématicky, hypoteticky) bez nutnosti iptables

nemůže tam být nějaký problém s prioritou tabulek a prioritou pravidel? Když rule určí podle jaké tabulky routovat, a nevyhoví žádná routa, postupuje se podle dalších tabulek? Žeby to probublalo až k main?

Musím napsat, co vlastně je cílem.  Nějak to z toho nevyplývá. Port forwarding z dostupného VPS do interní sítě. Tedy pro příchozí spojení z internetu na  počítače vevnitř. (což jsou ty záznamy na vps ip route -tnat PRE -dport 80 --to 192.168.0.N:8080,  8022 -> 192.168.0.1:22 ,etc)
Taky jsem nezmínil, že na tom VPSmám logicky ip route add 192.168.0.0 via 192.168.0.1 dev tun2. Ano, je to přes ssh -w. Bez žádných konfiguračních skripů, protože to právě se snažím zprovoznit.

Nemám ani 2 ISP ani nemám VPN na způsob "veškerý traffic přes VPN", ale ta "VPN" jen spojka mezi VPS a sítí za routerem, a to co chci zvenku dostupné řeším na tom VPS těmi DNATy
(To pak nějak mění koncepci použití toho značkování, že se vlaastně značkuje inverzně, nebo aby se to nezacyklilo nebo v případě 2 isp se značkuje "horizontálně")

Na nějaké odkazy na stack overflow jsem koukal. Ale 

Mezitím jsem si přidal pravidla do mangle: (jen odmazáno 0.0.0.0/0 aby se to vešlo na šírku)
PRE:  126  6812 CONNMARK   all  --  tun2   *       ctstate NEW CONNMARK set 0x4d2
FWD:  919 48108 MARK       all  --  *      *       connmark match  0x4d2 MARK set 0x10e1
OUT:  946 95784 MARK       all  --  *      *       connmark match  0x4d2 MARK set 0x10e1

Podíval jsem se to conntrack -L |grep -Pi 'mark=\d\d'


Vantomas: tenhle link jsem neviděl. Vyzkouším --save mark a restore-mark, ale iptables -j MARK vidím poprvé.

Tazatel přesměruje pakety z internetu ("klient.cz" mířící na "vps.cz") skrz tunel do lokální sítě která je "za-natem.cz". Zařízení v lokální síti dostane paket se zdrojovou adresou "klient.cz" a odpoví na něj - posláním odpovědi na "klient.cz". Výsledkem je, že klient.cz dostane paket

To je jen detail a důsledek, ale  dodám, že odpověď ke klientovi nedorazí, ze 5 důvodů:
- může být taky za NATem, pak ji zařízne jeho ISP
- 192.168 neprojde internetem
-odejde poj jinou src IP, tcp stack protistrany  si to nedá dohromady i kdyby neměl nat
-zablokuje ji můj ISP (protože přímo z mého WAN odchází src roszah mé interní sítě)
 ale hlavně ji zablokuje můj firewall ( -I FORWARD -s 192.168.0/24 -o wan -j  REJECT)   (v podstatě kontrola z předchozího řádku; jen na blíže-na mém perimetru)


Výpis:

Kód: [Vybrat]

0:      from all lookup local
32764:  from all fwmark 0x10e1 lookup vpn
32765:  from 10.2.0.0/24 lookup vpn
32766:  from all lookup main
32767:  from all lookup default
#ip r s t vpn (ať žijou zkratky)
default via 10.2.88.2 dev tun8
192.168.1.0/24 via 192.168.1.208 dev eth0

[Vietnamka]

Hmm, tak mi to zase nenávratně ztratilo odpověď. Co se vyhodnocuje dřív? pravidla iptables nebo ip rule?
Narazil jsem totiž v tom linku na

For each inbound packet kernel checks "reverse path". Kernel swapps inbound packet's source and destination and check via what interface it will be routed in reverse direction by consulting routing table. In this check kernel doesn't respect packet's mark (fwmark).

Napadlo mě že nerespektování Clocka fwmarku může souviset i s vyhodnocováním pravidel v iptables.

mám tam: ... -o wlan0 -j REJECT a vyhoví a přitom   REJECTNUTÍ je předčasné na nějakém předčasném závěru, protože by měl být pomocí pravidla mu změněna routa na tun2

[Vietnamka]

Tak vyřešeno sláva !
Přišel jsem na to.  pravidlo CONNMARK restore musí být taky v PREROUTING a nestačí v forward. Máte vysvětlení?


TZN

-A PREROUTING -i tun2 -m conntrack --ctstate NEW -j CONNMARK --set-mark 7 # označí vstupní pakety z internetu objevšivší se na tun
-A OUTPUT -j CONNMARK --restore-mark   # (pro lokální procesy)
-A PREROUTING -j CONNMARK --restore-mark # ( paradoxně pro forwardování)
# ip rule add fwmark 7 table vpn

Mám k tomu otázku, je toto výkonově  optimální? V tom smyslu, že --restore connmark se volá bez zúžení ? jako označování je zúžené volnou -i tun2 , tak bych si třeba představoval, že PREROUTING -restore-mark bude upřesněné ... čím? -s 192.168.1.8 nebo lepší tip? Nebo je to zbytečné


Druhá otázka pro fajšmekry: Myslel jsem, že by pravidlo pro označování paketů set-mark by mělo stačit až ve forwardu, ale takový
čím to je? (že)  modul conntrack potřebuje ke své práci prerouting a forward je moc pozdě? z obrázku mi to ale nepšilo





A jak koukám na ten obrázek, nedokážu pochopit, kolikrát probíhá routing decision v případě forwardování paketů? jednou nebo dvakrát?



reference, který jsem zkoumal, ale stejně jsem v nich řešení nenašel
https://www.linuxquestions.org/questions/linux-networking-3/policy-routing-problem-with-fwmark-4175492857-print/
https://gist.github.com/gpolitis/512193dd88c18aeb6900229187198899
https://serverfault.com/questions/1107846/how-to-route-a-reply-packet-to-the-device-it-coming-from#
https://superuser.com/questions/950031/routing-subnet-to-specific-routing-table-with-fwmark-direct-to-isp-and-vpn

[snuff1987]

Je to uz davno co som nieco podobne riesil, ale bez problemov mi to fungovalo s pomocou --set-mark a matne si spominam ze som jednoducho hodil mark v mangle prerouting a nasledne ip rule set ....
restore-mark som nikde nepouzival, takze popravde netusim naco tato direktiva je.
Este som riesil aj traffic shaping na zaklade ToS, DSCP hlavicky v spojeni s TC a taktiez to fungovalo krasne.

Iptables vie vsetko, nikdy som sa nestretol s tym, ze by nieco nefungovalo, vsetko je len vecou praxe a prist na to, do ktorej chainy treba pisat pravidla.

A ano forward je neskoro pre zmenu routingu pomocou markovania, treba to davat do preroutingu.

[Petr Bahula]

Možná vám pomůže diskuze pod článkem https://www.root.cz/clanky/policy-based-routing-v-linuxu-smerovani-provozu-pod-kontrolou/, tam mi pan Radek Zajíc poradil https://www.root.cz/clanky/policy-based-routing-v-linuxu-smerovani-provozu-pod-kontrolou/nazory/1085076/

[František Ryšánek]

Přišel jsem na to.  pravidlo CONNMARK restore musí být taky v PREROUTING a nestačí v forward. Máte vysvětlení?

Odpověď se IMO přímo skrývá ve Vašem dotazu.

Na značku máte zavěšenu routovací tabulku, podle které se následně provede první "routing decision", poté jde paket do chainu FORWARD. Ve chvíli, kdy vstupuje do chainu FORWARD, už má rozhodnutý=definovaný outbound interface, proto např. lze v chainu FORWARD filtrovat podle iptables -o $OUT_IF .

Přesně proto je třeba, prokopírování značky z "conntrack entry" (mangling) provést už ve fázi PREROUTING - aby se podle značky dal paket vzápětí zařadit do konkrétní instance "routing table"... a "odroutovat" = rozhodnout výstupní rozhraní.

[Vantomas]

Vantomas: tenhle link jsem neviděl. Vyzkouším --save mark a restore-mark, ale iptables -j MARK vidím poprvé.

Rozdíl mezi MARK a CONNMARK je v tom, co se markuje. Jedno markuje pakety a druhé markuje connection. Iptables bohužel neumí přímo poslat paket do nějaké jiné routovací tabulky, to umí až "ip rule", ale ten zase neumí číst connection mark, protože to je institut co existuje v netfilter světě, ale umí číst packet mark.

Packet mark s paketem zůstává dokud paket protéka systémem, ale jak se zakončí na nějakým Apachi a ten pošle odpověď, tak se vytvoří pakety nové a ty už zase žádný packet mark nemají.

Do toho nám pak vstupuje connection tracking, který umí každý takovýhle paket přiřadit k nějakému spojení, které je uložené v tabulce a v tabulce je možné mít uloženou connection mark a podle toho pak něco dělat. Nově vytvořené pakety se k té connection nějak přiřazují sami, bez potřeby expresivního pravidla, ale CONNMARK se podle všeho obnovuje až na žádost.

Je možné, že v tom popisu jsou nějaké nepřesnosti, jsou to pro mě taková zákoutí o kterých vím, že existují, dokáži si je představit při nějakém debuggingu, ale jestli do toho nejdřív vstupuje jedno a pak druhé nebo je to obráceně, to fakt nevím.

[Vietnamka]

Nestihl jsem vše ještě vstřebat a reagovat, ale Zůstal mi nezodpovězen jeden dotaz

A jak koukám na ten(černobílý) obrázek, nedokážu pochopit, kolikrát probíhá routing decision v případě forwardování paketů? jednou nebo dvakrát? (nad a pod forward)

Bylo mi to divné, proč je tam 2x routing decision, nevím jak tomu rozumět. Tak se to rozhodne  jednou ne? K čemu dvakrát? Které má prioritu,
Teď mi asi svitlo. :

Je to tak, že
1. routing decision(<forward) určuje jestli skončí v local process ,nebo bude puštěn na nějaké výstupní síťové rozhraní
2. routing, D.C. (>forward) určí  na které konkrétní   (-o)  rozhraní půjde.
.že.
3. routing decision( vlevo, u~local process) mi zůstává záhadou
Moc jsem se upínal na grafickou stránku diagramu - viděl jsem 2 stejné boxíky

(teď mě napadá, je možné aby linux forwardoval z eth3 na eth3?) I když asi moc legitimní use-case mě nenapadají, a nebo to svědčí o špatně designované síti.

[Vantomas]

1. routing decision(<forward) určuje jestli skončí v local process ,nebo bude puštěn na nějaké výstupní síťové rozhraní

Může to tak být. To schéma je zjednodušené, dnes se na tom systému můžou provozovat VRF nebo nějaké různé network namespaces a tohle je zhruba místo, kde se o tom rozhoduje, kam se to zařadí.

2. routing, D.C. (>forward) určí  na které konkrétní   (-o)  rozhraní půjde.

Ve FORWARD už se ví kam ten paket půjde, takže prošlo zjištěním, že to není lokální proces i nějakým vyhodnocením skrze routovací tabulky a ip rule.

3. routing decision( vlevo, u~local process) mi zůstává záhadou[/b]

Lokální proces přijme paket a pak na něj chce zaslat odpověď. Routing decision tedy není o ničem jiném než o zjištění, kam se ty pakety mají poslat. Když se zjistí, že pro odpověď žádná cesta neexistuje, tak to ani do netfiltru nevstupuje.

(teď mě napadá, je možné aby linux forwardoval z eth3 na eth3?) I když asi moc legitimní use-case mě nenapadají, a nebo to svědčí o špatně designované síti.

Ano je to možné. V praxi se to třeba používá když chceme přeadresovat na síti rozsah ze staré na novou síť a chceme obě dvě sítě nechat nějaký čas paralelně běžět, abychom si vklidu oběhali počítače nebo vyčkali na vypršení DHCP a mezitím tyto počítače mezi sebou komunikují skrze default gw, kde to router odroutuje ze stejného na stejné rozhraní.

[František Ryšánek]

Proč je tam 2x "routing decision" blok: původní KTPD, ze kterého vychází Váš diagram, je v tomto bodě zřejmě mírně nepřesný. Našel jsem přesnější obrázek. Jak už zde psali druzí, ono se toho pod kapotou zřejmě děje ještě o něco víc, ale odpověď na Vaši otázku by tímto měla být jasná.