В туннель направляйте только порт 25, а не хост

Четыре вещи должны совпасть, прежде чем хост Linux будет отправлять через туннель только свой SMTP: маршрут в отдельной таблице, правило политики, выбирающее трафик, адрес источника, который примет peer, и обратный путь, выдерживающий асимметрию. Каждая из них — отдельная конфигурация со своим режимом отказа. Порядок ниже позволяет отказу указывать на ту часть, которая действительно неверна. Это задача маршрутизации, специфичная для порта, а не запрос маршрута по умолчанию через VPN.

Правило порта — не маршрут по умолчанию

Правило, сопоставляющее локально созданный TCP с портом назначения 25, отправляет этот трафик в таблицу, которую вы назовёте. Само правило ничего не создаёт: оно выбирает, а таблица должна содержать маршрут, способный пронести пакет. Вместе они охватывают только исходящее направление одного протокола, поэтому пересылка для других хостов, входящие почтовые соединения и IPv6 остаются вне этой схемы. Если называть это политикой для конкретного порта, а не значением по умолчанию VPN, граница сохраняется честной.

Две настройки wg-quick — это предпосылки, а не часть политики. AllowedIPs = 0.0.0.0/0 позволяет peer'у нести произвольные адреса назначения IPv4, а Table = off мешает wg-quick установить собственный маршрут по умолчанию для этого префикса. Не смешивайте эти инструкции с менеджером, применяющим свою политику маршрутов: они разойдутся в том, кому принадлежит главная таблица.

Напишите маршрут, селектор и защиту

Выберите номер таблицы и пару приоритетов, которые больше никто не использует, затем примените маршрут, селектор и защиту именно в этом порядке. Числа ниже — примеры, а не зарезервированные значения:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo ограничивает правило трафиком локального происхождения, а ipproto tcp dport 25 определяет направление соединения; справочник ip-rule описывает оба селектора. Они есть в текущих ядрах и выпусках iproute2, а в старой системе правило просто отклоняется, что является более понятным отказом, чем правило, которое загружается и ни с чем не совпадает.

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

Адрес источника должен совпадать

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

На шлюзе peer клиента должен авторизовать источник, который он фактически получает, то есть 10.77.0.2/32, а не широкий префикс назначения. Копирование 0.0.0.0/0 клиента в каждый peer шлюза размывает представление о том, кому принадлежит какой трафик. Шлюзу также нужны пересылка, политика межсетевого экрана, разрешающая поток, и обратный путь, включая исходящую трансляцию, когда вышестоящая сторона не может маршрутизировать частный адрес туннеля.

Проверьте обратный путь, затем устойчивость

Прочитайте результаты поиска, прежде чем чему-либо доверять: они показывают, какую таблицу и какой источник получает каждое направление. Одного получателя на порту 25 и того же получателя на порту 443 достаточно:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

Первый поиск должен назвать wg0 и предполагаемый источник, а второй — сохранить обычный вышестоящий канал. Когда приложение привязывает собственный адрес, добавьте from с этим адресом в поиск. Направление ответа, которое доходит до wg0 и затем отбрасывается локально, указывает на фильтрацию обратного пути IPv4, потому что правило только для исходящего порта не заставляет обратный поиск выбирать туннель.

Там, где асимметричная маршрутизация разрешена, может подойти нестрогий режим, ограниченный интерфейсом, через net.ipv4.conf.wg0.rp_filter=2, и стоит сначала проверить действующий максимум значений all и интерфейса. Не отключайте проверку глобально как короткий путь. Затем передайте таблицу, приоритеты и защиту тому, кто владеет конфигурацией, и после переподключения откройте новые соединения, чтобы подтвердить, что выбор по-прежнему сохраняется. Учтите, что ответы локального слушателя SMTP несут исходный порт 25, а не порт назначения 25, и это отдельный вопрос политики.