pfSense as VPN-tsjinner en -klant: twa paden, ien router

Ien apparaat kin tagelyk twa rjochtingen yn sjen: roaming-brûkers ferbine nei binnen, en deselde kast ferbynt nei bûten mei in útgongsoanbieder sadat selektearre ferkear troch in oar netwurk fuortgiet. Beide tsjinsten oansette duorret minuten; se njonkeninoar besteane litte freget in ûntwerp, om't de twadde rol de rûtingstabel oerskriuwt dêr't de earste fan ôfhinklik is. Trije betingsten bepale oft de opstelling wurket, nammentlik oft de ynkommende tsjinst syn eigen weromrûte hâldt, oft de útgeande tunnel syn maat noch berikke kin, en oft it ferkear dat jo trochstjoere woene foar de útgong keazen wurdt. Dochst ien ferkeard, dan krijst twa tunnels dy't beide ferbining melde wylst der neat nuttich tusken har oerstekt. De kontrôles hjirûnder fêstigje elke betingst yn 'e folchoarder wêryn't de flaters ornaris ferskine.

Nammje de beide rollen foardatst oan in ynstelling komst

Skriuw fjouwer feiten op foar elk eksimplaar: syn fiere maat, syn autentikaasjemateriaal, de adrespôle dy't it útjout en de netwurken derachter. De twa eksimplaren binne aparte objekten op it apparaat en moatte dat ek yn dyn notysjes bliuwe. Hast elk ferwizend symptoom letter komt fan it trochinoar heljen fan har wearden, en twa eksimplaren dy't ien set notysjes diele is hoe't de ferkearde pôle yn it ferkearde fjild bedarret.

De ynkommende tsjinst hat in tunnelnetwurk nedich dat net oerlaapet mei de adressen fan 'e útgeande tunnel of mei hokker priveenetwurk dan ek dat it apparaat rûtet. Oerlaap is de iene flater dy't symptomen yn beide rollen tagelyk jout, en it is folle goedkeaper om dy op papier te fangen. Ferlykje beide pôles en elk rûte priveenetwurk op ien plak foardatst ien fan 'e tsjinsten konfigurearrest.

Dield hardware betsjut net dielde oanmeldgegevens, en in kliïntsertifikaat út 'e pôle foar fiere tagong soe net tsjin 'e útgongsoanbieder brûkber wêze moatte. Apart materiaal makket ek weromroppen in pleatslike beslissing ynstee fan in barren foar de hiele float.

Hâld de antwurden fan 'e tsjinner op it WAN-paad

De antwurden dy't it apparaat sels makket, binne it earste slachtoffer fan in sloppy standertrûte. As it ynkapsulearre pakket fan in roaming-brûker oankomt, is it antwurd pleatslik ûntstien ferkear en it moat fuortgean troch de ynterface dêr't dy brûker troch kaam. Hat de útgeande kliïnt in standertrûte ynstallearre dy't it fangt, dan giet it antwurd de ferkearde tunnel yn en de sesje stoppe wylst de tsjinst der noch sûn útsjocht.

Der is gjin inkel finkje dat dit beslist, om't de beslissing giet oer hokker ferkear de útgeande kliïnt fange mei. Ofst lûkst gjin rûtes en stjoerst allinnich watst selektearrest, ofst lûkst rûtes en foegest de útsûnderingen ta dy't de eigen tsjinsten fan it apparaat oan 'e gong hâlde. Skriuw de kar njonken it eksimplaar, oars sil de folgjende persoan de oare oannimme.

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

Lês de rûtingstabel op 'e langste oerienkomst earder as op 'e folchoarder wêryn'tst wat konfigurearre hast. De fraach is hokker ynfier wint foar it adres fan 'e útgongmaat en hokker ynfier wint foar it antwurd fan 'e ynkommende tsjinst, en dy beide antwurden kinne ferskille.

Lit de útgongstunnel syn eigen einpunt net opfrette

De útgeande kliïnt moat it iepenbiere adres fan syn maat berikke om de tunnel oeral te kinnen oanlizze. As dat adres sels yn 'e tunnel rûte wurdt, jout de kliïnt syn eigen sturt efternei: it ferfier komt nea omheech, of it komt omheech en falt fuort op it stuit dat de rûte ynstallearret. It logboek liket op in autentikaasje-timeout earder as op in rûteflater, en dêrom fertsjinnet de rûte de earste kontrôle.

