De ce SSL VPN și VPN site-la-site nu sunt opuse
SSL VPN și VPN site-la-site descriu axe diferite: cine se alătură rețelei și cum este construit tunelul. A le numi pe amândouă deodată este o eroare de categorie.
Rugați doi administratori să descrie același VPN și unul poate răspunde „SSL VPN“, în timp ce celălalt spune „site-la-site“, ca și cum ar fi opțiuni rivale într-un meniu. Sunt răspunsuri la întrebări diferite, iar tratarea lor ca alternative produce comparații care nu pot fi rezolvate. O etichetă spune ce puncte terminale sunt unite; cealaltă spune ce transportă traficul dintre ele. Țineți axele separate și cea mai mare parte a dezbaterii dispare.
Două etichete, două întrebări separate
Topologia răspunde cine se alătură la ce. Un proiect de acces la distanță conectează utilizatori sau dispozitive individuale la un gateway, de obicei cu identitate per utilizator și un pool de adrese. Un proiect site-la-site unește două rețele prin gateway-uri, așa că identitatea interesantă este gateway-ul partener, nu persoana de la tastatură. Acestea sunt probleme operaționale diferite, de la planificarea adreselor până la cine poate revoca accesul la ora 2 dimineața.
Mecanismul răspunde cum este construit și autentificat tunelul. IPsec cu IKEv2, un produs bazat pe TLS care transportă IP în interior, și un portal de aplicații orientat spre browser sunt alegeri de mecanism, iar fiecare are propria negociere, propriile suite de cifrare și propriile moduri de eșec. Niciunul nu implică o topologie, iar o topologie nu alege un mecanism.
Puneți cele două axe într-un singur tabel și confuzia devine vizibilă, pentru că fiecare celulă a grilei poate fi umplută. Ce nu poate face grila este să vă spună ce combinație a livrat furnizorul dumneavoastră, deoarece numele de produs comprimă ambele axe într-o singură expresie de marketing.
De unde vine eroarea de categorie
Furnizorii au vândut „SSL VPN“ ani de zile ca opus al „IPsec VPN“, ceea ce făcea o comparație de mecanisme să pară o alegere de topologie. Expresia a îmbătrânit prost și în propriii termeni, deoarece proiectele actuale folosesc versiuni TLS acceptate, iar numele SSL supraviețuiește mai ales ca categorie de produs.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
Din aceeași comprimare decurg două mituri înrudite. Primul este că IPsec înseamnă site-la-site; IKEv2 a fost proiectat și pentru relații client-gateway, așa că un laptop individual se poate alătura cu IPsec. Al doilea este că un produs bazat pe TLS înseamnă doar acces la distanță; OpenVPN este folosit în mod obișnuit pentru a transporta trafic între două situri, iar utilizarea sa de TLS se concentrează pe schimbul de control și autentificare, nu pe o sesiune de browser.
Un test util pentru orice descriere: dacă schimbarea unui cuvânt modifică atât punctele terminale, cât și protocolul, propoziția amestecă axele. „SSL VPN versus site-la-site“ nu trece acest test, deoarece primul termen numește o familie de mecanisme, iar al doilea o topologie.
Descrieți o implementare astfel încât să poată fi comparată
Scrieți patru câmpuri și completați-le: puncte terminale, mecanism, autentificare și suprafață de acces. O legătură de sucursală poate fi citită ca o pereche de gateway-uri IKEv2 între două prefixe numite, cu autentificare prin certificat și fără portal la nivel de utilizator. Un serviciu de acces la distanță poate fi citit ca un client bazat pe TLS care alocă adrese per utilizator, cere un al doilea factor la autentificare și publică doar o zonă DNS internă.
Aceste propoziții sunt comparabile într-un mod în care numele de produs nu sunt. Două proiecte de acces la distanță pot fi măsurate față de același flux de lucru al utilizatorului și aceeași cale de revocare, iar două proiecte între situri față de aceeași listă de prefixe, politică de trafic și cerințe de eșec. Etichetele organizează comparația; nu o înlocuiesc.
Terminologia are și un punct de sprijin publicat. Documentul IETF despre terminologia VPN separă mai multe modele de serviciu, inclusiv accesul la distanță și site-la-site, de mecanismele cu care sunt construite, iar aceasta este exact distincția care se pierde mereu.
Citiți protocolul negociat, nu numele produsului
Eticheta de pe cutie nu stabilește la ce a căzut de acord un tunel în funcțiune. Întrebați partenerul direct, pe partea TLS, și citiți versiunea de protocol și cifrul pe care le-a produs strângerea de mână, în locul versiunii din broșură.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefPentru un gateway IPsec observația echivalentă vine din ieșirea de stare a implementării înseși, care raportează propunerile IKE și ESP utilizate. În orice caz, ideea este aceeași: axa mecanismului trebuie citită din sesiunea vie, pentru că un client și un gateway pot negocia în jos către ceva mai vechi decât se aștepta oricare administrator.
ipsec statusall | grep -E "IKE|ESP"După aceea, întrebările care rămân sunt cele la care niciun etichetă nu răspunde. Ce versiuni de protocol mai sunt acceptate, cum este validată identitatea gateway-ului, ce set de algoritmi este permis, cine autorizează un anumit utilizator pentru o anumită resursă și ce revocă accesul atunci când un dispozitiv se pierde. O diagramă de topologie și un nume de mecanism sunt începutul acelei liste, nu un substitut al ei.
Păstrați deci cele două etichete, dar folosiți-le pentru ceea ce sunt: o modalitate scurtă de a spune ce puncte terminale sunt unite și cum este construit tunelul. În momentul în care una este folosită pentru a o exclude pe cealaltă, descrierea a încetat să descrie ceva.