Nefunkční Nginx proxy_bind $remote_addr transparent

[mikesznovu]

Dobre,j , snazim se rozchodit  nginx v režimu proxy_bind $remote_addr transparent; (takovy hybrid mezi port forwardingem a normalni nginx proxy - ucel aby nginx resil https ,ale po tunelu a domaci siti chodily realne ip adresy na L3 vrstve.) setup : VPS v LXC  jako verejny server, , propojen pomoci wireguardu na GW za natem a backend  v siti za switchem (virtualizovany, ale to je jedno) . Vidim chybu 504 gw timeout . Dodam ze mi port forwarding s originalnima IP adresama po siti funguje  na jinem backendu vidtelnym pochopitelne na jinem portu nez 80/443, (je to resene prostym port forwardingem na VPS ne pres nginx -- proto mam pocit, ze je problem nekde v nginxu.. Adresni rozsah je stejny obou serveru.

analyzoval jsem traffic tcpdumpem. a paket probubla k backendu, a ten odesle SYN ACK a ta propluje tunelem a vidi ji tcpdump opet na VPS, ale mam pocit ,ze nginx  to nejak neprijme... Cili problem vidim na tom vps.

V dokumentaci nginx ngx stream module kde je direktiva popsana ctu neco ze musi bezet pod rootem nebo mit nejaky CAPS RAW NET. nebo pockat, musim to mit obaleny v stream direktive? Jediny co jsem udelal v konfigu je  ze pri zmene z normalniho reverse proxy, kdy mi to ovsem chodilo s L3 adresou rozsahu tunelu
proxy {server {location {proxy pass}}}
 jsem pridal zmineny proxy bind., a od te doby backend protlaci odpoved az dovnitr vps, ale nginx asi nezareaguje
Dodam, ze asi rp filter a firewall je poreseny, protoze prave podobny setup s "nahou L3 adresou" mi funguje v tom jinym pripadu, kdy nenasloucha nginx, ale jede to pres port forwarding.

[Reklama]

[Filip Jirsák (forum)]

Potřebujete zařídit, aby se packet s odpovědí vůbec dostal na server, kde běží ten nginx (tj. musíte tam routovat výchozí bránu). Musíte mít nastavené routování přímo na tom serveru, aby provoz na cizí IP adresy vůbec směroval do aplikace. A pak musíte mít nginx spuštěný tak, aby se k těm paketům pro cizí IP adresy dostal – jak píšete, musí mít CAPS_RAW_NET, případně běžet pod rootem.

[mikesznovu]

No to aby provoz na cizi adresy smeroval do aplikace, to si ten nginx zaridi? 
jak zjistim, ze ma caps_raw_net? spoustim ho pod rootem prikazem systemctl start nginx na LXC VPS. Vidim v htop :nginx master process ma root, workerirs maji www-data
Na ten vps se  ty pakety dostanou, to vidim z tcpdump. je ale potreba neco stelovat na firewallu, protoze kdyz o tom premyslim, jak vps/nginx pozna ,ze pakety SYN+ACK z tun SRC 192.168.5.BACKEND:443 DST 23.4.5.6:65444 maji projit nginxem? z komunikace projde jen prvni syn+ pak castecne syn-ack- dostane se na VPS a dal nevim.   nema tam taky byt nejaky ip rule  nebo mangle  i tady na vps? protoze v popisovane situace kde je jen port forwarding, sipackety odchyti pravidlo v prerouting ktere prepisuje je posila na 192.168.5.jinyserver
conntrack -L mi hlasi SYNC RECV

a mimochodem jsem schopny  mit proxy_bind 10.0.20.31 transparent;  funkcni (ppokud vps priradim krome 10.0.20.1 i tuto) - jenze to mi nepomuze ,protoze pak positi jsou vsechny requesty s touhle sloucenou adresou akorat je tam 31 misto 1

a prirozene "proxy_bind $remote_addr ;" hlasi cannot bind.....

[Filip Jirsák (forum)]

No to aby provoz na cizi adresy smeroval do aplikace, to si ten nginx zaridi?

Pochybuju. To musí být nastaví routování v jádře – musí ty cizí IP adresy routovat jako by patřily danému počítači, aby je neroutoval pryč.

jak zjistim, ze ma caps_raw_net? spoustim ho pod rootem prikazem systemctl start nginx na LXC VPS. Vidim v htop :nginx master process ma root, workerirs maji www-data

Pokud hlavní prcoes běží pod rootem, nginx dokáže tu capability worker procesům předat.

Na ten vps se  ty pakety dostanou, to vidim z tcpdump. je ale potreba neco stelovat na firewallu, protoze kdyz o tom premyslim, jak vps/nginx pozna ,ze pakety SYN+ACK z tun SRC 192.168.5.BACKEND:443 DST 23.4.5.6:65444 maji projit nginxem? z komunikace projde jen prvni syn+ pak castecne syn-ack- dostane se na VPS a dal nevim.   nema tam taky byt nejaky ip rule  nebo mangle  i tady na vps? protoze v popisovane situace kde je jen port forwarding, sipackety odchyti pravidlo v prerouting ktere prepisuje je posila na 192.168.5.jinyserver

To je právě to, že tohle musí být nastavené v routovacích tabulkách jádra. Nevím z hlavy, jak se to dělá – ale standardně máte v routovací tabulce dvě možnosti. Jedna je, že se paket směruje na next hop dál do sítě, a druhá (která se normálně nastavuje jen pro lokální IP adresy), že se ten paket zpracovává lokálně a pošle se tedy naslouchající aplikaci. No a vy potřebujete, aby se ten druhý typ použil i pro pakety, které mají libovolnou cílovou IP adresu, zdrojový port je 443 a zdrojová IP adresa je adresa toho cílového serveru.

Jinak teda osobně bych se na tohle vykašlal, normálně bych nginx nastavil, ať to dál přeposílá pod svou IP adresou a IP adresu zdroje ať cpe do hlavičky X-Forwarded-For. Jaký máte důvod posílat to dál s tou původní IP adresou?

[mikesznovu]

Na zkousku jsem zmenil na nginxu listen port na 4943 aby se mi to lepe hledalo. na FW je vse ACCEPT
nginx pouziva nejaky dynamic bind, znamena to ,ze v momente, kdy nginx posle SYN do backendu, uvidim v ss -4 -l -t -p navic radek  ? momentalnne vidim v nginu ze posloucha n 0000:4943

nepomohlo mi ani pravidlo:
iptables -t mangle -I PREROUTING -p tcp -m tcp --sport      443  -s 192.168.5.103 -j TPROXY --on-port 4943 (hit counter se zvysuje)

ani
iptables -t nat -I PREROUTING -p tcp -m tcp --sport      443  -s 192.168.5.103 -j REDIRECT --to 4943 (nuly)

nicmene me napad jedna vec, zda probvlem nenim, ze webappka posila redirect na domenu, pokud se pristupuje z ip adrey, jenze to je nesmysl, protoze zpetny  SYN,ACK nginx neodesle.

[Reklama]

[mikesznovu]

Ale kdyz premyslim o tech pravidlech firewallu, mam pocit, ze jsou zbytecna(ze use case je kdyz to server ma poslouchat), protoze nginx je ten , ktery iniciuje spojeni TCP SYN na 192.168.5.103:443 z "umele internetove adresy 31.32.33.33:54440 ... a zpet prijde SYN.ACK, ale k odeslani SYN.ACK nazpet uz nedojde.

[mikesznovu]

vlastne proc to chci: chci mit moznost filtrovat/logovat podle L3 v serverovne, takhle mi tam proudi  smichane 10.0.20.1, maximalne 10.0.20.x , pokud si tam praci a aspon rozlisim  z jakeho site.conf to jde, coz je stejne na nic
bohuzel selhaly pokusy zjistit jake ma proce capability, getcaps ani pscap nemam ani nejdou nainstalovat, baliky neexistuji

https://www.baeldung.com/linux/process-needed-capabilities

[Filip Jirsák (forum)]

Pořád řešíte capabilities, které jsou ale s největší pravděpodobností v pořádku - rodičovský proces nginx běží pod rootem a nginx se stará sám, aby tu capability předal workerům. Chyba je podle mne v routování, nikde jste nepsal, že byste routování nakonfiguroval.

[mikesznovu]

Dobre,zeptam se jinak. Proc mi to nefunguje  ani s jednim  ze dvou mangleTPROXY/natREDIRECT routovacim pravidlem v iptables "-I PREROUTING -p tcp -m tcp --sport      443  -s 192.168.5.103 -j..." a jake (nebo dalsi?) routovaci pravidlo bych tam mel mit?

rozsahy v routovaci tabulce mam, jinak by mi nefungoval podobny scenar tunelovani trafficu na  podobny(dokonce i stejny) server uvnitr site  na druhym konci tunelu ale v rezimu port forwardingu (nginx je vyskrnut a resi to NAT PREROUTING - DNAT 192.168.5:123) - default routa je na odchozim eth0 vps, 192 je na vpn interface a 10. je podobna routa jako na vpn akorat s scope link a src 10.... navic

a ted me trochu znejistila jedna dve tri veci. druha vec  :TPROXY, v tech dvou  pravidlech je u REDIRECT --to-port povinne a u kdyz odhlednu, ze u TPROXY se to pro zmenu   jmenuje --on-port, tak on-port ma volbu 0, coz je It is a required option, 0 means the new destination port is the same as the original. To jsem taky zkousel ale bez vysledku
(man iptables extensions, odstavec TPROXY nebo REDIRECT)

preci kdyz na to koukam, tak chodi pakety s IP adresami 192.168.5.1:4433 (pevne dany par) a 45.6.7.8:XXX (internetova adresa a cislo portu je nahodne a jeste k tomu jde o "prevzatou adresu" kterou prave nginx vyplni jako source diky proxy bind a transparent) a kdyz na tohle zacne koukat routing tabulka, tak zjisti, ze bez iptables pravidel v  ve smeru z nginx do site projde OK, routa do 192 existuje, coz potvrzuje to, ze server vrati odpoved(mysleno Tcp syn+ack) a dokonce dorazi opet na vpn interface pres tunel.  ale zde routing vidi, ze DST je internetova adresa a ze bez  dodatecneho pravidla by odesel paket rovnou do internetu a nikoliv do nginxu --- to jsem ani neocekaval, ze to nginx prijme bez zadnoho pravidla, ale zahadou je mi, proc pravidlo redirect nezabirat (hit count 0) a TPROXY nezsfunguje

proc to pisu, proc me to znejistilo - prvni vec co me znejistila (omlouvam se za retrospektivu) jsou prave ta cisla portu : a jestli to nedelam obracene nespravne  -

• 1 je spravne ze tproxy/redirect pravidla jsou specifikovana pres src ip a src port (192.168.5 ...:4433) ??
• 2.mam pocit ze --toport u REDIRECT je zjevne spatne, protoze na teto strane jde o nahodny port a tim padem smysl  asi bud emit jen TPROXY --on-port 0 ?? coz je prave to "same as original"

ale proc to nejde?

[Filip Jirsák (forum)]

iptables nenastavuje routovací pravidla. iptables nastavuje firewall a NAT. Routovací pravidla (která vybírají konkrétní routovací tabulku) se nastavují pomocí ip rule, routovací tabulky pomocí ip route.

Ten scénář, který vám funguje, je úplně něco jiného. Tam nepoužíváte v aplikaci falešné IP adresy. Pracujete tam s TCP/IP spojením jen na úrovni jádra, ty pakety se neposílají do aplikace – jenom se routují a NATem se ty pakety modifikují.

bez  dodatecneho pravidla by odesel paket rovnou do internetu a nikoliv do nginxu[/b] --- to jsem ani neocekaval, ze to nginx prijme bez zadnoho pravidla, ale zahadou je mi, proc pravidlo redirect nezabirat (hit count 0) a TPROXY nezsfunguje

Protože tam žádná speciální routovací pravidla nemáte – teda aspoň jste je nevypsal. To, co jste vypisoval, je firewall, který s tím nemá nic společného (v kontextu problému, který řešíte).