Kontrolearje de rûte foar de oanmeldgegevens en nochris neidat de tunnel omheech is, om't in ynfier by it opstarten goed en in minút letter ferkeard wêze kin. It adres fan 'e maat moat nei it gewoane WAN-paad wiisd, nea nei it tunnelapparaat. Sadree't it ferfier stabyl is, ferhúzet de nijsgjirrige fraach nei trochstjoerd ferkear, dat de folgjende beslissing is.

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

Kies hokker brûkers de útgong krije

Boarnbelied heart by 'e yngong dêr't ferkear it apparaat binnenkomt, dus kies de pôle foar fiere tagong, of nauwere identiteiten deryn. Bewarje de priveebestimmingen en behearsútsûnderingen dy't nea nei de útgong stjoerd wurde meie, en set dy regels foar de brede oan. It útgongspaad hat dan syn eigen oersetting of in rûte weromregeling nedich, wat foar de measte ûntwerpen útgeande NAT op 'e útgongynterface betsjut dy't de pôle dekt. Oersetting kiest gjin útgong; it oerskriuwt allinnich wat al fuort is, dus in NAT-regel op in net belutsen WAN feroaret neat oan 'e seleksje.

Befêstigje dat de fiere kant trochstjoerd ferkear út dit ûntwerp tastean, om't guon oanbieders dat wol dogge en guon net. It ferskil docht bliken as in tunnel dy't ferbynt en neat draacht, wat maklik as in pleatslike flater te lêzen is. Test de trije streamen apart, om't se ûnôfhinklik mislearje en twa fan trije is in heal ôf ûntwerp.

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

It earste kommando is de bûtenferbining fan 'e roaming-brûker, en it wurket as de kliïnt meldt dat de initialisaasjefolchoarder klear is. It twadde, út dy ferbûne laptop wei draaid, soe it adres fan 'e útgongsoanbieder melde moatte ynstee fan dyn WAN-adres. It tredde rint op it apparaat bûn oan in adres út 'e pôle, en it test it boarnbelied foar trochstjoerd ferkear sûnder hielendal in fiere brûker te belûken. As it ynstee fan it WAN antwurdet, dan paste it belied net, en gjin inkel bedrach oan NAT-bewurking makket in seleksjeprobleem goed.

Beslis wat der bart as de útgong mislearret

Skriuw it flatergedrach op foardat it bart: as de útgeande tunnel falt, falle brûkers dan werom op it gewoane WAN of wurde se blokkearre oant de útgong weromkomt? Beide antwurden binne ferdigenber, en it apparaat sil net foar dy kieze. In fuorthelle rûte of in belied dat nei in deade gateway wiist, jout net fanselssprekkend in folslein blokkearre resultaat. Wolst blokkearje, dan moat it belied dat eksplisyt sizze, en it moat test wurde troch de útgong fuort te nimmen ynstee fan deroer te redenearjen. Wolst weromfalle, meitsje dat dan buorkundich foar brûkers, om't ferkear dat stil it gewoane paad nimt krekt dat ferkear is dêr't immen tocht dat it dekt wie.

Skeakelje it kliïnteksimplaar út, sjoch wat in ferbûne brûker noch berikke kin, en start it dan wer. In oanfraach dy't útrint is it folslein blokkearre resultaat dêr'tst om frege hast; ien dy't mei it WAN-adres antwurdet is de weromfal dy'tst net dokumintearre hast. Werhelje de kontrôle foar IPv6 en foar DNS, om't in belied skreaun foar IPv4 neat seit oer AAAA-ferkear en in resolver dy't troch ien fan 'e tunnels treaun wurdt, antwurdet fan dêr't de fraach wier fuortgiet.

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

Netgate syn resept foar rûte OpenVPN lit sjen hoe't boarnbelied, ynterfacetaopassing en útgeande oersetting yninoar passe, en syn omfang fan side nei side is it diel dat net hielendal kopyeare moat wurde. Wat it dy net fertelle sil, is hokker fan 'e trije betingsten hjirboppe dyn eigen ûntwerp al brutsen hat.