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

To ingeniørar med same OpenBSD-gateway gir deg ofte to ulike regelsett for å nå eit eksternt nettverk, og begge kan forsvarast. Valet mellom kjeldeomsetjing og ei returrute er ikkje eit syntaksspørsmål i det heile. Det handlar om kva den andre sida allereie veit om 192.168.88.0/24, og kva du treng å halde på i loggane. Gjer du feil her, vil nat-to-linja sjå heilt riktig ut medan svara forsvinn i den eksterne standardrutaren.

Ruting og omskriving svarar på ulike spørsmål

Rutetabellen avgjer at 172.20.0.0/16 er tilgjengeleg over tun0, og den avgjerda blir teken før nokon pf-omsetjing blir rådspurd. Kjeldeomsetjinga endrar deretter pakkehovudet slik at den eksterne enden ser tunneladressa til gatewayen i staden for ein LAN-vert. Ingen av mekanismane erstattar den andre: ein nat-regel kan ikkje trylle fram ei rute, og ei rute kan ikkje overtyde ein ekstern ruter som aldri har høyrt om det private subnettet ditt. Når den andre sida manglar ein returveg, blir svara forkasta eller vidaresende til standardrutaren hennar, og ingen mengd regeljustering fiksar det.

Enkelt sagt svarar vidaresending på kvar trafikken går, og omsetjing svarar på kvar han ser ut som han kjem frå. Hald dei i separate mentale boksar medan du designar regelsettet.

Tre vilkår som avgjer

Still tre spørsmål i rekkjefølgje, og designet vel seg oftast sjølv. Har det eksterne nettverket ei statisk rute som peikar på tunneladressa for 192.168.88.0/24, eller styrer administratøren deira rutarane på den vegen? Viss ja, la LAN-adressene reise uendra og hopp over omsetjinga heilt. Treng du synlegheit per klient på den andre sida, anten for tilgangspolitikk eller for eit revisjonsspor? Viss ja, er det verdt ruterarbeidet å ta vare på kjelda. Er tunneladressa stabil nok til å skrivast inn i ei ekstern rute, eller flyttar ho seg mellom attilkoplingar?

Viss eit svar er nei eller ukjent, er nat-to det pragmatiske alternativet, og det er også det reversible. Ein omsetjingsregel blir teken ut på éi linje når den andre sida legg til ei skikkeleg rute. Ei returrute som aldri vart installert kostar deg ein supporttråd kvar gong nokon spør kvifor tunnelen berre verkar éin veg.

Plasser fragmentet slik at pf faktisk vurderer det

Fragmentet nedanfor føreset 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 vel neste hopp. Det skriv berre om kjelda på pakkar som allereie er på veg 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 detaljar i den første linja ber mesteparten av vekta. Parentesane rundt tun0 fortel pf å lese grensesnittadressa kvar gong det byggjer ein tilstandsoppføring, noko som betyr noko når tunnelen får nytt nummer etter ei attilkopling. Ordet match betyr at regelen skriv om og deretter fell gjennom, så ein eigen pass-regel må framleis sleppe straumen gjennom. Grensesnittet som blir nemnt i match-linja må også vere det rutetabellen vel, elles vurderer pf regelen på ein annan utgåande veg enn den pakken faktisk tek.

Ikkje gløym kjernesida. IPv4-vidaresending må vere slått på, og stateful pass-reglar for tunnel og LAN må finnast før noko av dette gir meining. PF NAT-delen i OpenBSD FAQ er rett referanse for nøkkelordrækkjefølgja her.

Stadfest regelsettet før du stolar på trafikken

Sjekk syntaksen først med pfctl -nf /etc/pf.conf, som parsar fila utan å laste ho. Last deretter policyen og les tilbake kva kjernen faktisk held, fordi ein regel som vart parsa reint framleis kan vere skyggelagd eller festa til feil grensesnitt. pfctl -sn skriv ut omsetjingsreglar i lasta form, og pfctl -sr skriv ut filterreglar i vurderingsrekkjefølgje.

Fylg så med på leidningen. På gatewayen viser tcpdump -ni tun0 'host 172.20.0.10' om kjeldeadressa som forlèt tunnelen er tunneladressa eller LAN-verten. Ein rask netstat -rn -f inet stadfestar kva grensesnitt målet blir løyst til. Når trafikken byrjar å flyte, listar pfctl -ss opp tilstandsoppføringar; viss ein straum ikkje gav nokon tilstand, trefte pakken aldri ein regel som lagar ein.

Viss tunnelsida ser riktig ut og svara framleis ikkje kjem, slutt å redigere pf. Den attverande feilen ligg på den eksterne rutaren, der svaret blir sendt mot ei privat adresse den sida ikkje kan nå.

Når omsetjinga kostar meir enn ho sparer

Omsetjing gøymer klientar, og stundom er det nettopp den gale handelen. Overlappande subnett er eitt tilfelle: viss den andre sida også brukar 192.168.88.0/24 internt, gjer det kollisjonen verre og ikkje betre å presentere LAN-vertar som gatewayen. IPsec-policyar som vel trafikk etter adressepar er eit anna, fordi tryggingspolicydatabasen blir matcha før omsetjinga og aldri ser den omskrivne pakken. Kvar utrulling som fakturerer, strupar eller reviderer per brukar mistar også identiteten ho treng i det augneblunken kjelda kollapsar til éi adresse.

Berebare pf-derivat er ei eiga felle. Produkt som genererer sine eigne regelfiler ventar at NAT blir konfigurert gjennom grensesnittet deira, og handredigerte fragment blir overskrivne ved neste omlasting. Regelsett kopierte frå rettleidingar skrivne før nøkkelordet match fanst vil ikkje laste på ein noverande kjerne, så porter syntaksen og les feilen i staden for å gjette.

Beslutningsregelen som overlever kontakt med ekte nettverk er kort: installer ei returrute når du kan, set om når du ikkje kan, og skriv ned kva av dei tre vilkåra som fekk deg til å velje. Den notata sparar neste person ein ettermiddag.