Redsocks слуша на локална примка, но VPN трафикът така и не пристига

Тунелът се вдига, клиентът може да пингува шлюза, но всяка уеб заявка по пътя през проксито умира. Процесът redsocks работи и портът му слуша, така че услугата изглежда здрава от самия шлюз. Проваля се стъпката на доставяне: пакет, пренасочен от тунела, не попада на сокета, който сте стартирали. Адресът на връзката и целта на пренасочването трябва да съвпадат, а обикновено се проверява само едно от двете.

Къде всъщност попада пренасочен пакет

Прозрачното проксиране на шлюз използва REDIRECT в таблицата nat при PREROUTING, за да пренапише дестинацията на входяща връзка към локален порт. Пренаписаната дестинация е локален адрес, както се вижда от интерфейса, по който е пристигнал пакетът, а не адресът на локалната примка на процес, стартирал другаде. Слушател, вързан само към 127.0.0.1, приема връзки, които вече са били локални за хоста, и това е точно случаят, който продължава да работи, докато трафикът през тунела се проваля. Собствената локална примка на клиента е трети адрес и никога не е цел на правилото на шлюза.

Затова, преди да пипате идентификационните данни за горното ниво, установете два факта: към кой локален адрес пренаписва правилото и към кой адрес е вързан сокетът на проксито.

Четете слушателя и правилото за пренасочване заедно

Отпечатайте таблицата на сокетите и правилата на 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, несъответствието обяснява провала без никаква допълнителна диагностика.

Вържете тясно, после ограничете какво може да го достигне

Примерната конфигурация от горното ниво по подразбиране слага слушателя на локалната примка с основателна причина: прозрачното прокси приема връзки от името на всеки, който може да го достигне. Промяната на връзката към 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 трафик, а частните дестинации обикновено изискват явни изключения. Успешен локален тест доказва само пътя през локалната примка, който никога не е бил проблемът.