pfSense ca server și client VPN: două căi, un singur router

Un singur echipament poate privi în două direcții deodată: utilizatorii itineranți se conectează spre interior, iar aceeași cutie se conectează spre exterior la un furnizor de ieșire, astfel încât traficul selectat să iasă prin altă rețea. Activarea ambelor servicii durează minute; conviețuirea lor cere un proiect, fiindcă al doilea rol rescrie tabela de rutare pe care se sprijină primul. Trei condiții decid dacă aranjamentul funcționează, anume dacă serviciul de intrare își păstrează propria cale de întoarcere, dacă tunelul de ieșire mai ajunge la partenerul său și dacă traficul pe care voiai să îl transmiți este selectat pentru ieșire. Greșești una și obții două tuneluri care ambele raportează conectat în timp ce nimic util nu trece între ele. Verificările de mai jos stabilesc fiecare condiție în ordinea în care defecțiunile apar de obicei.

Numește cele două roluri înainte de a atinge vreo setare

Notează patru fapte pentru fiecare instanță: partenerul ei îndepărtat, materialul de autentificare, pool-ul de adrese pe care îl distribuie și rețelele din spatele ei. Cele două instanțe sunt obiecte separate pe echipament și ar trebui să rămână separate și în notițele tale. Aproape fiecare simptom încurcător ulterior vine din amestecarea valorilor lor, iar două instanțe care împart un singur set de notițe este felul în care pool-ul greșit ajunge în câmpul greșit.

Serviciul de intrare are nevoie de o rețea de tunel care să nu se suprapună cu adresele tunelului de ieșire sau cu vreo rețea privată pe care echipamentul o rutează. Suprapunerea este singura greșeală care produce simptome în ambele roluri deodată, și e mult mai ieftin de prins pe hârtie. Compară ambele pool-uri și fiecare rețea privată rutată într-un singur loc înainte de a configura oricare dintre servicii.

Hardware partajat nu înseamnă acreditări partajate, iar un certificat de client din pool-ul de acces la distanță nu ar trebui să fie utilizabil împotriva furnizorului de ieșire. Materialul separat face și revocarea o decizie locală în loc de un eveniment pentru întreaga flotă.

Ține răspunsurile serverului pe calea WAN

Răspunsurile pe care echipamentul le generează singur sunt prima victimă a unei rute implicite neglijente. Când sosește pachetul encapsulat al unui utilizator itinerant, răspunsul este trafic originat local și trebuie să iasă prin interfața prin care a intrat acel utilizator. Dacă clientul de ieșire a instalat o rută implicită care îl capturează, răspunsul intră în tunelul greșit și sesiunea se blochează în timp ce serviciul încă pare sănătos.

Nu există o singură bifă care să rezolve asta, fiindcă decizia privește ce trafic poate captura clientul de ieșire. Fie nu tragi nicio rută și direcționezi doar ce selectezi, fie tragi rute și adaugi excepțiile care țin serviciile proprii ale echipamentului în funcțiune. Notează alegerea lângă instanță, altfel următoarea persoană o va presupune pe cealaltă.

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

Citește tabela de rutare după cea mai lungă potrivire și nu după ordinea în care ai configurat ceva. Întrebarea este care intrare câștigă pentru adresa partenerului de ieșire și care intrare câștigă pentru răspunsul serviciului de intrare, iar aceste două răspunsuri pot diferi.

Nu lăsa tunelul de ieșire să își mănânce propriul punct terminal

Clientul de ieșire trebuie să ajungă la adresa publică a partenerului său pentru a stabili tunelul măcar. Dacă acea adresă este ea însăși rutată în tunel, clientul își urmărește propria coadă: transportul nu urcă niciodată sau urcă și cade în momentul în care ruta se instalează. Jurnalul arată ca un timeout de autentificare și nu ca o defecțiune de rutare, de aceea ruta merită prima verificare.

Verifică ruta înainte de acreditări și din nou după ce tunelul e sus, fiindcă o intrare poate fi corectă la pornire și greșită un minut mai târziu. Adresa partenerului trebuie să indice calea WAN obișnuită, niciodată dispozitivul de tunel. Când transportul e stabil, întrebarea interesantă trece la traficul transmis, care este următoarea decizie.

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

Alege ce utilizatori primesc ieșirea

Politica de sursă aparține intrării unde traficul intră în echipament, așa că alege pool-ul de acces la distanță sau identități mai înguste în el. Păstrează destinațiile private și excepțiile de administrare care nu trebuie trimise niciodată la ieșire și pune acele reguli înaintea celei largi. Calea de ieșire are apoi nevoie de propria traducere sau de un aranjament de întoarcere rutat, ceea ce în majoritatea proiectelor înseamnă NAT de ieșire pe interfața de ieșire care acoperă pool-ul. Traducerea nu alege o ieșire; doar rescrie ce a plecat deja, așa că o regulă NAT pe un WAN nelegat nu schimbă nimic în selecție.

Confirmă că extremitatea îndepărtată permite traficul transmis din acest proiect, fiindcă unii furnizori permit și alții nu. Diferența apare ca un tunel care se conectează și nu transportă nimic, ceea ce e ușor de citit greșit ca o defecțiune locală. Testează cele trei fluxuri separat, fiindcă eșuează independent, iar două din trei este un proiect pe jumătate construit.

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

Prima comandă este conexiunea exterioară a utilizatorului itinerant și funcționează când clientul raportează că secvența de inițializare s-a încheiat. A doua, rulată de pe acel laptop conectat, ar trebui să raporteze adresa furnizorului de ieșire în locul adresei tale WAN. A treia rulează pe echipament legată de o adresă din pool și testează politica de sursă pentru traficul transmis fără a implica deloc un utilizator îndepărtat. Dacă răspunde din WAN în schimb, politica nu s-a potrivit, și nicio editare NAT nu repară o problemă de selecție.

Decide ce se întâmplă când ieșirea eșuează

Notează comportamentul la defecțiune înainte să se întâmple: când tunelul de ieșire cade, utilizatorii revin la WAN-ul obișnuit sau sunt blocați până când ieșirea revine? Ambele răspunsuri sunt defendabile, iar echipamentul nu va alege în locul tău. O rută eliminată sau o politică ce indică o poartă moartă nu produc automat un rezultat complet blocat. Dacă vrei blocare, politica trebuie să o spună explicit, și trebuie testată scoțând ieșirea, nu gândind despre ea. Dacă vrei revenire, publică asta utilizatorilor, fiindcă traficul care ia în liniște calea obișnuită este exact traficul pe care cineva credea că e acoperit.

Dezactivează instanța de client, observă la ce mai ajunge un utilizator conectat, apoi pornește-o din nou. O cerere care expiră este rezultatul complet blocat pe care l-ai cerut; una care răspunde cu adresa WAN este revenirea pe care nu ai documentat-o. Repetă verificarea pentru IPv6 și pentru DNS, fiindcă o politică scrisă pentru IPv4 nu spune nimic despre traficul AAAA, iar un resolver împins de oricare dintre tuneluri răspunde de unde iese de fapt interogarea.

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

Rețeta Netgate pentru OpenVPN rutat arată cum se potrivesc politica de sursă, alocarea interfeței și traducerea de ieșire, iar domeniul ei de la site la site este partea care nu trebuie copiată în întregime. Ce nu îți va spune este care dintre cele trei condiții de mai sus a fost deja încălcată de propriul tău proiect.