Skicka bara port 25 i tunneln, inte värden

Fyra saker måste stämma innan en Linux-värd skickar bara sin egen SMTP genom en tunnel: en rutt i en egen tabell, en policyregel som väljer trafiken, en källadress som peeren accepterar, och en returväg som klarar asymmetrin. Var och en är en separat konfiguration med sitt eget felläge. Ordningen nedan är den som får ett fel att peka på den del som faktiskt är fel. Det är en portspecifik routinguppgift, inte en begäran om en standardrutt för VPN.

En portregel är inte en standardrutt

En regel som matchar lokalt genererad TCP mot målport 25 skickar trafiken till en tabell du namnger. Regeln skapar ingenting i sig själv: den väljer, och tabellen måste innehålla en rutt som kan bära paketet. Kombinationen av de två täcker bara en protokolls utgående riktning, så vidarebefordran för andra värdar, inkommande postanslutningar och IPv6 hamnar utanför arrangemanget. Att kalla det en portspecifik policy i stället för VPN-standard håller den gränsen ärlig.

Två wg-quick-inställningar är förutsättningar, inte en del av policyn. AllowedIPs = 0.0.0.0/0 låter peeren bära godtyckliga IPv4-mål, och Table = off hindrar wg-quick från att installera sin egen standardrutt för det prefixet. Blanda inte dessa instruktioner med en hanterare som tillämpar sin egen ruttpolicy, för de två kommer att vara oense om vem som äger huvudtabellen.

Skriv rutten, väljaren och vakten

Välj ett tabellnummer och ett par prioriteringar som ingenting annat använder, och tillämpa sedan rutten, väljaren och vakten i den ordningen. Siffrorna nedan är exempel, inte reserverade värden:

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 begränsar regeln till lokalt uppkommen trafik, och ipproto tcp dport 25 identifierar anslutningens riktning; ip-rule-referensen dokumenterar båda väljarna. De finns i aktuella kärnor och iproute2-utgåvor, och på ett äldre system avvisas regeln helt, vilket är ett tydligare fel än en regel som läses in och inte matchar något.

Unreachable-regeln på nästa prioritet är vakten. Utan den faller en saknad rutt i tabell 51825 igenom till den vanliga standardrutten, och post lämnar den fysiska länken under ett tunnelavbrott, vilket är precis det fall policyn byggdes för att förhindra.

Källadressen måste stämma

Ruttens src-preferens fyller bara i en källa för anslutningar som inte bundit en egen. Det är ingen översättning, och det åsidosätter inte en uttrycklig bindning, så en daemon bunden till den fysiska adressen fortsätter att skicka från den adressen. Om det är detta du hittar, ändra daemonens egen inställning eller designa en avsiktlig översättningspolicy, för en sen generell masquerade är en annan lösning med andra konsekvenser.

Vid gatewayen måste klientens peer auktorisera den källa den faktiskt tar emot, alltså 10.77.0.2/32 i stället för ett brett målprefix. Att kopiera klientens 0.0.0.0/0 till varje gateway-peer gör det oklart vilken peer som äger vilken trafik. Gatewayen behöver också vidarebefordran, en brandväggspolicy som tillåter flödet och en returväg, inklusive utgående översättning när uppströms inte kan routa en privat tunneladress.

Kontrollera returvägen, sedan persistensen

Läs uppslagningarna innan du litar på något, för de visar vilken tabell och vilken källa varje riktning får. Ett mål på port 25 och samma mål på port 443 räcker:

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

Den första uppslagningen bör namnge wg0 och den avsedda källan, och den andra bör behålla den vanliga upplänken. När programmet binder sin egen adress, lägg till from med den adressen i uppslagningen. En svarsriktning som når wg0 och sedan släpps lokalt pekar på IPv4-filtrering av omvänd väg, eftersom en regel bara för utgående port inte får den omvända uppslagningen att välja tunneln.

Där asymmetrisk routing är tillåten kan ett gränssnittsbegränsat löst läge via net.ipv4.conf.wg0.rp_filter=2 vara lämpligt, och det är värt att först kontrollera det effektiva maximivärdet för all och gränssnittet. Stäng inte av validering globalt som en genväg. Lämna sedan över tabellen, prioriteringarna och vakten till den som äger konfigurationen, och öppna nya anslutningar efter en återanslutning för att bekräfta att valet fortfarande håller. Tänk på att svar från en lokal SMTP-lyssnare bär källport 25 och inte målport 25, vilket är en separat policyfråga.