pfSense VPN-serveri ja -kliendina: kaks teed, üks ruuter
Sissetulev teenus ja väljuv väljundtunnel võivad jagada ühte seadet. Kolm tingimust otsustavad, kas nende marsruudid, tõlkimine ja tõrked jäävad eraldi.
Üks seade võib korraga vaadata kahes suunas: rändavad kasutajad ühenduvad sisse ja sama karp ühendub välja väljundpakkuja juurde, et valitud liiklus lahkuks teise võrgu kaudu. Mõlema teenuse lubamine võtab minuteid; nende koos eksisteerimine nõuab projekti, sest teine roll kirjutab ümber marsruutimistabeli, millest esimene sõltub. Kolm tingimust otsustavad, kas lahendus töötab, nimelt kas sissetulev teenus hoiab oma tagasiteed, kas väljuv tunnel jõuab ikka oma partnerini ja kas liiklus, mida tahtsite edasi suunata, valitakse väljundi jaoks. Kui eksite ühes, saate kaks tunnelit, mis mõlemad teatavad ühendusest, samal ajal kui nende vahel ei liigu midagi kasulikku. Allolevad kontrollid kinnitavad iga tingimuse selles järjekorras, milles tõrked tavaliselt ilmuvad.
Nimetage kaks rolli enne, kui puudutate ühtegi seadet
Kirjutage iga eksemplari kohta üles neli fakti: selle kaugpartner, autentimismaterjal, väljastatav aadressikogum ja selle taga olevad võrgud. Kaks eksemplari on seadmel eraldi objektid ja peaksid jääma eraldi ka teie märkmetes. Peaaegu iga segadust tekitav sümptom hiljem tuleneb nende väärtuste segamini ajamisest, ja kaks eksemplari, mis jagavad üht märkmete kogumit, on viis, kuidas vale kogum satub valesse välja.
Sissetulev teenus vajab tunnelivõrku, mis ei kattu väljuva tunneli aadressidega ega ühegi privaatvõrguga, mida seade marsruudib. Kattumine on ainus viga, mis tekitab sümptomeid mõlemas rollis korraga, ja paberil on seda palju odavam tabada. Võrrelge mõlemat kogumit ja iga marsruuditud privaatvõrku ühes kohas enne, kui konfigureerite kumbagi teenust.
Jagatud riistvara ei tähenda jagatud volitusi, ja kaugjuurdepääsu kogumist pärit kliendisertifikaat ei peaks olema väljundpakkuja vastu kasutatav. Eraldi materjal muudab ka tühistamise kohalikuks otsuseks, mitte kogu parve sündmuseks.
Hoidke serveri vastused WAN-teel
Vastused, mille seade ise genereerib, on hooletu vaikemarsruudi esimene ohver. Kui rändava kasutaja kapseldatud pakett saabub, on vastus kohapeal tekkinud liiklus ja see peab lahkuma liidese kaudu, mille kaudu see kasutaja tuli. Kui väljuv klient on paigaldanud vaikemarsruudi, mis selle kinni püüab, satub vastus valesse tunnelisse ja seanss jääb seisma, samal ajal kui teenus näib endiselt terve.
Ükski märkeruut ei lahenda seda, sest otsus puudutab seda, millist liiklust väljuv klient võib kinni püüda. Kas ärge tõmmake ühtegi marsruuti ja suunake ainult seda, mille valite, või tõmmake marsruudid ja lisage erandid, mis hoiavad seadme enda teenused töös. Kirjutage valik eksemplari kõrvale, muidu eeldab järgmine inimene teist.
netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn
Lugege marsruutimistabelit pikima vaste järgi, mitte selle järjekorra järgi, milles te midagi konfigureerisite. Küsimus on, milline kirje võidab väljundpartneri aadressi jaoks ja milline kirje võidab sissetuleva teenuse vastuse jaoks, ning need kaks vastust võivad erineda.
Ärge laske väljuval tunnelil oma lõpp-punkti ära süüa
Väljuv klient peab jõudma oma partneri avaliku aadressini, et tunnel üldse üles seada. Kui see aadress ise on tunnelisse marsruuditud, ajab klient oma saba taga: transport ei tõuse kunagi või tõuseb ja kukub hetkel, mil marsruut paigaldatakse. Logi näeb välja nagu autentimise aegumine, mitte marsruutimise viga, mistõttu marsruut väärib esimest kontrolli.
Kontrollige marsruuti enne volitusi ja uuesti pärast seda, kui tunnel üleval on, sest kirje võib käivitamisel olla õige ja minut hiljem vale. Partneri aadress peab osutama tavalisele WAN-teele, mitte kunagi tunneliseadmele. Kui transport on stabiliseerunud, liigub huvitav küsimus edasisaadetavale liiklusele, mis on järgmine otsus.
netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10
Valige, millised kasutajad väljundi saavad
Allikapoliitika kuulub sissepääsu juurde, kus liiklus seadmesse siseneb, seega valige kaugjuurdepääsu kogum või kitsamad identiteedid selle sees. Hoidke alles privaatsed sihtkohad ja halduserandid, mida ei tohi kunagi väljundisse saata, ja asetage need reeglid laia reegli ette. Seejärel vajab väljundtee oma tõlget või marsruuditud tagasilahendust, mis enamiku projektide puhul tähendab väljuvat NAT-i väljundliidesel, mis katab kogumi. Tõlkimine ei vali väljundit; see kirjutab ümber ainult selle, mis on juba lahkunud, seega NAT-reegel mitteseotud WAN-il ei muuda valikus midagi.
Kinnitage, et kaugpool lubab sellest lahendusest edasisaadetavat liiklust, sest mõned pakkujad lubavad ja mõned mitte. Erinevus ilmneb tunnelina, mis ühendub ja ei kanna midagi, mida on lihtne kohalikuks tõrkeks lugeda. Testige kolme voogu eraldi, sest need ebaõnnestuvad sõltumatult ja kaks kolmest on pooleli ehitatud projekt.
openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health
Esimene käsk on rändava kasutaja väline ühendus ja see töötab siis, kui klient teatab, et lähtestamisjärjestus on lõpetatud. Teine, mis käivitatakse sellest ühendatud sülearvutist, peaks teatama väljundpakkuja aadressi, mitte teie WAN-aadressi. Kolmas töötab seadmel, olles seotud kogumi aadressiga, ja testib allikapoliitikat edasisaadetava liikluse jaoks, kaasamata üldse kaugkasutajat. Kui see vastab hoopis WAN-ist, siis poliitika ei sobitunud ja ükski NAT-i muudatus ei paranda valikuprobleemi.
Otsustage, mis juhtub, kui väljund ebaõnnestub
Kirjutage tõrke käitumine üles enne, kui see juhtub: kui väljuv tunnel kukub, kas kasutajad langevad tagasi tavalisele WAN-ile või blokeeritakse, kuni väljund naaseb? Mõlemad vastused on kaitstavad ja seade ei vali teie eest. Eemaldatud marsruut või surnud lüüsile osutav poliitika ei anna automaatselt täieliku blokeeringu tulemust. Kui soovite blokeerimist, peab poliitika seda selgesõnaliselt ütlema ja seda tuleb testida väljundi äravõtmisega, mitte selle üle arutlemisega. Kui soovite tagasilangust, teatage sellest kasutajatele, sest liiklus, mis vaikselt tavalisele teele läheb, on täpselt see liiklus, mida keegi arvas olevat kaetud.
Keelake kliendi eksemplar, vaadake, milleni ühendatud kasutaja veel jõuab, ja käivitage see seejärel uuesti. Päring, mis aegub, on täieliku blokeeringu tulemus, mida palusite; see, mis vastab WAN-aadressiga, on tagasilangus, mida te ei dokumenteerinud. Korrake kontrolli IPv6 ja DNS-i jaoks, sest IPv4 jaoks kirjutatud poliitika ei ütle AAAA-liikluse kohta midagi ja ükskõik millise tunneliga läbi surutud resolver vastab sealt, kust päring tegelikult väljub.
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'i marsruuditud OpenVPN retsept näitab, kuidas allikapoliitika, liidese määramine ja väljuv tõlkimine kokku sobivad, ja selle saidi-vaheline ulatus on osa, mida ei tohiks tervikuna kopeerida. Mida see teile ei ütle, on see, millise kolmest ülaltoodud tingimusest teie enda projekt juba rikkunud on.