Port forwarding bez DNAT

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Klasicky si forwarduji porty z VPS přes iptables -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.1.8.1:80 , kde 10.1.0,0/16 je nějaký tunel, který nás v tuto chvíli nezajímá.

V dotazu mě zajímá, řešení na straně VPS. A to využívá conntrack a vlastně to modifikuje TCP segmenty - (přepisuje to volitelně-port a) mění to i cílovou adresu  IP, že?  Už asi víte kam mířím.

Je možná docílit i "port forwardingu" jiným způsobem, a to přes ip rule add dport 80 table pomocna; ip route add ??.??.??.?? via vpn Tím by totiž mohly chodit pakety bez nutnosti perestrojky (volitelně-portu a) dst IP. (A asi by bylo nutné udělat rovnák na dalších pár věcí na druhé straně tunelu...

Ono udělat port forwarding přes i ten pitomý DNAT --to chce alchymii s mangle-PREROUTING restore-mark a fwmark)

Jde to takhle? Jsou v tom nějaké praktické výhody? Jsou tam nějaká úskalí  vůbec stojí za to  ta složitější konfigurace(jelikož chodí defakto cizí dst IP, asi by se musel obměkčit rp-filter, "klonovat" ip adresa VPS) - to znamená, ža na druhém konci tunelu by musel soket poslouchat  na této IP vps nebo v nějakém "*" režimu

PS: pokud (ne nutně na konfiguraci výše) například spustím php -S "0.0.0.0:80", bude dostanou se do PHP procesu vůbec TCP streamy s dst IP , která neni mezi IP adresami stroje? Nebo jádro nejdřív provádí u příchozích  paketů kontrolu IP adres na všech rozhraních a propustí aplikaci jen typ toky, kde dst IP je některá z adres stroje.
A je tato kontrola provedena jen jednou v okamžiku spuštění naslouchacího procesu nebo je dynamická(když se přidají rozhraní nebo adresy na rozhraní)?

není i tohle nějaká opšna TCP, která právě aktivuje "roadwarrior"/"wildcard" režim naslouchání?

[Reklama]

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Pro upřesnění. Není použit  SNAT (server na konci tunelu vidí skutečné IP adresy klientů). Ale v dotazu  se naťukává  druhá IP adresa (serveru nebo tunelu). S DNATem je přepsáno na 10.1.8.x  (ip na rozhraní vpn), což by s pouhym routingem být nemohlo a adresa serveru by byla rovněž globální ipv4. o té server(myšleno OS toho pc,resp. Jeho ip stack) aptiory nemá tušo(až info vyšších vrstev jako $SERVER[local.addr)]

[Filip Jirsák]

Já teda nevím, kam míříte.

Port forwarding znamená, že provoz, který je směrován na určitou IP adresu a port, přesměrujete na jinou IP adresu – typicky do interní sítě na adresu, která není z venku přímo dostupná. To znamená, že musíte změnit cílovou IP adresu, což je NAT, konkrétně DNAT.

Manipulací s routovací tabulkou toho nedocílíte, protože routovací tabulka nemůže změnit paket – jenom rozhoduje o tom, kam (nezměněný) paket bude putovat.

Pokud byste nechtěl měnit cílovou IP adresu, nepotřebujete NAT – ale pak by to zase nebyl port forwarding.

pokud (ne nutně na konfiguraci výše) například spustím php -S "0.0.0.0:80", bude dostanou se do PHP procesu vůbec TCP streamy s dst IP , která neni mezi IP adresami stroje?

Proč si to prostě nevyzkoušíte? Když to teda potřebujete zjišťovat takhle, místo abyste se podíval na schéma, jak vypadá schéma routeru a firewallu v Linuxu, třeba zde: https://unix.stackexchange.com/questions/697888/during-the-lifecycle-of-iptables-in-which-step-will-kernel-take-advantage-of

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Aha, koukám , že název topicu byl přejmenován. Mělo tam být (navíc?) -jDNAT vs ip rule add dport pro zvýraznění že chci srovnat 2 metody jak přesměrovat traffic na cílové místo. Taky v druhym odstavci bylo "port forwarding" v" uvozovkách"


Šlo mi o pouhé forwardování paketů. Berte to tak , že dosavadní(první-DNAT)je způsob, jak dostat pakety na cílové místo a tento způsob holt přepisuje cílovou IP a možná port.

( psal jsem , že port je volitelné, je to jen speciální případ, kdy port v --to se rovná portu -dport )

[5nik]

Tuším o co vám jde, sám to občas používám. Na Mikrotiku je na to ve firewallu action=route v chainu prerouting tabulky mangle, jak to mají implementované v linuxu pod tím netuším. Ale v linuxu bych to (kdysi dávno) řešil přes označení paketů (route mark) a pak přes vlastní routovací tabulku. Tím docílíte toho, že vám označené pakety pošle router kam potřebujete bez modifikace adres / portů.
Odpověď k PS: Pokus si na tom stroji dáte jako sekundární IP tu veřejnou (jako máte na routeru), pak binding 0.0.0.0:80 bude zpracovávat i pakety s veřejnou dstIP přeposlané z routeru.

[Reklama]

[jjrsk]

Co takhle si nejdriv nacist neco o zakladech sitovani?

Aby cilovy stroj paket zpracoval, musi ten paket obsahovat jeho IP, proto ji tam DNAT da.

Pokud chci routovat ruzne pakety ruzne, nepotrebuju na to zadne markovani v mangle, pouziva se na to vice routovacich tabulek kde se treba pravidly rekne, ze kdyz je adresa v nejakem rozsahu, posle se to jinudy. Takto se ovsem pakety daji predat jen dalsimu routeru, ne cilovemu stroji.

[Filip Jirsák]

Pakety se na cílové místo dostávají na základě IP adresy cíle v paketu. Pokud je chcete poslat někam jinam, musíte v paketu změnit IP adresu cíle.

Samozřejmě byste si mohl naimplementovat vlastní síťový stack a v něm pakety směrovat podle něčeho jiného, než podle cílové IP adresy. Pokud byste si síť s vlastním síťovým stackem připojil k internetu tak, že by IP adresy použité uvnitř té vaší sítě byly na internetu správně routované na váš hraniční router, fungovalo by to. Ale proč byste něco takového dělal?

Tím docílíte toho, že vám označené pakety pošle router kam potřebujete bez modifikace adres / portů.

Buď je cílová IP adresa adresou toho routeru. Pak i když donutíte router poslat paket někam jinam, musel byste někde jinde mít další zařízení se stejnou IP adresou, které ty pakety přijme. Tím si ovšem uděláte v síti hrozný nepořádek, a nic tím nezískáte. Nebo byste tu adresu musel změnit někde jinde – a proč ji pak nezměnit hned na tom prvním routeru?

Nebo se to dá napsat ještě jinak – je mnoho kreativních způsobů, jak si rozbít síť. Ale proč to dělat? Když všichni postupují stejným způsobem, je dobré se toho držet a dělat to stejně – ono to asi má nějaký důvod, proč to tak všichni dělají. Případ, že to dělají všichni špatně, není moc pravděpodobný – a i kdyby nastal, tak když dokážete vymyslet lepší způsob, musíte také umět přesně pojmenovat, co je na tom současném způsobu špatně a také proč se to tak dělá. Pak se na to ale nebudete potřebovat ptát na Rootu…