Cine răspunde de fapt la adresa dedicată a VPN-ului?

O adresă care stă nefolosită în alocarea organizației nu este un ascultător, iar adăugarea ei la un firewall nu creează niciunul. Ceva trebuie să încheie IKE pe acea adresă, iar mecanismul diferă în funcție de faptul că gateway-ul deține adresa sau un dispozitiv din amonte o traduce. Calea pachetului este cea care le distinge, și ea decide de ce funcție a platformei aveți nevoie înainte ca cineva să deschidă o cerere de schimbare. Modelați mai întâi calea, apoi alegeți.

Calea pachetului din spatele adresei

Un partener trimite IKE la adresa pe care a primit-o, pe UDP 500 sau pe UDP 4500 când este implicată traversarea NAT. Dispozitivul care deține acea adresă pe cale fie primește datagrama local și răspunde la ea, fie o redirecționează în altă parte. Acestea sunt singurele două posibilități, iar tot restul din acest articol decurge din care dintre ele este adevărată.

Primirea locală înseamnă că pe acel dispozitiv există un socket, legat de acea adresă. Redirecționarea înseamnă că datagrama este rescrisă și trimisă mai departe către un alt punct final, care are atunci socketul. O regulă de firewall care permite UDP 500 nu vă spune nimic despre care dintre cele două se întâmplă.

Scrieți înregistrarea înainte de a atinge ceva: adresa cu care contactează partenerii, cum o livrează rețeaua din amonte, interfața locală sau punctul final logic care o primește, și procesul care răspunde la IKE. Patru rânduri, și fiecare poate fi verificat. Când unul dintre ele este necunoscut, acel necunoscut este munca de proiectare, nu un detaliu de implementare de lămurit mai târziu. Completarea lor după aprobarea cererii de schimbare este modul în care o regulă de traducere ajunge pe dispozitivul greșit.

Modelul A: gateway-ul deține adresa

În primul model gateway-ul deține adresa însuși, fie ca adresă secundară pe o interfață existentă, fie ca adresă pe o interfață dedicată, fie ca loopback pe care platforma îl acceptă ca punct final de tunel. Sunt trei funcții diferite cu trei căi de configurare diferite, iar o platformă care o acceptă pe una s-ar putea să nu le accepte pe celelalte.

Confirmați că platforma și versiunea acceptă exact această aranjare înainte de a proiecta în jurul ei. Un bloc rutat, o adresă suplimentară pe o interfață și un punct final loopback nu sunt interschimbabile, iar documentația unei versiuni nu promite că următoarea se comportă la fel.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Socketul care ascultă este dovada. Dacă nimic nu este legat de adresă, gateway-ul nu este terminatoarea indiferent ce spune tabela de rutare, iar o captură de pachete va arăta datagramele sosind fără nimic care să le răspundă.

Nu puneți o a doua interfață într-o subrețea care există deja altundeva în topologie și nu presupuneți că platforma va rezolva asta. Subrețelele de interfață suprapuse produc o selecție ambiguă a sursei și, pe multe platforme, un refuz complet de configurare.

Modelul B: un dispozitiv din amonte o traduce

În al doilea model un firewall din amonte deține adresa dedicată și redirecționează traficul către un alt gateway VPN. Aceasta este o traducere de destinație cu cale de întoarcere și este un proiect perfect valid atât timp cât este documentat ca atare.

Ce nu este, este dovada că dispozitivul din amonte a obținut un socket VPN local. Traducerea redirecționează pachete; nu face din cutia superioară un respondător IKE. Dacă regula din amonte este eliminată sau calea ei de întoarcere se rupe, VPN-ul se oprește chiar dacă gateway-ul este sănătos și ascultătorii săi sunt intacți.

Înregistrați ambele adrese: cea cu care contactează partenerii și cea pe care gateway-ul o vede efectiv. Apoi înregistrați transportul și calea de întoarcere, deoarece o traducere care funcționează pentru UDP 500 dar nu pentru ESP încapsulat se va conecta și apoi nu va putea transporta trafic, ceea ce este o defecțiune confuză de depanat mai târziu.

Identitatea nu este adresa exterioară

IPsec separă punctul final al tunelului de traficul pe care îl protejează, iar arhitectura ține aceste decizii în locuri diferite. Schimbarea adresei cu care contactează partenerii nu schimbă automat ce prefixe interne sunt permise, ce rute sunt instalate sau la ce resurse poate ajunge sesiunea.

Identitatea autentificată este din nou separată. IKEv2 transportă o încărcătură de identitate și un schimb de autentificare care nu trebuie să corespundă adresei exterioare a pachetului, și exact de aceea un proiect tradus poate încă autentifica corect.

Acea independență este utilă și totodată o capcană. Două nume DNS care se rezolvă la un ascultător obișnuit nu selectează backend-uri VPN diferite, iar un certificat care numește o identitate nu va satisface un partener care așteaptă alta. Confirmați ce validează partenerul înainte de a presupune că doar adresa decide acest lucru.

Acceptați proiectul observând o singură conexiune

Inspectați unde este livrată efectiv o nouă conexiune autorizată, ce identitate răspunde și ce flux privat este apoi permis. Trei observații, trei straturi diferite, iar o căutare publică reușită a adresei nu testează niciuna dintre ele.

Păstrați și cazul negativ: un partener care nu ar trebui acceptat, sau un prefix intern care nu ar trebui să fie accesibil, verificat după schimbare. Înregistrarea scrisă la început este cea care face posibil acel test fără a reconstrui proiectul din memorie.

Sensul tuturor acestora este să îi permită proprietarului rețelei să aleagă o metodă de alocare acceptată, în loc să se bazeze pe o afirmație generală despre ce poate face fiecare firewall cu o adresă suplimentară. Exact acea afirmație este locul unde aceste proiecte eșuează, pentru că sună plauzibil pe fiecare platformă și în general nu este adevărată pe niciuna. Înregistrarea de patru rânduri lămurește acest lucru pentru platforma dumneavoastră în zece minute.