Kilderouting til to VPN-puljer: hvad din regel overser

To klientpuljer, én gateway og planen ser triviel ud: én regel sender den første pulje ud ad den hurtige uplink, en anden sender den anden pulje gennem en partnertunnel. Så er reglerne på plads, og den anden pulje forlader stadig ad standardruten. Reglen er ikke i stykker. Pakkens kilde er ikke det, forfatteren forventede i det øjeblik opslaget sker, fordi oversættelse og opslag foregår på forskellige punkter i samme pakkes rejse, og rækkefølgen er det modsatte af det mentale diagram, de fleste tegner.

Opslaget sker, før kilden skrives om

For en pakke, der videresendes fra en VPN-klient, kører kernen en fast sekvens. Den ankommer på tunnelinterfacet, passerer prerouting, hvor conntrack og DNAT bor, derefter træffes routingbeslutningen, derefter videresendelse, derefter postrouting, hvor SNAT anvendes sidst. En regel af formen from konsulteres under den routingbeslutning, hvilket betyder, at den ser klientens oprindelige adresse, ikke den oversatte.

Så at tilføje en masquerade-regel ændrer ikke, hvilken politik der matcher den udgående strøm. Det, den ændrer, er, hvad den fjerne ende ser, og dermed hvilken returvej der findes. Det er to forskellige konsekvenser, og ændringsgennemgange forveksler dem konstant. Adskil dem, og designet bliver som regel tydeligt inden for et minut.

Det er i svarretningen, den oversatte adresse dukker op i reglerne. En pakke, der vender tilbage til gatewayen, er adresseret til den oversatte adresse, og hvis du har politikregler baseret på destination eller på det interface, den ankom på, er det den værdi, du matcher. Samme forbindelse, forskellig kilde til sandhed i hver retning.

To puljer med forskellige kilder har altså brug for forskellige tabeller, og designet er sundt. Det, tabellen ovenfor udelukker, er genvejen at fejlfinde ved at se på, hvad fjernsiden modtog, og udlede reglen deraf.

En test fra gatewayen er ikke en test af puljen

Trafik, som gatewayen selv genererer, passerer aldrig prerouting, fordi den ikke ankom på et interface. Den routes i output-stien med gatewayens egen adresse som kilde, og en from-regel baseret på et klientområde matcher ikke. Hver ticket i dette område, der siger, at det virker fra boksen men ikke fra klienten, er den samme kendsgerning gentaget.

Simulér klienten i stedet for at tilnærme den. Routingopslaget kan spørges direkte, med en kilde og et indgangsinterface angivet:

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

Kør det én gang per pulje. Hvis de to kommandoer returnerer det samme interface, adskiller reglerne ikke puljerne, og årsagen er enten en manglende regel eller en regel med højere prioritet, der matcher begge. Hvis de returnerer forskellige interfaces, men klienten stadig fejler, ligger fejlen efter opslaget, og du kan stoppe med at kigge på regler.

Prioritet, ikke placering i filen

Regler evalueres i stigende prioritetsrækkefølge, og tallet er det, der betyder noget, ikke den rækkefølge, du skrev dem i. local-tabellen ligger på prioritet 0, main-tabellen på 32766 og standardreglen på 32767, og derfor ender en regel tilføjet med standardprioritet nær slutningen af listen og taber til næsten alt.

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

En eksplicit prioritet gør den tilsigtede rækkefølge synlig i filen og i gennemgangen. Den forhindrer også en senere tilføjelse i stille at springe foran en eksisterende regel, hvilket er den mest almindelige årsag til, at en fungerende politik holder op med at virke efter en urelateret ændring.

En matchende regel, der peger på en ufuldstændig tabel, er den anden fælde. Hvis tabel 201 indeholder en standardrute men ingen rute til destinationen, droppes pakken eller sendes det forkerte sted hen, og reglen ser helt korrekt ud isoleret. Læs tabellen, ikke kun reglen. En regel er en pegepind, og en tom tabel er en pegepind ud i ingenting.

Returvejen skal stadig findes

Kildepolitik vælger en udgang. Den skaber ikke en returvej. Hvis den anden pulje forlader gennem en partnertunnel, skal partneren vide, hvordan den når 172.31.8.0/24, enten via en rute tilbage til gatewayen eller ved at modtage oversatte adresser, den allerede kender.

Valget mellem de to er en designbeslutning med synlige konsekvenser. At route klientområdet tilbage bevarer hver klients identitet hos partneren og kræver, at de accepterer dit præfiks. Oversættelse skjuler puljen bag én adresse og kræver, at partneren kun accepterer den adresse, på bekostning af at dine og deres logfiler ikke længere er enige om, hvem der forbandt.

Uanset hvad du vælger, så skriv det ned ved siden af puljedefinitionen. En returvej, der kun findes i nogens hukommelse, er netop den slags, der overlever, indtil partneren ændrer en firewall, og derefter tager en dag at rekonstruere.

Fang ikke gatewayens egen tunnel i politikken

De regler, du skriver for klienter, gælder også for trafik, som gatewayen genererer, medmindre du udelukker den. En bred regel baseret på et mærke eller på output-interfacet kan fange gatewayens egen forbindelse til partneren, og så bliver den tunnel, der bærer politikken, routet af politikken. Det giver en løkke eller et udfald, der ligner en udbyderfejl.

Afgræns hver regel så snævert, som designet tillader: kildepræfiks, indgangsinterface og, hvor det understøttes, et mærke som kun klientpakker bærer. Test derefter gatewayens egen forbindelse efter hver regelændring, fordi fejlen er selvhenvisende og ikke viser sig i en klienttest.

Manualsiden for ip-rule dokumenterer selektor- og prioritetssemantikken. Kombinér den med en opslagstest per pulje, og designet bliver efterprøveligt, hvilket er forskellen mellem politikrouting, der holder et år, og politikrouting, som alle er bange for at røre.