NAT av LAN-et gjennom tun0 på en OpenBSD VPN-gateway

To ingeniører med samme OpenBSD-gateway gir deg ofte to ulike regelsett for å nå et eksternt nettverk, og begge kan forsvares. Valget mellom kildetranslasjon og en returrute er ikke et syntaksspørsmål i det hele tatt. Det handler om hva den andre siden allerede vet om 192.168.88.0/24, og hva du trenger å beholde i loggene. Tar du feil her, vil nat-to-linjen se helt riktig ut mens svarene forsvinner i den eksterne standardruteren.

Ruting og omskriving svarer på forskjellige spørsmål

Rutetabellen avgjør at 172.20.0.0/16 er tilgjengelig over tun0, og den avgjørelsen tas før noen pf-translasjon konsulteres. Kildetranslasjonen endrer deretter pakkehodet slik at den eksterne enden ser gatewayens tunneladresse i stedet for en LAN-vert. Ingen av mekanismene erstatter den andre: en nat-regel kan ikke trylle fram en rute, og en rute kan ikke overbevise en ekstern ruter som aldri har hørt om det private subnettet ditt. Når den andre siden mangler en returvei, blir svarene forkastet eller videresendt til dens standardruter, og ingen mengde regeljustering fikser det.

Enkelt sagt svarer videresending på hvor trafikken går, og translasjon svarer på hvor den ser ut som den kommer fra. Hold dem i separate mentale bokser mens du designer regelsettet.

Tre betingelser som avgjør

Still tre spørsmål i rekkefølge, og designet velger seg vanligvis selv. Har det eksterne nettverket en statisk rute som peker på tunneladressen for 192.168.88.0/24, eller kontrollerer administratoren deres ruterne på den veien? Hvis ja, la LAN-adressene reise uendret og hopp over translasjonen helt. Trenger du synlighet per klient på den andre siden, enten for tilgangspolicy eller for et revisjonsspor? Hvis ja, er det verdt rute-arbeidet å bevare kilden. Er tunneladressen stabil nok til å skrives inn i en ekstern rute, eller flytter den seg mellom gjentilkoblinger?

Hvis noe svar er nei eller ukjent, er nat-to det pragmatiske alternativet, og det er også det reversible. En translasjonsregel tas ut på én linje når den andre siden legger til en skikkelig rute. En returrute som aldri ble installert koster deg en supporttråd hver gang noen spør hvorfor tunnelen bare virker én vei.

Plasser fragmentet slik at pf faktisk vurderer det

Fragmentet nedenfor forutsetter at LAN-et er 192.168.88.0/24, det eksterne nettverket er 172.20.0.0/16, og tunellgrensesnittet er tun0. Ingenting i det velger neste hopp. Det skriver bare om kilden på pakker som allerede er på vei ut gjennom tunnelen.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

To detaljer i den første linjen bærer mesteparten av vekten. Parentesene rundt tun0 forteller pf å lese grensesnittadressen hver gang det bygger en tilstandsoppføring, noe som betyr noe når tunnelen får nytt nummer etter en gjentilkobling. Ordet match betyr at regelen skriver om og deretter faller gjennom, så en egen pass-regel må fortsatt slippe strømmen gjennom. Grensesnittet som nevnes i match-linjen må også være det rutetabellen velger, ellers vurderer pf regelen på en annen utgående vei enn den pakken faktisk tar.

Ikke glem kjernesiden. IPv4-videresending må være aktivert, og stateful pass-regler for tunnel og LAN må finnes før noe av dette gir mening. PF NAT-delen i OpenBSD FAQ er riktig referanse for nøkkelordrekkefølgen her.

Verifiser regelsettet før du stoler på trafikken

Sjekk syntaksen først med pfctl -nf /etc/pf.conf, som parser filen uten å laste den. Last deretter policyen og les tilbake hva kjernen faktisk holder, fordi en regel som ble parset rent fortsatt kan være skyggelagt eller festet til feil grensesnitt. pfctl -sn skriver ut translasjonsregler i lastet form, og pfctl -sr skriver ut filterregler i evalueringsrekkefølge.

Følg deretter med på ledningen. På gatewayen viser tcpdump -ni tun0 'host 172.20.0.10' om kildeadressen som forlater tunnelen er tunneladressen eller LAN-verten. En rask netstat -rn -f inet bekrefter hvilket grensesnitt målet løses til. Når trafikken begynner å flyte, lister pfctl -ss opp tilstandsoppføringer; hvis en strøm ikke ga noen tilstand, traff pakken aldri en regel som lager en.

Hvis tunnelsiden ser riktig ut og svarene fortsatt ikke kommer, slutt å redigere pf. Den gjenværende feilen ligger på den eksterne ruteren, der svaret sendes mot en privat adresse den siden ikke kan nå.

Når translasjonen koster mer enn den sparer

Translasjon skjuler klienter, og noen ganger er det nøyaktig den gale handelen. Overlappende subnett er ett tilfelle: hvis den andre siden også bruker 192.168.88.0/24 internt, gjør det kollisjonen verre og ikke bedre å presentere LAN-verter som gatewayen. IPsec-policyer som velger trafikk etter adressepar er et annet, fordi sikkerhetspolicy-databasen matches før translasjonen og aldri ser den omskrevne pakken. Enhver utrulling som fakturerer, struper eller reviderer per bruker mister også identiteten den trenger i det øyeblikket kilden kollapser til én adresse.

Bærbare pf-derivater er en egen felle. Produkter som genererer sine egne regelfiler forventer at NAT konfigureres gjennom grensesnittet deres, og håndredigerte fragmenter overskrives ved neste omlasting. Regelsett kopiert fra veiledninger skrevet før nøkkelordet match fantes vil ikke laste på en nåværende kjerne, så porter syntaksen og les feilen i stedet for å gjette.

Beslutningsregelen som overlever kontakt med ekte nettverk er kort: installer en returrute når du kan, oversett når du ikke kan, og skriv ned hvilken av de tre betingelsene som fikk deg til å velge. Den notaten sparer neste person en ettermiddag.