NAT LAN'et gennem tun0 på en OpenBSD VPN-gateway

To ingeniører med samme OpenBSD-gateway giver dig ofte to forskellige regelsæt til at nå et fjernnetværk, og begge kan forsvares. Valget mellem kildetranslation og en returrute er slet ikke et syntaksspørgsmål. Det handler om, hvad den fjerne side allerede ved om 192.168.88.0/24, og hvad du skal beholde i dine logs. Tager du fejl, ser nat-to-linjen helt korrekt ud, mens svar forsvinder i den fjerne standardgateway.

Routing og omskrivning besvarer forskellige spørgsmål

Routingtabellen afgør, at 172.20.0.0/16 kan nås over tun0, og den beslutning træffes, før nogen pf-translation konsulteres. Kildetranslation ændrer derefter pakkehovedet, så den fjerne ende ser gatewayens tunneladresse i stedet for en LAN-vært. Ingen af mekanismerne erstatter den anden: en nat-regel kan ikke trylle en rute frem, og en rute kan ikke overbevise en fjernrouter, der aldrig har hørt om dit private subnet. Når den fjerne side mangler en returvej, kasseres svar eller sendes videre til dens standardgateway, og ingen mængde regeltuning retter det.

Sagt ligeud: videresendelse svarer på, hvor trafikken går hen, og translation svarer på, hvem den ser ud til at komme fra. Hold dem i hver sin mentale kasse, mens du designer regelsættet.

Tre betingelser, der afgør det

Stil tre spørgsmål i rækkefølge, og designet vælger som regel sig selv. Har fjernnetværket en statisk rute, der peger på tunneladressen for 192.168.88.0/24, eller kontrollerer dets administrator routerne på den vej? Hvis ja, så lad LAN-adresserne rejse uændret og spring translation helt over. Har du brug for synlighed pr. klient på den fjerne side, enten til adgangspolitik eller til et revisionsspor? Hvis ja, er bevarelsen af kilden ruteningsarbejdet værd. Er tunneladressen stabil nok til at skrive i en fjernrute, eller flytter den sig mellem genopkoblinger?

Hvis et svar er nej eller ukendt, er nat-to den pragmatiske mulighed, og den er også den reversible. En translationsregel fjernes på én linje, når den fjerne side tilføjer en ordentlig rute. En returrute, der aldrig blev installeret, koster dig en supporttråd, hver gang nogen spørger, hvorfor tunnelen kun virker i én retning.

Placér fragmentet, så pf faktisk evaluerer det

Fragmentet nedenfor forudsætter, at LAN'et er 192.168.88.0/24, at fjernnetværket er 172.20.0.0/16, og at tunnelegrænsefladen er tun0. Intet i det vælger et næste hop. Det omskriver kun kilden på pakker, der allerede forlader 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 linje bærer det meste af vægten. Parenteserne omkring tun0 fortæller pf at læse grænsefladeadressen, hver gang den bygger en tilstandspost, hvilket betyder noget, når tunnelen omnummereres efter en genopkobling. Ordet match betyder, at reglen omskriver og derefter falder igennem, så en separat pass-regel stadig skal tillade strømmen. Grænsefladen, der nævnes i match-linjen, skal også være den, routingtabellen vælger, ellers evaluerer pf reglen på en anden udgående vej, end pakken faktisk tager.

Glem ikke kernen. IPv4-videresendelse skal være aktiveret, og de stateful pass-regler for tunnel og LAN skal findes, før noget af dette giver mening. PF NAT-afsnittet i OpenBSD FAQ er den rigtige reference til nøgleordsrækkefølgen her.

Verificér regelsættet, før du stoler på trafikken

Tjek syntaksen først med pfctl -nf /etc/pf.conf, som fortolker filen uden at indlæse den. Indlæs derefter politikken, og læs tilbage, hvad kernen faktisk holder, for en regel, der blev fortolket rent, kan stadig være skyggelagt eller knyttet til den forkerte grænseflade. pfctl -sn udskriver translationsregler i deres indlæste form, og pfctl -sr udskriver filterregler i evalueringsrækkefølge.

Hold så øje med ledningen. På gatewayen viser tcpdump -ni tun0 'host 172.20.0.10', om kildeadressen, der forlader tunnelen, er tunneladressen eller LAN-værten. En hurtig netstat -rn -f inet bekræfter, hvilken grænseflade destinationen opløses til. Når trafikken flyder, viser pfctl -ss tilstandsposter; hvis en strøm ikke skabte nogen tilstand, har pakken aldrig matchet en regel, der skaber en.

Hvis tunnelsiden ser rigtig ud, og svar stadig aldrig kommer, så stop med at redigere pf. Den resterende fejl sidder på den fjerne router, hvor svaret sendes mod en privat adresse, som den side ikke kan nå.

Når translation koster mere, end den sparer

Translation skjuler klienter, og nogle gange er det præcis den forkerte handel. Overlappende subnet er et tilfælde: hvis den fjerne side også bruger 192.168.88.0/24 internt, gør det kollisionen værre, ikke bedre, at præsentere LAN-værter som gatewayen. IPsec-politikker, der vælger trafik efter adressepar, er et andet, fordi sikkerhedspolitikkens database matches før translation og aldrig ser din omskrevne pakke. Enhver udrulning, der fakturerer, begrænser eller reviderer pr. bruger, mister også den identitet, den har brug for, i det øjeblik kilden falder sammen til én adresse.

Portable pf-afledte produkter er en separat fælde. Produkter, der selv genererer regelfiler, forventer, at NAT konfigureres gennem deres grænseflade, og håndredigerede fragmenter overskrives ved næste genindlæsning. Regelsæt kopieret fra vejledninger skrevet før nøgleordet match fandtes, indlæses ikke på en nuværende kerne, så portér syntaksen og læs fejlen i stedet for at gætte.

Den beslutningsregel, der overlever mødet med rigtige netværk, er kort: installér en returrute, når du kan, oversæt, når du ikke kan, og skriv ned, hvilken af de tre betingelser der fik dig til at vælge. Den note sparer den næste person en eftermiddag.