Fórum Root.cz
Hlavní témata => Server => Téma založeno: mikesznovu 07. 11. 2025, 12:43:43
-
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.
-
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.
-
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.....
-
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?
-
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.
-
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.
-
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
-
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.