Redsocks luistert op loopback, maar VPN-verkeer komt nooit aan

Een tunnel komt op, de client kan de gateway pingen, en elk webverzoek via het proxypad sterft. Het redsocks-proces draait en de poort luistert, dus de dienst lijkt gezond vanaf de gateway zelf. Wat mislukt is de afleverstap: een pakket dat van de tunnel wordt omgeleid, landt niet op de socket die je hebt gestart. Het bindadres en het omleidingsdoel moeten overeenkomen, en meestal wordt er maar één van de twee gecontroleerd.

Waar een omgeleid pakket werkelijk landt

Transparante proxy op een gateway gebruikt REDIRECT in de nat-tabel bij PREROUTING om de bestemming van een inkomende verbinding naar een lokale poort te herschrijven. De herschreven bestemming is een lokaal adres zoals gezien vanaf de interface waarop het pakket binnenkwam, niet het loopbackadres van een proces dat elders is gestart. Een luisteraar die alleen aan 127.0.0.1 is gebonden, accepteert verbindingen die al lokaal op de host waren, en dat is precies het geval dat blijft werken terwijl tunnelverkeer mislukt. De eigen loopback van de client is een derde adres en is nooit het doel van de gatewayregel.

Dus voordat je de inloggegevens van de bovenliggende laag aanraakt, stel je twee feiten vast: naar welk lokaal adres de regel herschrijft, en aan welk adres de proxysocket is gebonden.

Lees de luisteraar en de omleidingsregel samen

Druk de sockettabel en de nat-regels in dezelfde doorgang af, want een regel die naar een poort wijst die niemand bezit, ziet er identiek uit als een regel die naar het verkeerde adres wijst. sudo ss -ltnp | grep redsocks toont het bindadres en het proces dat het bezit. sudo iptables -t nat -S PREROUTING toont het REDIRECT-doel, en sudo iptables -t nat -L PREROUTING -v -n toont of er iets bij paste.

Een sprong naar een gebruikersketen met de naam REDSOCKS bereikt niets tenzij die keten bestaat en de bedoelde uitsluitingen en de REDIRECT-actie draagt. Lees de keten waarheen hij springt met sudo iptables -t nat -S REDSOCKS in plaats van aan te nemen dat de naam het werk doet.

Vergelijk dan de twee waarden. Als de regel naar een gatewayadres op poort 12345 omleidt en de luisteraar meldt 127.0.0.1:12345, verklaart de mismatch het falen zonder enige verdere diagnose.

Bind nauw, beperk daarna wat het kan bereiken

De voorbeeldconfiguratie van de bovenliggende laag zet de luisteraar om een goede reden op loopback: een transparante proxy accepteert verbindingen namens iedereen die hem kan bereiken. De binding naar 0.0.0.0 wijzigen herstelt de aflevering en opent tegelijk de poort op elke interface, wat een beveiligingswijziging is, geen neutrale reparatie. Bind liever aan het specifieke lokale adres dat de omleiding beoogt, en houd de poort gesloten op niet-vertrouwde interfaces. Als een bredere binding onvermijdelijk is, voeg dan een firewallregel op de host toe die alleen het bronbereik van de tunnel en het eigen lokale verkeer van de gateway toestaat.

De poort op de openbare interface openen is nooit nodig voor omgeleid VPN-verkeer, omdat de verbinding na het herschrijven lokaal eindigt. Stel de proxy niet bloot aan het internet om een lokale omleiding te laten werken.

Bewijs het met een nieuwe verbinding vanaf een client

Test vanaf een echte VPN-client met een verse TCP-verbinding, niet vanuit een shell op de gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com op de client doorloopt het omgeleide pad van begin tot eind.

Bevestig daarna dat een directe verbinding naar de luisteraar vanaf een niet-vertrouwd netwerk nog steeds wordt geweigerd, en dat de eigen verbinding van de proxy naar boven niet opnieuw door dezelfde regel wordt gevangen. Recursieve onderschepping uit zich als een proxy die verbinding met zichzelf maakt en nooit een verzoek voltooit. Voeg de bestemming van de proxy toe aan de uitsluitingsset, of markeer zijn uitgaande pakketten zodat de keten ze overslaat.

Onthoud ten slotte wat dit pad niet dekt. Gewone redsocks TCP-omleiding maakt UDP, QUIC of DNS niet tot SOCKS-verkeer, en privébestemmingen vereisen meestal expliciete uitsluitingen. Een geslaagde lokale test bewijst alleen het loopbackpad dat nooit het probleem was.