pfSense som VPN-tenar og -klient: to vegar, éin ruter

Éi eining kan sjå i to retningar samstundes: gjestebrukarar koplar inn, og den same boksen koplar ut til ein utgangsleverandør slik at utvalt trafikk går ut via eit anna nettverk. Å slå på begge tenestene tek minutt; å få dei til å leve side om side krev eit design, fordi den andre rolla skriv om rutetabellen den første er avhengig av. Tre vilkår avgjer om ordninga verkar, nemleg om den inngåande tenesta held sin eigen returveg, om den utgåande tunnelen framleis når peer-en sin, og om trafikken du ville vidaresende blir vald ut for utgangen. Tek du éin feil, får du to tunnelar som begge melder tilkopla medan ingenting nyttig går mellom dei. Kontrollane nedanfor fastslår kvart vilkår i den rekkjefølgja feila vanlegvis viser seg.

Namngje dei to rollene før du rører ei innstilling

Skriv ned fire fakta for kvar instans: den eksterne peer-en, autentiseringsmaterialet, adressepoolen han deler ut, og netta bak han. Dei to instansane er åtskilde objekt på eininga og bør halde seg åtskilde i notata dine òg. Nesten kvart forvirrande symptom seinare kjem av å blande verdiane deira, og to instansar som deler eitt sett notat er måten feil pool hamnar i feil felt på.

Den inngåande tenesta treng eit tunnelnett som ikkje overlappar adressene til den utgåande tunnelen eller noko privat nett som eininga rutar. Overlapp er den einaste feilen som gir symptom i begge rollene samstundes, og det er langt billegare å fange på papiret. Samanlikn begge poolane og kvart ruta privat nett på éin stad før du konfigurerer nokon av tenestene.

Delt maskinvare betyr ikkje delte påloggingsdata, og eit klient sertifikat frå ekstern tilgang-poolen bør ikkje kunne brukast mot utgangsleverandøren. Separat materiale gjer òg tilbakekalling til ei lokal avgjerd i staden for ei hending for heile flåten.

Hald svara til tenaren på WAN-vegen

Svara som eininga genererer sjølv, er det første offeret for ein slurvete standardrute. Når den innkapsla pakken til ein gjestebrukar kjem, er svaret lokalt oppstått trafikk, og det må gå ut gjennom grensesnittet brukaren kom inn gjennom. Viss utgangsklienten har installert ei standardrute som fangar det, går svaret inn i feil tunnel, og økta stoppar medan tenesta framleis ser sunn ut.

Det finst ingen einskild avkryssingsboks som avgjer dette, fordi avgjerda handlar om kva trafikk utgangsklienten kan fange. Anten trekkjer du ingen ruter og styrer berre det du vel, eller du trekkjer ruter og legg til unntaka som held eininga sine eigne tenester i gang. Skriv valet ned ved sida av instansen, elles vil neste person føresetje det andre.

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

Les rutetabellen etter lengste treff og ikkje etter rekkjefølgja du konfigurerte noko i. Spørsmålet er kva oppføring som vinn for adressa til utgangs-peer-en og kva oppføring som vinn for svaret til den inngåande tenesta, og dei to svara kan vere ulike.

Ikkje lat utgangstunnelen eta sitt eige endepunkt

Utgangsklienten må nå den offentlege adressa til peer-en sin for å setje opp tunnelen i det heile. Viss den adressa sjølv blir ruta inn i tunnelen, jagar klienten sin eigen hale: transporten kjem aldri opp, eller han kjem opp og fell i det augneblinken ruta blir installert. Loggen ser ut som ein autentiseringstidsavbrot og ikkje ein rutefeil, og difor fortener ruta den første kontrollen.

Kontroller ruta før påloggingsdataa og igjen etter at tunnelen er oppe, fordi ei oppføring kan vere riktig ved oppstart og feil eit minutt seinare. Adressa til peer-en må peike på den vanlege WAN-vegen, aldri på tunnel-eininga. Når transporten er stabil, flyttar det interessante spørsmålet seg til vidaresendt trafikk, som er den neste avgjerda.

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

Vel kva brukarar som får utgangen

Kjeldepolicy høyrer til inngangen der trafikken kjem inn i eininga, så vel ekstern tilgang-poolen, eller snevrare identitetar inni han. Ta vare på dei private destinasjonane og administrasjonsunntaka som aldri må sendast til utgangen, og plasser dei reglane før den breie. Utgangsvegen treng då si eiga omsetjing eller eit ruta returarrangement, som for dei fleste design betyr utgåande NAT på utgangsgrensesnittet som dekkjer poolen. Omsetjing vel ikkje ein utgang; ho skriv berre om det som alt har gått ut, så ei NAT-regel på eit uvedkommande WAN endrar ingenting i utvalet.

Stadfest at den eksterne enden tillèt vidaresendt trafikk frå dette designet, fordi nokre leverandørar gjer det og andre ikkje. Skilnaden viser seg som ein tunnel som koplar til og ikkje ber noko, noko som er lett å lese som ein lokal feil. Test dei tre straumane kvar for seg, fordi dei feilar uavhengig, og to av tre er eit 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 gjestebrukarens ytre tilkopling, og han verkar når klienten rapporterer at initialiseringssekvensen er fullført. Den andre, køyrd frå den tilkopla laptopen, bør rapportere adressa til utgangsleverandøren i staden for WAN-adressa di. Den tredje køyrer på eininga bunden til ei pool-adresse, og han testar kjeldepolicyen for vidaresendt trafikk utan å involvere ein ekstern brukar i det heile. Viss han svarar frå WAN i staden, passa ikkje policyen, og inga mengd NAT-redigering rettar eit utvalsproblem.

Bestem kva som skjer når utgangen sviktar

Skriv ned feilåtferda før ho skjer: når utgangstunnelen fell, fell brukarane då attende til det vanlege WAN, eller blir dei blokkerte til utgangen kjem attende? Begge svara er forsvarlege, og eininga vel ikkje for deg. Ei fjerna rute eller ein policy som peikar på ein død gateway gir ikkje automatisk eit fullstendig blokkert resultat. Vil du ha blokkering, må policyen seie det eksplisitt, og han må testast ved å ta bort utgangen i staden for å resonnere om han. Vil du ha attende fall, må du kunngjere det for brukarane, for trafikk som stille tek den vanlege vegen er nettopp den trafikken nokon trudde var dekt.

Deaktiver klientinstansen, sjå kva ein tilkopla brukar framleis når, og start han så igjen. Ein førespurnad som blir tidsavbroten er det fullstendig blokkerte resultatet du bad om; ein som svarar med WAN-adressa, er attende fallet du ikkje dokumenterte. Gjenta kontrollen for IPv6 og for DNS, fordi ein policy skriven for IPv4 ikkje seier noko om AAAA-trafikk, og ein resolver som blir skyvd av ein av tunnelane svarar frå der førespurnaden faktisk går ut.

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 ruta OpenVPN viser korleis kjeldepolicy, grensesnifttildeling og utgåande omsetjing passar saman, og området frå stad til stad er den delen som ikkje skal kopierast i sin heilskap. Det han ikkje vil fortelje deg, er kven av dei tre vilkåra ovanfor ditt eige design allereie har brote.