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, який ніколи не був проблемою.