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?