Насочвайте само порт 25 към тунела, не хоста

Четири неща трябва да се подредят, преди Linux хост да изпрати само своя SMTP през тунел: маршрут в отделна таблица, правило за политика, което избира трафика, адрес на източник, който партньорът ще приеме, и обратен път, който издържа на асиметрията. Всяко от тях е отделна конфигурация със собствен режим на отказ. Редът по-долу е този, който кара отказа да сочи към действително сгрешената част. Това е задача за маршрутизиране, специфична за порт, а не заявка за маршрут по подразбиране през VPN.

Правилото за порт не е маршрут по подразбиране

Правило, което съпоставя локално генериран TCP с порт на местоназначението 25, изпраща този трафик в таблица, която вие посочвате. Правилото само по себе си не създава нищо: то избира, а таблицата трябва да съдържа маршрут, който да пренесе пакета. Съчетаването на двете покрива само изходящата посока на един протокол, затова препращането за други хостове, входящите пощенски връзки и IPv6 остават извън схемата. Наричането ѝ политика, специфична за порт, а не VPN по подразбиране, пази тази граница честна.

Две настройки на wg-quick са предпоставки, а не част от политиката. AllowedIPs = 0.0.0.0/0 позволява на партньора да носи произволни 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 на маршрута само попълва източник за връзки, които не са обвързали свой. То не е транслация и не отменя явно обвързване, затова демон, обвързан с физическия адрес, продължава да изпраща от него. Ако откриете точно това, променете собствената настройка на демона или проектирайте съзнателна политика за транслация, защото късна всеобхватна маскировка е друго решение с други последствия.

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

Проверете обратния път, после устойчивостта

Прочетете търсенията, преди да се доверите на каквото и да е, защото те показват коя таблица и кой източник получава всяка посока. Едно местоназначение на порт 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, което е отделен въпрос на политика.