L7 маршрутизация Squid+IPTables и WireGuard, или как завернуть трафик в тоннель на основе имени домена

[Mishochegg]

Маршруты поднимутся автоматически, если для поднятия тоннеля использовать wg-quick@wg0. Если поднимать тоннель средствами ip, маршруты нужно создавать отдельно. Окажусь у рабочего места - перепроверю.

[aborouhin]

Скрипты wg-quick, для сложных режимов маршрутизации, я использовать не люблю, так как диррективу AllowedIPs они воспринимают и как разрешение и как правила маршрутизации.

Если добавить в секцию [Interface] конфига wg параметр "Table = off" - то маршруты на подсети из AllowedIPs автоматически не создаются.

Сервисы, использующие ssl_v1.3 не проходять через peek. К таким сервисам относится Telegram и большиство банк-клиентов. Для этих сервисов создаётся файл ssl13.txt с указанием ip и подсетей

...и это сводит на нет смысл всей затеи, увы :( Если для части сервисов нам всё равно надо реализовывать регулярный ресолвинг хостнеймов в IP (а если мы хотим wildcards использовать - то и похитрее изворачиваться) - так в чём смысл плодить сущности и не сделать и всё остальное тем же способом?

[Mishochegg]

За table=off спасибо. Как говорится, rtfm.

Пул адресов для телеги вполне себе небольшой, и резолвить его не надо: просто находим список подсетей и адресов, вносим в файл и не mitm-аем имя сертификата. При этом трафик всё ещё идет через кальмара, и в статистике squid трафик даже будет отражаться, если есть задача вести логи. Банк-клиент тоже вряд-ли обращается к большому пулу адресов. Согласен, особенности работы ssl 1.3 с контексте прозрачного сквида вызывают фрустрацию...

Но, на данный момент, в продуктивной среде я использую прозрачный сквид для ограничения доступа в интернет на предприятии. Делать это по ip-адресам было бы неприятно. А тут всего (пока) два сервиса, которые требуют 1.3 .. Пока что можно сделать небольшой список подсетей и делать вид, что тебя это не беспокоит.

[aborouhin]

Ну у каждого свои вводные. Я пока такую задачу решаю через хуки DNS-сервера (просто ресолвить адреса раз в N часов не работает, т.к. часто нужны wildcards для всех доменов 3 уровня), но тоже много нюансов (после первого запроса к новому IP первое соединение уходит мимо, если мы не хотим тормозить ресолвинг; нужна нетривиальная логика инвалидации старых записей и т.п.) Прокси мне для других задач не нужен, поэтому для меня он лишняя сущность. Но если он уже есть - другое дело, конечно.

[vmx]

Я как-то делал вот такую очень простую утилиту https://github.com/vmxdev/sidmat

Она слушает на интерфейсе (с помощью pcap или nflog) DNS-ответы и печатает ip адреса доменов, которые матчатся регекспами. Можно сказать те же wildcards, только в виде регулярок. Там в документации есть примеры, как ее использовать с iptables/ipset.

То есть, если не хочется морочиться с хуками DNS-сервера, можно сделать и по-другому. Не знаю, проще это или нет.

[aborouhin]

Интересная штука для простых DNS-серверов, где нет встроенных средств для подобного. Но даже у unbound (то, что у меня сейчас, не совсем хуки, да) легко включается логирование всех запросов/ответов. Хочу попробовать перейти на technitium (там уже собственно хуки и много других полезных плюшек).

Но самая нетривиальная часть - не собрать запросы/ответы, а где-то их хранить и своевременно обновлять, иначе у нас очень быстро таблица маршрутизации неактуальным мусором засорится. Но и тупо дропать кэш/маршруты по таймеру не вариант. Ведь первый запрос, если мы не хотим добавлять задержку DNS-серверу (а мы не хотим), у нас будет выполняться параллельно тому, как клиент получит ответ и в этот первый раз всё же пойдёт по адресу не тем маршрутом, который задуман. Нежелательная ситуация, но один раз можно потерпеть, а вот регулярно повторять этот фокус уже совсем нехорошо. Т.е. в идеале нам нужно, как минимум:

a) по тем доменам, которые можно ресолвить заранее (где не маски/регекспы, а конкретное имя) так и делать, а при запросе просто уточнять, не устарел ли IP;

b) по тем доменам, где маски/регекспы, - пополнять список конкретных доменов при каждом подпадающем под них запросе;

c) по всем доменам из п.п. "a" и "b" в фоне регулярно проверять актуальность и обновлять IP;

d) при изменении списка доменов в настройках удалять из нашей базы записи, соответствующие удалённым вхождениям, и выполнять п. "a" для новых.

Если у нас несколько маршрутизаторов и DNS-серверов - всё становится ещё интереснее, т.к. разным серверам могут прилетать разные IP и нужен оперативный обмен данными (логика обновления записей при этом становится совсем неочевидной, т.к. если серверу Б прилетел другой IP, чем серверу А, это не значит, что серверу А тоже будет впредь прилетать этот новый IP, а не старый).

В общем, у меня всё это пока в виде недоделанного набора скриптов, где тоже не все перечисленные моменты учтены. Надо бы переписать заново с нуля красиво, но как обычно, пока вроде в основном и так работает - руки не доходят уже больше года с момента, как сформулировал для себя ТЗ :(

[vmx]

штука для простых DNS-серверов

Утилита задумывалась для произвольных DNS, даже для тех которые мы не контролируем.

Ставим ее на софтроутере/зеркале трафика (вроде ее кто-то запускал даже на OpenWRT, по крайней мере в форках было) и собираем себе адреса.

первый запрос, если мы не хотим добавлять задержку DNS-серверу (а мы не хотим)

Ну, я бы в этом месте не заморачивался. Задержка же небольшая.

Надо бы переписать заново с нуля красиво

Мне кажется, в 2026-м в сетях перфекционизм не очень нужен :)

И так все работает через одно место. В трафик активно вмешивается ТСПУ, операторский АнтиДДоС/Антифрод, происходят непредсказуемые ковровые баны сетей/AS и т.п. Тут хоть как-то бы все работало.