Stuur alleen poort 25 de tunnel in, niet de host

Vier dingen moeten kloppen voordat een Linux-host alleen zijn eigen SMTP door een tunnel stuurt: een route in een eigen tabel, een beleidsregel die het verkeer selecteert, een bronadres dat de peer accepteert, en een retourpad dat de asymmetrie overleeft. Elk daarvan is een aparte configuratie met zijn eigen faalwijze. De volgorde hieronder zorgt dat een fout wijst naar het onderdeel dat echt verkeerd is. Het is een poortspecifieke routingtaak, geen verzoek om een standaardroute van VPN.

Een poortregel is geen standaardroute

Een regel die lokaal gegenereerde TCP koppelt aan bestemmingspoort 25, stuurt dat verkeer naar een tabel die u noemt. De regel maakt zelf niets aan: hij selecteert, en de tabel moet een route bevatten die het pakket kan dragen. De combinatie van beide dekt alleen de uitgaande richting van één protocol, dus doorsturen voor andere hosts, inkomende mailverbindingen en IPv6 blijven buiten de regeling. Het een poortspecifiek beleid noemen in plaats van een VPN-standaard houdt die grens eerlijk.

Twee wg-quick-instellingen zijn voorwaarden, geen onderdeel van het beleid. AllowedIPs = 0.0.0.0/0 laat de peer willekeurige IPv4-bestemmingen dragen, en Table = off voorkomt dat wg-quick zijn eigen standaardroute voor dat prefix installeert. Meng deze instructies niet met een beheerder die zijn eigen routebeleid toepast, want de twee zullen het oneens zijn over wie de hoofdtabel bezit.

Schrijf de route, de selector en de bewaker

Kies een tabelnummer en een paar prioriteiten die niets anders gebruikt, en pas daarna de route, de selector en de bewaker in die volgorde toe. De nummers hieronder zijn voorbeelden, geen gereserveerde waarden:

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 beperkt de regel tot lokaal ontstaan verkeer, en ipproto tcp dport 25 identificeert de richting van de verbinding; de ip-rule-referentie documenteert beide selectors. Ze bestaan op huidige kernels en iproute2-versies, en op een ouder systeem wordt de regel botweg geweigerd, wat een duidelijker fout is dan een regel die laadt en nergens op matcht.

De unreachable-regel op de volgende prioriteit is de bewaker. Zonder die regel valt een ontbrekende route in tabel 51825 terug op de gewone standaard, en verlaat mail tijdens een tunnelstoring de fysieke link, wat precies het geval is dat het beleid moest voorkomen.

Het bronadres moet kloppen

De src-voorkeur van de route vult alleen een bron in voor verbindingen die er zelf geen hebben vastgelegd. Het is geen vertaling, en het overschrijft geen expliciete binding, dus een daemon die aan het fysieke adres is gebonden blijft vanaf dat adres verzenden. Als u dat aantreft, wijzig dan de instelling van de daemon zelf of ontwerp een bewust vertaalbeleid, want een late alomvattende masquerade is een andere oplossing met andere gevolgen.

Bij de gateway moet de peer van de client de bron autoriseren die hij daadwerkelijk ontvangt, namelijk 10.77.0.2/32 in plaats van een breed bestemmingsprefix. Het 0.0.0.0/0 van de client in elke gateway-peer kopiëren vertroebelt welke peer welk verkeer bezit. De gateway heeft ook doorsturen, een firewallbeleid dat de stroom toestaat, en een retourpad nodig, inclusief uitgaande vertaling wanneer de upstream een privé-tunneladres niet kan routeren.

Controleer het retourpad, dan de persistentie

Lees de zoekopdrachten voordat u iets vertrouwt, want ze tonen welke tabel en welke bron elke richting krijgt. Eén bestemming op poort 25 en dezelfde bestemming op poort 443 zijn genoeg:

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

De eerste zoekopdracht hoort wg0 en de bedoelde bron te noemen, en de tweede hoort de gewone uplink te behouden. Wanneer de toepassing zijn eigen adres bindt, voeg dan from met dat adres toe aan de zoekopdracht. Een antwoordrichting die wg0 bereikt en vervolgens lokaal wordt weggegooid, wijst op IPv4 reverse-path-filtering, want een regel alleen voor de uitgaande poort zorgt er niet voor dat de omgekeerde zoekopdracht de tunnel kiest.

Waar asymmetrische routing is toegestaan, kan een interfacegebonden losse modus via net.ipv4.conf.wg0.rp_filter=2 passend zijn, en het is de moeite waard eerst het effectieve maximum van de waarden all en van de interface te controleren. Schakel validatie niet wereldwijd uit als snelkoppeling. Draag daarna de tabel, de prioriteiten en de bewaker over aan wie de configuratie bezit, en open na een herverbinding nieuwe verbindingen om te bevestigen dat de selectie nog steeds standhoudt. Houd er rekening mee dat antwoorden van een lokale SMTP-listener bronpoort 25 dragen en niet bestemmingspoort 25, wat een aparte beleidsvraag is.