pfSense som VPN-server og -klient: to veier, én ruter

Én enhet kan se i to retninger samtidig: gjestebrukere kobler inn, og den samme boksen kobler ut til en utgangsleverandør slik at utvalgt trafikk forlater via et annet nettverk. Å aktivere begge tjenestene tar minutter; å få dem til å leve side om side krever et design, fordi den andre rollen skriver om rutetabellen den første er avhengig av. Tre betingelser avgjør om ordningen virker, nemlig om den inngående tjenesten beholder sin egen returvei, om den utgående tunnelen fortsatt når peer-en sin, og om trafikken du ville videresende blir valgt ut for utgangen. Tar du én feil, får du to tunneler som begge melder tilkoblet mens ingenting nyttig går mellom dem. Kontrollene nedenfor fastslår hver betingelse i den rekkefølgen feilene vanligvis viser seg.

Navngi de to rollene før du rører en innstilling

Skriv ned fire fakta for hver instans: dens eksterne peer, autentiseringsmaterialet, adressepoolen den deler ut, og nettene bak den. De to instansene er atskilte objekter på enheten og bør forbli atskilt i notatene dine også. Nesten hvert forvirrende symptom senere kommer av å blande verdiene deres, og to instanser som deler ett sett notater er måten feil pool havner i feil felt på.

Den inngående tjenesten trenger et tunnelnett som ikke overlapper den utgående tunnelens adresser eller noe privat nett som enheten ruter. Overlapp er den ene feilen som gir symptomer i begge roller samtidig, og det er langt billigere å fange på papiret. Sammenlign begge poolene og hvert rutet privat nett på ett sted før du konfigurerer noen av tjenestene.

Delt maskinvare betyr ikke delte påloggingsdata, og et klient sertifikat fra ekstern tilgang-poolen bør ikke kunne brukes mot utgangsleverandøren. Separat materiale gjør også tilbakekalling til en lokal beslutning i stedet for en hendelse for hele flåten.

Hold serverens svar på WAN-veien

Svarene som enheten genererer selv, er det første offeret for en slurvete standardrute. Når en gjestebrukers innkapslede pakke ankommer, er svaret lokalt oppstått trafikk, og det må forlate gjennom grensesnittet brukeren kom inn gjennom. Hvis utgangsklienten har installert en standardrute som fanger det, går svaret inn i feil tunnel, og økten stopper mens tjenesten fortsatt ser sunn ut.

Det finnes ingen enkelt avkrysningsboks som avgjør dette, fordi beslutningen handler om hvilken trafikk utgangsklienten kan fange. Enten trekker du ingen ruter og styrer bare det du velger, eller du trekker ruter og legger til unntakene som holder enhetens egne tjenester i gang. Skriv valget ned ved siden av instansen, ellers vil neste person anta det andre.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Les rutetabellen etter lengste treff og ikke etter rekkefølgen du konfigurerte noe i. Spørsmålet er hvilken oppføring som vinner for utgangs-peer-ens adresse og hvilken oppføring som vinner for den inngående tjenestens svar, og de to svarene kan være forskjellige.

Ikke la utgangstunnelen spise sitt eget endepunkt

Utgangsklienten må nå peer-ens offentlige adresse for å sette opp tunnelen i det hele tatt. Hvis den adressen selv rutes inn i tunnelen, jager klienten sin egen hale: transporten kommer aldri opp, eller den kommer opp og faller i det øyeblikket ruten installeres. Loggen ser ut som en autentiseringstidsavbrudd og ikke en rutefeil, og derfor fortjener ruten den første kontrollen.

Kontroller ruten før påloggingsdataene og igjen etter at tunnelen er oppe, fordi en oppføring kan være riktig ved oppstart og feil et minutt senere. Peer-ens adresse må peke på den vanlige WAN-veien, aldri på tunnel-enheten. Når transporten er stabil, flytter det interessante spørsmålet seg til videresendt trafikk, som er den neste beslutningen.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Velg hvilke brukere som får utgangen

Kildepolicy hører til inngangen der trafikken kommer inn i enheten, så velg ekstern tilgang-poolen, eller snevrere identiteter inni den. Bevar de private destinasjonene og administrasjonsunntakene som aldri må sendes til utgangen, og plasser disse reglene før den brede. Utgangsveien trenger da sin egen oversettelse eller et rutet returarrangement, som for de fleste design betyr utgående NAT på utgangsgrensesnittet som dekker poolen. Oversettelse velger ikke en utgang; den skriver bare om det som allerede har forlatt, så en NAT-regel på et uvedkommende WAN endrer ingenting i utvalget.

Bekreft at den eksterne enden tillater videresendt trafikk fra dette designet, fordi noen leverandører gjør det og andre ikke. Forskjellen viser seg som en tunnel som kobler til og ikke bærer noe, noe som er lett å lese som en lokal feil. Test de tre strømmene hver for seg, fordi de feiler uavhengig, og to av tre er et halvferdig design.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Den første kommandoen er gjestebrukerens ytre tilkobling, og den virker når klienten rapporterer at initialiseringssekvensen er fullført. Den andre, kjørt fra den tilkoblede laptopen, bør rapportere utgangsleverandørens adresse i stedet for din WAN-adresse. Den tredje kjører på enheten bundet til en pool-adresse, og den tester kildepolicyen for videresendt trafikk uten å involvere en ekstern bruker i det hele tatt. Hvis den svarer fra WAN i stedet, passet ikke policyen, og ingen mengde NAT-redigering retter et utvalgsproblem.

Bestem hva som skjer når utgangen svikter

Skriv ned feilatferden før den skjer: når utgangstunnelen faller, faller brukerne tilbake til det vanlige WAN, eller blir de blokkert til utgangen kommer tilbake? Begge svarene er forsvarlige, og enheten velger ikke for deg. En fjernet rute eller en policy som peker på en død gateway gir ikke automatisk et fullstendig blokkert resultat. Vil du ha blokkering, må policyen si det eksplisitt, og den må testes ved å ta bort utgangen i stedet for å resonnere om den. Vil du ha tilbakefall, må du kunngjøre det for brukerne, for trafikk som stille tar den vanlige veien er nettopp den trafikken noen trodde var dekket.

Deaktiver klientinstansen, se hva en tilkoblet bruker fortsatt når, og start den så igjen. En forespørsel som tidsavbrytes er det fullstendig blokkerte resultatet du ba om; en som svarer med WAN-adressen, er tilbakefallet du ikke dokumenterte. Gjenta kontrollen for IPv6 og for DNS, fordi en policy skrevet for IPv4 ikke sier noe om AAAA-trafikk, og en resolver som skyves av en av tunnelene svarer fra der forespørselen faktisk forlater.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgates oppskrift for rutet OpenVPN viser hvordan kildepolicy, grensesnitttilordning og utgående oversettelse passer sammen, og dens område fra sted til sted er den delen som ikke skal kopieres i sin helhet. Det den ikke vil fortelle deg, er hvilken av de tre betingelsene ovenfor ditt eget design allerede har brutt.