Redsocks слуша на loopback-у, али VPN саобраћај никада не стиже

Тунел се подиже, клијент може да пингује гејтвеј, али сваки веб захтев кроз путању проксија умире. Процес redsocks ради и његов порт слуша, па услуга изгледа здраво са самог гејтвеја. Оно што не успева јесте корак испоруке: пакет преусмерен са тунела не слеће на сокет који сте покренули. Адреса везивања и циљ преусмеравања морају да се поклопе, а обично се проверава само једно од њих.

Где преусмерени пакет заиста слеће

Транспарентни прокси на гејтвеју користи REDIRECT у nat табели на PREROUTING да препише одредиште долазне везе на локални порт. Преписано одредиште је локална адреса виђена са интерфејса на који је пакет стигао, а не loopback адреса процеса покренутог негде другде. Слушалац везан само на 127.0.0.1 прихвата везе које су већ биле локалне на хосту, и то је управо случај који наставља да ради док саобраћај кроз тунел не успева. Сопствени loopback клијента је трећа адреса и никада није циљ правила гејтвеја.

Зато пре него што дотакнете акредитиве горњег нивоа, утврдите две чињенице: на коју локалну адресу правило преписује и на коју адресу је везан сокет проксија.

Читајте слушаоца и правило преусмеравања заједно

Испишите табелу сокета и nat правила у једном пролазу, јер правило које показује на порт који нико не поседује изгледа исто као правило које показује на погрешну адресу. sudo ss -ltnp | grep redsocks приказује адресу везивања и процес који је поседује. sudo iptables -t nat -S PREROUTING приказује циљ REDIRECT, а sudo iptables -t nat -L PREROUTING -v -n показује да ли се нешто с њим поклопило.

Скок на кориснички ланац назван REDSOCKS не постиже ништа ако тај ланац не постоји и не носи предвиђена искључења и радњу REDIRECT. Читајте ланац у који скаче помоћу sudo iptables -t nat -S REDSOCKS уместо да претпостављате да име обавља посао.

Затим упоредите две вредности. Ако правило преусмерава на адресу гејтвеја на порту 12345, а слушалац пријављује 127.0.0.1:12345, неслагање објашњава неуспех без икакве даље дијагностике.

Вежите уско, затим ограничите шта може да га достигне

Пример конфигурације горњег нивоа подразумевано ставља слушаоца на loopback с добрим разлогом: транспарентни прокси прихвата везе у име свакога ко може да га достигне. Промена везивања на 0.0.0.0 поправља испоруку и истовремено отвара порт на сваком интерфејсу, што је безбедносна промена, а не неутрална поправка. Радије вежите на конкретну локалну адресу коју преусмеравање циља и држите порт затвореним на неповерљивим интерфејсима. Ако је шире везивање неизбежно, додајте правило хостовог заштитног зида које дозвољава само опсег извора тунела и сопствени локални саобраћај гејтвеја.

Отварање порта на јавном интерфејсу никада није потребно за преусмерени VPN саобраћај, јер се веза завршава локално после преписивања. Не излажите прокси интернету да би локално преусмеравање прорадило.

Докажите то новом везом са клијента

Тестирајте са правог VPN клијента свежом TCP везом, не из љуске на гејтвеју. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com на клијенту пролази преусмерену путању од почетка до краја.

Затим потврдите да је директна веза ка слушаоцу из неповерљиве мреже и даље одбијена и да сопствена горња веза самог проксија није поново захваћена истим правилом. Рекурзивно хватање се појављује као прокси који се повезује сам са собом и никада не завршава захтев. Додајте одредиште проксија у скуп искључења или означите његове одлазне пакете да их ланац прескочи.

Најзад, запамтите шта ова путања не покрива. Обично TCP преусмеравање у redsocks не претвара UDP, QUIC или DNS у SOCKS саобраћај, а приватна одредишта обично захтевају изричита искључења. Успешан локални тест доказује само путању кроз loopback која никада није била проблем.