Rut berre port 25 inn i tunnelen, ikkje verten

Fire ting må stemme før ein Linux-vert sender berre sin eigen SMTP gjennom ein tunnel: ei rute i ein eigen tabell, ei policyregel som vel trafikken, ei kildeadresse peer-en godtek, og ein returveg som toler asymmetrien. Kvar av dei er ein eigen konfigurasjon med sin eigen feilmodus. Rekkjefølgja nedanfor er den som får ein feil til å peike på delen som faktisk er feil. Det er ei portspesifikk ruteroppgåve, ikkje ei førespurnad om ei standardrute for VPN.

Ein portregel er ikkje ei standardrute

Ein regel som matchar lokalt generert TCP mot destinasjonsport 25, sender trafikken til ein tabell du namngir. Regelen skapar ingenting i seg sjølv: han vel, og tabellen må innehalde ei rute som kan bera pakken. Kombinasjonen av dei to dekkjer berre den utgåande retninga til éin protokoll, så vidaresending for andre vertar, innkommande postforbindingar og IPv6 blir utanfor ordninga. Å kalle det ein portspesifikk policy i staden for VPN-standard held den grensa ærleg.

To wg-quick-innstillingar er føresetnader, ikkje ein del av policyen. AllowedIPs = 0.0.0.0/0 lèt peer-en bera vilkårlege IPv4-destinasjonar, og Table = off hindrar wg-quick i å installere si eiga standardrute for det prefikset. Ikkje bland desse instruksjonane med ein behandlar som brukar sin eigen rutepolicy, for dei to vil vere usamde om kven som eig hovudtabellen.

Skriv ruta, veljaren og vaktaren

Vel eit tabellnummer og eit par prioritetar som ingenting anna brukar, og bruk deretter ruta, veljaren og vaktaren i den rekkjefølgja. Tala nedanfor er døme, ikkje reserverte verdiar:

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 avgrensar regelen til lokalt oppstått trafikk, og ipproto tcp dport 25 identifiserer retninga på forbindinga; ip-rule-referansen dokumenterer båe veljarane. Dei finst i gjeldande kjernar og iproute2-utgåver, og på eit eldre system blir regelen avvist heilt, noko som er ein klarare feil enn ein regel som blir lasta og ikkje matchar noko.

Unreachable-regelen på neste prioritet er vaktaren. Utan han fell ei manglande rute i tabell 51825 gjennom til den vanlege standardruta, og post forlèt den fysiske lenkja under eit tunnelutfall, som er nøyaktig tilfellet policyen vart bygd for å hindre.

Kildeadressa må stemme

Rutas src-preferanse fyller berre inn ei kjelde for forbindingar som ikkje har bunde si eiga. Det er ikkje omsetjing, og det overstyrer ikkje ei eksplisitt binding, så ein daemon bunden til den fysiske adressa held fram med å sende frå den adressa. Viss det er dette du finn, endre innstillinga til daemonen sjølv eller design ein medviten omsetjingspolicy, for ein sein generell masquerade er ei anna løysing med andre konsekvensar.

Ved gatewayen må peer-en til klienten autorisere kjelda han faktisk mottek, altså 10.77.0.2/32 i staden for eit breitt destinasjonsprefiks. Å kopiere 0.0.0.0/0 til klienten inn i kvar gateway-peer gjer det uklart kven peer som eig kva trafikk. Gatewayen treng òg vidaresending, ein brannmurpolicy som tillèt flyten, og ein returveg, inkludert utgåande omsetjing når oppstraumen ikkje kan rute ei privat tunneladresse.

Sjekk returvegen, deretter persistensen

Les oppslaga før du stolar på noko, for dei viser kva tabell og kva kjelde kvar retning får. Éin destinasjon på port 25 og same destinasjon på port 443 er nok:

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

Det første oppslaget bør namngi wg0 og den tiltenkte kjelda, og det andre bør halde på den vanlege opplenkja. Når applikasjonen bind si eiga adresse, legg til from med den adressa i oppslaget. Ei svarretning som når wg0 og deretter blir droppa lokalt, peikar på IPv4 reversert sti-filtrering, fordi ein regel berre for utgåande port ikkje får det omvende oppslaget til å velje tunnelen.

Der asymmetrisk ruting er tillate, kan ein grensesnittavgrensa løys modus via net.ipv4.conf.wg0.rp_filter=2 vere passande, og det er verdt å sjekke den effektive maksimumsverdien for all og grensesnittet først. Ikkje slå av validering globalt som ein snøggveg. Overlèt deretter tabellen, prioritetane og vaktaren til det som eig konfigurasjonen, og opne nye forbindingar etter ein gjenoppkopling for å stadfeste at valet framleis held. Hugs at svar frå ein lokal SMTP-lyttar ber kjeldeport 25 og ikkje destinasjonsport 25, som er eit eige policymessig spørsmål.