Dante SOCKS на loopback для HTTPS-сервиса только через WireGuard

Привяжите отдельный SOCKS-слушатель к loopback и разрешите одно TCP-назначение. Держите отдельно исходящий источник Dante, маршрут ядра, DNS и политику потери туннеля.

Этот документ даёт приложению, знакомому с прокси, доступ к существующему пути WireGuard, не публикуя прокси-порт на сервере VPN или в интернете. Демон SOCKS предоставляет интерфейс приложения, WireGuard предоставляет уже одобренный IP-путь, и ни один из них не выполняет аутентификацию пользователя за вас. Каждый шаг ниже даёт что-то, что можно проверить, и у каждого есть откат: остановите экземпляр, удалите правило или уберите настройку прокси в приложении. Ничто здесь не меняет маршрут по умолчанию хоста.

Пример предполагает, что Dante 1.4.x установлен как отдельный управляемый экземпляр на доверенной рабочей станции Linux, а служебная учётная запись и конфигурация журналирования из пакета оставлены на месте. Рабочая станция владеет 10.77.0.2 на своём интерфейсе WireGuard, достигает 10.60.0.20:443 через этот туннель, а правильное имя сервиса — app.corp.example.

Шаг 1: привяжите слушатель только к loopback

Поместите разделы сети, метода и правил в активную конфигурацию экземпляра, заменив примерные адреса. Все настройки сервера идут перед блоками правил:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

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

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

Шаг 2: напишите два правила, а не одно

Справочник по конфигурации Dante даёт двум типам правил разные задачи. Правило клиента допускает подключение к слушателю loopback, и его назначением является адрес самого слушателя. Правило SOCKS разрешает запрошенное дальнейшее подключение к одобренному хосту и порту. Несовпадающие запросы блокируются по умолчанию, поэтому отсутствующее правило выглядит точно так же, как сломанный маршрут.

Обратите внимание, чего эта конфигурация намеренно не делает: она не запрашивает пароль SOCKS. Это подходит для доверенного локального хоста, и это не аутентификация пользователя. Любой другой процесс на этой машине тоже может использовать loopback. Сохраняйте собственную аутентификацию удалённого приложения и не используйте повторно эту неаутентифицированную форму для недоверенных локальных пользователей или слушателя, обращённого в LAN.

Шаг 3: проверьте маршрут из правильного источника

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

ip -4 route get 10.60.0.20 from 10.77.0.2

Выполняйте это в реальном сетевом пространстве имён Dante, а не в любой случайно открытой оболочке. Маршрут, выбор партнёра WireGuard, разрешение на удалённой стороне и обратный путь должны соответствовать этому адресу источника. Успешный запрос необходим, но недостаточен, потому что он ничего не говорит о том, принимает ли дальний конец запрос.

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

Шаг 4: тестируйте с предполагаемой идентичностью

После того как владелец проверит установленную конфигурацию и запустит экземпляр через свой менеджер служб, примерный запрос выглядит так:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

С socks5h Dante выполняет разрешение назначения, но Dante работает на этой рабочей станции, поэтому настройка сама по себе не отправляет DNS на дальний конец туннеля. Одобренный резолвер, который использует Dante, должен вернуть разрешённый адрес для этого имени. Пустой список без прокси не даёт унаследованному исключению тихо обойти SOCKS.

Сохраните в тесте проверку имени хоста и сертификата HTTPS, затем проверьте реальный слушатель и подтвердите обе половины контракта: разрешённый запрос проходит, а исключённое назначение — нет. Также убедитесь, что неподдерживаемые команды пересылки остаются запрещены, потому что этот фрагмент разрешает команду SOCKS CONNECT по TCP и ничего похожего на общий UDP- или туннель всего устройства.

Шаг 5: решите, что происходит при падении туннеля

Проверьте потерю туннеля и перезапуск экземпляра, прежде чем называть это производством. Супервизор, запускающий Dante после WireGuard, не создаёт fail-closed маршрутизацию и не создаёт fail-closed DNS; и то и другое должно обеспечиваться владельцем сети. Наблюдайте, что делает приложение при упавшем туннеле: чистая ошибка — хороший результат, тихий переход на публичный резолвер — нет.

Согласовывайте обновления, если привязанный адрес туннеля меняется, потому что external прикреплён к нему. Когда схема больше не нужна, выведите этот экземпляр и настройку прокси приложения вместе и оставьте путь WireGuard тому, кто им владеет.

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