Kjelderuting for to VPN-pølar: kva regelen din overser

To klientpølar, éin gateway og planen ser triviell ut: éin regel sender den første pølen ut på den raske opplenkja, ein annan sender den andre pølen gjennom ein partnartunnel. Så er reglane på plass, og den andre pølen går framleis ut via standardruta. Regelen er ikkje øydelagd. Kjelda til pakken er ikkje det forfattaren venta i det augneblinken oppslaget skjer, fordi omsetjing og oppslag skjer på ulike punkt i reisa til same pakken, og rekkjefølgja er det motsette av det mentale diagrammet dei fleste teiknar.

Oppslaget skjer før kjelda blir skriven om

For ein pakke som blir vidaresend frå ein VPN-klient, køyrer kjernen ein fast sekvens. Han kjem inn på tunnelgrensesnittet, passerer prerouting der conntrack og DNAT bur, deretter blir rutingsavgjerda teken, deretter vidaresending, deretter postrouting der SNAT blir brukt sist. Ein regel av forma from blir konsultert under den rutingsavgjerda, som tyder at han ser den opphavlege adressa til klienten, ikkje den omsette.

Å leggje til ein masquerade-regel endrar altså ikkje kva politikk som passar på den utgåande straumen. Det som blir endra er kva den fjerne enden ser, og dermed kva returveg som finst. Dette er to ulike konsekvensar, og endringsgjennomgangar blandar dei heile tida. Skil dei, og designet blir vanlegvis tydeleg i løpet av eitt minutt.

Det er i svarretninga den omsette adressa dukkar opp i reglane. Ein pakke som kjem tilbake til gatewayen, er adressert til den omsette adressa, og dersom du har politikkreglar baserte på mål eller på grensesnittet han kom inn på, er det den verdien du matchar. Same samband, ulik kjelde til sanning i kvar retning.

To pølar med ulike kjelder treng altså verkeleg ulike tabellar, og designet er solid. Det tabellen over utelukkar, er snarvegen å feilsøkje ved å sjå på kva fjernsida tok imot og utleie regelen frå det.

Ein test frå gatewayen er ikkje ein test av pølen

Trafikk gatewayen sjølv genererer, passerer aldri prerouting, fordi han ikkje kom inn på eit grensesnitt. Han blir ruta i output-stien, med gatewayen si eiga adresse som kjelde, og ein from-regel basert på eit klientområde vil ikkje matche. Kvar sak i dette feltet som seier at det verkar frå boksen men ikkje frå klienten, er den same kjensgjerninga repetert.

Simuler klienten i staden for å tilnærme han. Rutingoppslaget kan ein spørje direkte, med kjelde og 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

Køyr det éin gong per pøl. Dersom dei to kommandoane returnerer same grensesnitt, skil ikkje reglane pølane, og årsaka er anten ein manglande regel eller ein regel med høgare prioritet som matchar begge. Dersom dei returnerer ulike grensesnitt men klienten framleis feilar, ligg feilen etter oppslaget, og du kan slutte å sjå på reglar.

Prioritet, ikkje plassering i fila

Reglar blir vurderte i stigande prioritetsrekkjefølgje, og talet er det som tel, ikkje rekkjefølgja du skreiv dei i. local-tabellen ligg på prioritet 0, main-tabellen på 32766 og standardregelen på 32767, difor hamnar ein regel lagt til med standardprioritet nær slutten av lista 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

Ein eksplisitt prioritet gjer den tiltenkte rekkjefølgja synleg i fila og i gjennomgangen. Han hindrar òg at ei seinare tilføying stille hoppar framfor ein eksisterande regel, som er den vanlegaste årsaka til at ein fungerande politikk sluttar å verke etter ei urelatert endring.

Ein matchande regel som peikar på ein ufullstendig tabell, er den andre fella. Dersom tabell 201 inneheld ei standardrute men inga rute til målet, blir pakken droppa eller send til feil stad, og regelen ser heilt korrekt ut isolert. Les tabellen, ikkje berre regelen. Ein regel er ein peikar, og ein tom tabell er ein peikar til ingenting.

Returvegen må framleis finnast

Kjeldepolitikken vel ein utgang. Han skaper ikkje ein returveg. Dersom den andre pølen går ut gjennom ein partnartunnel, må partnaren vite korleis han når 172.31.8.0/24, anten via ei rute tilbake til gatewayen eller ved å ta imot omsette adresser han alt kjenner.

Å velje mellom dei er ei designavgjerd med synlege konsekvensar. Å rute klientområdet tilbake bevarer identiteten til kvar klient hos partnaren og krev at han godtek prefikset ditt. Omsetjing gøymer pølen bak éi adresse og krev at partnaren berre godtek den adressa, på kostnad av at dine og deira loggar ikkje lenger er samde om kven som kopla til.

Uansett kva du vel, skriv det ned ved sida av pøldefinisjonen. Ei returrute som berre finst i minnet til nokon, er nettopp den typen ting som overlever til partnaren endrar ein brannmur, og som deretter tek ein dag å rekonstruere.

Ikkje fang eigen tunnel til gatewayen i politikken

Reglane du skriv for klientar, gjeld òg for trafikk gatewayen genererer, med mindre du utelukkar han. Ein brei regel basert på eit merke eller på output-grensesnittet kan fange eigen samband til gatewayen med partnaren, og då blir tunnelen som ber politikken, ruta av politikken. Det gir ei løkke eller eit utfall som ser ut som ein leverandørfeil.

Avgrens kvar regel så snevert som designet tillèt: kjeldeprefiks, inngangsgrensesnitt og, der det er støtta, eit merke som berre klientpakkar ber. Test deretter eigen tilkopling til gatewayen etter kvar regelendring, fordi feilen er sjølvtilvisande og ikkje viser seg i ein klienttest.

Manualsida for ip-rule dokumenterer semantikken til veljaren og prioriteten. Kombiner henne med ein oppslagstest per pøl, og designet blir etterprøvbart, som er skilnaden mellom policyrutings som held eitt år og det alle er redde for å røre.