Redsocks harket op loopback, mar VPN-ferkear komt nea oan

In tunnel komt op, de klant kin de gateway pingje, en elk weboanfraach fia it proxy-paad stjert. It redsocks-proses rint en syn poarte harket, dat de tsjinst liket sûn fan de gateway sels. Wat mislearret is de leveringsstap: in pakket dat fan de tunnel trochstjoerd wurdt, lânet net op de socket dy't jo start hawwe. It binadres en it trochstjoerdoel moatte oerienkomme, en meastentiids wurdt mar ien fan beide kontrolearre.

Wêr't in trochstjoerd pakket eins lânet

Transparante proxy op in gateway brûkt REDIRECT yn 'e nat-tabel by PREROUTING om de bestimming fan in ynkommende ferbining nei in lokale poarte te skriuwen. De oerskreaune bestimming is in lokaal adres sa't de interface dy't it pakket binnenkaam it sjocht, net it loopback-adres fan in proses dat earne oars start is. In lústerder dy't allinnich oan 127.0.0.1 bûn is, akseptearret ferbiningen dy't al lokaal wiene op de host, en dat is krekt it gefal dat bliuwt wurkjen wylst tunnelferkear mislearret. De eigen loopback fan de klant is in tredde adres en is nea it doel fan 'e gateway-regel.

Dat, foardat jo de upstream-gegevens oanreitsje, stel twa feiten fêst: nei hokker lokaal adres de regel oerskriuwt, en oan hokker adres de proxy-socket bûn is.

Lês de lústerder en de trochstjoerregel tegearre

Print de sockettabel en de nat-regels yn ien trochgong, want in regel dy't nei in poarte wiist dy't nimmen hat, liket identyk op in regel dy't nei it ferkearde adres wiist. sudo ss -ltnp | grep redsocks lit it binadres en it besittende proses sjen. sudo iptables -t nat -S PREROUTING lit it REDIRECT-doel sjen, en sudo iptables -t nat -L PREROUTING -v -n lit sjen oft der wat by paste.

In sprin nei in brûkerskeatling mei de namme REDSOCKS berikt neat, útsein as dy keatling bestiet en de bedoelde útslutings en de REDIRECT-aksje draacht. Lês de keatling dêr't er nei springt mei sudo iptables -t nat -S REDSOCKS ynstee fan oan te nimmen dat de namme it wurk docht.

Fergelykje dan de twa wearden. As de regel nei in gateway-adres op poarte 12345 trochstjoert en de lústerder rapportearret 127.0.0.1:12345, ferklearret de ôfwiking it mislearjen sûnder fierdere diagnoaze.

Bin smel, en behein dan wat it berikke kin

De foarbyldkonfiguraasje fan upstream set de lústerder om in goede reden op loopback: in transparante proxy akseptearret ferbiningen namme fan wa't it ek berikke kin. De bining nei 0.0.0.0 feroarje reparearret de levering en iepenet tagelyk de poarte op elke interface, wat in feiligensferoaring is, gjin neutrale reparaasje. Bin leaver oan it spesifike lokale adres dat it trochstjoeren rjochtet, en hâld de poarte ticht op net fertroude interfaces. As in bredere bining net te mijen is, foegje in host-firewallregel ta dy't allinnich it boarneberik fan de tunnel en it eigen lokale ferkear fan de gateway tastiet.

It iepenjen fan de poarte op 'e iepenbiere interface is nea nedich foar trochstjoerd VPN-ferkear, om't de ferbining lokaal einiget nei it oerskriuwen. Stel de proxy net oan it ynternet bleat om in lokale trochstjoering wurkje te litten.

Bewiis it mei in nije ferbining fan in klant

Test fan in echte VPN-klant mei in frisse TCP-ferbining, net fan in shell op de gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com op de klant beoefenet it trochstjoerde paad fan begjin oant ein.

Befêstigje dan dat in direkte ferbining nei de lústerder fan in net fertroud netwurk noch altyd wegere wurdt, en dat de eigen upstream-ferbining fan 'e proxy net wer troch deselde regel fongen wurdt. Rekursive fanging docht bliken as in proxy dy't himsels ferbynt en nea in oanfraach foltôget. Foegje de bestimming fan 'e proxy ta oan 'e útslutingsset, of markearje syn útgeande pakketten sadat de keatling se oerslacht.

Ta beslút, tink derom wat dit paad net dekt. Gewoane redsocks TCP-trochstjoering makket UDP, QUIC of DNS net ta SOCKS-ferkear, en privee bestimmingen hawwe meastentiids eksplisite útslutings nedich. In slagge lokale test bewiist allinnich it loopback-paad dat nea it probleem wie.