Dante SOCKS через VPN: полный туннель или маршрутизация по источнику

Два способа пропустить через туннель только SOCKS-прокси: заменить маршрут по умолчанию или привязать один адрес источника к своей таблице. Они отказывают по-разному.

Вы хотите, чтобы трафик SOCKS-прокси выходил через VPN, а остальная часть хоста сохраняла обычный путь. Это делают два решения, и они различаются тем, что ломается, когда что-то идёт не так. Одно заталкивает маршрут по умолчанию в туннель и затем обходит его; другое оставляет главную таблицу в покое и отправляет единственный адрес источника во вторую таблицу. Второе чище, и у него есть свои ловушки.

Два решения, два разных радиуса поражения

Решение с полным туннелем — это то, что большинство VPN-клиентов делают по умолчанию: заменяют маршрут по умолчанию, чтобы всё шло через туннель, а затем исключают то, что не должно. О нём легко рассуждать и трудно держать его узким, потому что каждая добавленная локальная служба наследует туннель, пока вы её не исключите. Режим отказа широк, так как один неверный маршрут уносит с собой и связность самого хоста.

Решение с выбором по источнику идёт в обратную сторону. Главная таблица остаётся как была, и одно правило политики отправляет пакеты с определённого локального адреса в таблицу с маршрутом по умолчанию через туннель. Больше ничего не меняется, то есть радиус поражения — один адрес.

Эта узость — одновременно и ограничение: решение работает только если исходящие пакеты прокси действительно несут этот адрес.

Что делает параметр external в Dante

Параметр external выбирает адреса, которые прокси использует для исходящих соединений; он не трогает политику маршрутизации ядра. Именно это разделение делает возможным второе решение, и именно здесь люди читают документацию неправильно. Указание external на адрес туннеля заставляет прокси устанавливать соединения с этого адреса, а таблица маршрутизации затем решает, куда пойдут эти пакеты.

Слушатель — отдельный вопрос. Держите internal ограниченным клиентами, которым следует пользоваться прокси, требуйте аутентификацию и закрывайте порт межсетевым экраном, потому что открытый слушатель не является свойством выхода через VPN.

Убедитесь, что настроенный адрес действительно принадлежит туннелю внутри сетевого пространства имён прокси.

Построение таблицы с выбором по источнику

Для адреса TUN 10.90.0.2/24 с достижимым партнёром на 10.90.0.1 и номером таблицы, который больше никто не использует, схема выглядит так:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

Недостижимый маршрут — это та часть, которую люди пропускают. Без него таблица, у которой исчез маршрут через туннель, проваливается на обычный маршрут по умолчанию, и прокси молча уходит через WAN. С ним поиск завершается неудачей, а это видимый отказ вместо тихой утечки. Приоритет правила также должен стоять впереди всего остального, что соответствует этому источнику.

Эти значения описывают одну топологию. Партнёры «точка-точка», адресация net30 и клиенты, выдающие другой префикс, нуждаются в своих маршрутах, поэтому копируйте форму, а не адреса.

Где утекает правило источника

Правило, соответствующее адресу источника, влияет на каждый процесс, который его использует, а не только на прокси. Если другой демон привяжет тот же адрес, его трафик тоже пойдёт через туннель, и отказ будет выглядеть как проблема несвязанной службы. Дайте прокси адрес, который больше никто не использует, или примите, что область — это адрес, а не процесс.

DNS — вторая утечка. Сокет резолвера не обязательно использует источник исходящих данных прокси, поэтому поиск имён всё ещё может уходить через WAN. Проверяйте разрешение отдельно от установления соединения и решите, приемлем ли такой результат.

IPv6 нужны свои правила и маршруты, потому что схема IPv4 ничего о нём не доказывает.

Выбирайте по отказу, который можете выдержать

Выбирайте полный туннель, когда хост нужно защищать целиком и вы можете поддерживать список исключений. Выбирайте маршрутизацию по источнику, когда хост должен сохранить свой путь и перенаправить нужно только одну службу. Оба варианта законны; ошибка — выбрать один, а затем проверять его так, будто это другой.

Что бы вы ни выбрали, проверяйте с обеих сторон: запрос через прокси и прямой запрос с хоста, с записью наблюдённого адреса выхода для каждого.

Если туннель упадёт, заранее решите, должен ли прокси отказать или отступить, и позвольте таблице маршрутизации выразить это решение.

Похожие статьи