Rut bare port 25 inn i tunnelen, ikke verten

Fire ting må stemme før en Linux-vert sender bare sin egen SMTP gjennom en tunnel: en rute i en egen tabell, en policyregel som velger trafikken, en kildeadresse peer’en godtar, og en returvei som tåler asymmetrien. Hver av dem er en egen konfigurasjon med sin egen feilmodus. Rekkefølgen nedenfor er den som får en feil til å peke på delen som faktisk er feil. Det er en portspesifikk ruteroppgave, ikke en forespørsel om en standardrute for VPN.

En portregel er ikke en standardrute

En regel som matcher lokalt generert TCP mot destinasjonsport 25, sender trafikken til en tabell du navngir. Regelen skaper ingenting i seg selv: den velger, og tabellen må inneholde en rute som kan bære pakken. Kombinasjonen av de to dekker bare den utgående retningen til én protokoll, så videresending for andre verter, innkommende postforbindelser og IPv6 blir utenfor ordningen. Å kalle det en portspesifikk policy i stedet for VPN-standard holder den grensen ærlig.

To wg-quick-innstillinger er forutsetninger, ikke en del av policyen. AllowedIPs = 0.0.0.0/0 lar peer’en bære vilkårlige IPv4-destinasjoner, og Table = off hindrer wg-quick i å installere sin egen standardrute for det prefikset. Ikke bland disse instruksjonene med en behandler som bruker sin egen rutepolicy, for de to vil være uenige om hvem som eier hovedtabellen.

Skriv ruten, velgeren og vakten

Velg et tabellnummer og et par prioriteter som ingenting annet bruker, og bruk deretter ruten, velgeren og vakten i den rekkefølgen. Tallene nedenfor er eksempler, ikke reserverte verdier:

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 begrenser regelen til lokalt oppstått trafikk, og ipproto tcp dport 25 identifiserer retningen på forbindelsen; ip-rule-referansen dokumenterer begge velgerne. De finnes i gjeldende kjerner og iproute2-utgivelser, og på et eldre system avvises regelen helt, noe som er en klarere feil enn en regel som lastes og ikke matcher noe.

Unreachable-regelen på neste prioritet er vakten. Uten den faller en manglende rute i tabell 51825 gjennom til den vanlige standardruten, og post forlater den fysiske lenken under et tunnelutfall, som er nøyaktig tilfellet policyen ble bygget for å hindre.

Kildeadressen må stemme

Rutens src-preferanse fyller bare inn en kilde for forbindelser som ikke har bundet sin egen. Det er ikke oversettelse, og det overstyrer ikke en eksplisitt binding, så en daemon bundet til den fysiske adressen fortsetter å sende fra den adressen. Hvis det er dette du finner, endre daemonens egen innstilling eller design en bevisst oversettelsespolitikk, for en sen generell masquerade er en annen løsning med andre konsekvenser.

Ved gatewayen må klientens peer autorisere kilden den faktisk mottar, altså 10.77.0.2/32 i stedet for et bredt destinasjonsprefiks. Å kopiere klientens 0.0.0.0/0 inn i hver gateway-peer gjør det uklart hvilken peer som eier hvilken trafikk. Gatewayen trenger også videresending, en brannmurpolicy som tillater flyten, og en returvei, inkludert utgående oversettelse når oppstrøms ikke kan rute en privat tunneladresse.

Sjekk returveien, deretter persistensen

Les oppslagene før du stoler på noe, for de viser hvilken tabell og hvilken kilde hver retning får. Én destinasjon på port 25 og samme 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 navngi wg0 og den tiltenkte kilden, og det andre bør beholde den vanlige opplenken. Når applikasjonen binder sin egen adresse, legg til from med den adressen i oppslaget. En svarretning som når wg0 og deretter droppes lokalt, peker på IPv4 reversert sti-filtrering, fordi en regel bare for utgående port ikke får det omvendte oppslaget til å velge tunnelen.

Der asymmetrisk ruting er tillatt, kan en grensesnittbegrenset løs modus via net.ipv4.conf.wg0.rp_filter=2 være passende, og det er verdt å sjekke den effektive maksimumsverdien for all og grensesnittet først. Ikke slå av validering globalt som en snarvei. Overlever deretter tabellen, prioritetene og vakten til det som eier konfigurasjonen, og åpne nye forbindelser etter en gjenoppkobling for å bekrefte at valget fortsatt holder. Husk at svar fra en lokal SMTP-lytter bærer kildeport 25 og ikke destinasjonsport 25, som er et eget policymessig spørsmål.