Kilderuting for to VPN-pooler: hva regelen din overser

To klientpooler, én gateway og planen ser triviell ut: én regel sender den første poolen ut på den raske uplinken, en annen sender den andre poolen gjennom en partnertunnel. Så er reglene på plass, og den andre poolen går fortsatt ut via standardruten. Regelen er ikke ødelagt. Pakkens kilde er ikke det forfatteren forventet i det øyeblikket oppslaget skjer, fordi oversettelse og oppslag skjer på forskjellige punkter i samme pakkes reise, og rekkefølgen er det motsatte av det mentale diagrammet de fleste tegner.

Oppslaget skjer før kilden skrives om

For en pakke som videresendes fra en VPN-klient, kjører kjernen en fast sekvens. Den ankommer tunnelgrensesnittet, passerer prerouting der conntrack og DNAT bor, deretter tas rutingsbeslutningen, deretter videresending, deretter postrouting der SNAT brukes sist. En regel av formen from konsulteres under den rutingsbeslutningen, som betyr at den ser klientens opprinnelige adresse, ikke den oversatte.

Å legge til en masquerade-regel endrer altså ikke hvilken policy som passer på den utgående strømmen. Det som endres er hva den fjerne enden ser, og dermed hvilken returvei som finnes. Dette er to forskjellige konsekvenser, og endringsrevisjoner blander dem hele tiden. Skill dem, og designet blir vanligvis tydelig i løpet av et minutt.

Det er i svarretningen den oversatte adressen dukker opp i reglene. En pakke som kommer tilbake til gatewayen, er adressert til den oversatte adressen, og hvis du har policyregler basert på destinasjon eller på grensesnittet den kom inn på, er det den verdien du matcher. Samme forbindelse, ulik kilde til sannhet i hver retning.

To pooler med ulike kilder trenger altså virkelig ulike tabeller, og designet er solid. Det tabellen over utelukker, er snarveien å feilsøke ved å se på hva fjernsiden mottok og utlede regelen fra det.

En test fra gatewayen er ikke en test av poolen

Trafikk gatewayen selv genererer, passerer aldri prerouting, fordi den ikke ankom på et grensesnitt. Den rutes i output-stien, med gatewayens egen adresse som kilde, og en from-regel basert på et klientområde vil ikke matche. Hver sak i dette feltet som sier at det virker fra boksen men ikke fra klienten, er den samme kjensgjerningen gjentatt.

Simuler klienten i stedet for å tilnærme den. Rutingoppslaget kan spørres direkte, med en kilde og et inngangsgrensesnitt oppgitt:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Kjør det én gang per pool. Hvis de to kommandoene returnerer samme grensesnitt, skiller ikke reglene poolene, og årsaken er enten en manglende regel eller en regel med høyere prioritet som matcher begge. Hvis de returnerer ulike grensesnitt men klienten fortsatt feiler, ligger feilen etter oppslaget, og du kan slutte å se på regler.

Prioritet, ikke plassering i filen

Regler vurderes i stigende prioritetsrekkefølge, og tallet er det som betyr noe, ikke rekkefølgen du skrev dem i. local-tabellen ligger på prioritet 0, main-tabellen på 32766 og standardregelen på 32767, derfor havner en regel lagt til med standardprioritet nær slutten av listen og taper mot nesten alt.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

En eksplisitt prioritet gjør den tiltenkte rekkefølgen synlig i filen og i gjennomgangen. Den hindrer også at en senere tilføyelse stille hopper foran en eksisterende regel, som er den vanligste årsaken til at en fungerende policy slutter å virke etter en urelatert endring.

En matchende regel som peker på en ufullstendig tabell, er den andre fellen. Hvis tabell 201 inneholder en standardrute men ingen rute til destinasjonen, droppes pakken eller sendes til feil sted, og regelen ser helt korrekt ut isolert. Les tabellen, ikke bare regelen. En regel er en peker, og en tom tabell er en peker til ingenting.

Returveien må fortsatt finnes

Kildefilterets policy velger en utgang. Den skaper ikke en returvei. Hvis den andre poolen går ut gjennom en partnertunnel, må partneren vite hvordan den når 172.31.8.0/24, enten via en rute tilbake til gatewayen eller ved å motta oversatte adresser den allerede kjenner.

Å velge mellom dem er en designbeslutning med synlige konsekvenser. Å rute klientområdet tilbake bevarer hver klients identitet hos partneren og krever at de godtar prefikset ditt. Oversettelse skjuler poolen bak én adresse og krever at partneren bare godtar den adressen, på bekostning av at dine og deres logger ikke lenger er enige om hvem som koblet til.

Uansett hva du velger, skriv det ned ved siden av pooldefinisjonen. En returrute som bare finnes i noens hukommelse, er nettopp den typen ting som overlever til partneren endrer en brannmur, og deretter tar en dag å rekonstruere.

Ikke fang gatewayens egen tunnel i policyen

Reglene du skriver for klienter, gjelder også for trafikk gatewayen genererer, med mindre du utelukker den. En bred regel basert på et merke eller på output-grensesnittet kan fange gatewayens egen forbindelse til partneren, og da blir tunnelen som bærer policyen, rutet av policyen. Det gir en løkke eller et utfall som ser ut som en leverandørfeil.

Avgrens hver regel så snevert som designet tillater: kildeperfiks, inngangsgrensesnitt og, der det støttes, et merke som bare klientpakker bærer. Test deretter gatewayens egen tilkobling etter hver regelendring, fordi feilen er selvhenvisende og ikke vises i en klienttest.

Manualsiden for ip-rule dokumenterer semantikken til velgeren og prioriteten. Kombiner den med en oppslagstest per pool, og designet blir etterprøvbart, som er forskjellen mellom policyrutings som holder et år og det alle er redde for å røre.