Waarom SSL-VPN en site-tot-site-VPN nie teenoorgesteldes is nie
SSL-VPN en site-tot-site beskryf verskillende asse: wie by die netwerk aansluit en hoe die tonnel gebou word. Om albei te noem, begaan die kategorie-fout.
Vra twee administrateurs om dieselfde VPN te beskryf, en een antwoord miskien “SSL VPN” terwyl die ander “site-tot-site” sê, asof die twee mededingende opsies in ’n kieslys was. Hulle is antwoorde op verskillende vrae, en om hulle as alternatiewe te behandel, lewer vergelykings op wat nie opgelos kan word nie. Die een etiket sê watter eindpunte verbind word; die ander sê wat die verkeer tussen hulle dra. Hou die asse uitmekaar, en die meeste van die argument verdwyn.
Twee etikette, twee aparte vrae
Topologie antwoord wie by wat aansluit. ’n Afstandstoegang-ontwerp heg individuele gebruikers of toestelle aan ’n poort aan, gewoonlik met per-gebruiker-identiteit en ’n poel adresse. ’n Site-tot-site-ontwerp verbind twee netwerke deur poorte, so die interessante identiteit is die eweknie-poort eerder as die persoon by ’n sleutelbord. Dit is verskillende bedryfsprobleme, van adresbeplanning tot wie toegang om 2 vm. kan intrek.
Meganisme antwoord hoe die tonnel gebou en geauthentiseer word. IPsec met IKEv2, ’n TLS-gebaseerde produk wat IP binne-in dra, en ’n blaaiergerigte toepassingsportaal is meganisme-keuses, en elkeen het sy eie onderhandeling, syfersuites en foutmodusse. Nie een daarvan impliseer ’n topologie nie, en ’n topologie kies nie ’n meganisme nie.
Sit die twee asse in een tabel en die verwarring word sigbaar, want elke sel van die rooster kan gevul word. Wat die rooster nie kan doen nie, is om vir jou te sê watter kombinasie jou verskaffer gelewer het, want produkname vou beide asse in een bemarkingsfrase saam.
Waar die kategorie-fout vandaan kom
Verskaffers het jare lank “SSL VPN” as die teenoorgestelde van “IPsec VPN” verkoop, wat ’n meganisme-vergelyking soos ’n topologie-keuse laat lyk het. Die frase het ook op sy eie terme sleg verouder, want huidige ontwerpe gebruik ondersteunde TLS-weergawes en die SSL-naam oorleef hoofsaaklik as ’n produk-kategorie.
| 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 |
Twee verwante mites volg uit dieselfde ineenstorting. Die eerste is dat IPsec site-tot-site beteken; IKEv2 is ook vir kliënt-tot-poort-verhoudings ontwerp, so ’n individuele skootrekenaar kan met IPsec aansluit. Die tweede is dat ’n TLS-gebaseerde produk slegs afstandstoegang beteken; OpenVPN word gereeld gebruik om verkeer tussen twee sites te dra, en sy TLS-gebruik is gekonsentreer in die beheer- en authentiseringsuitruiling eerder as in ’n blaaier-sessie.
’n Nuttige toets vir enige beskrywing: as die omruil van een woord beide die eindpunte en die protokol verander, meng die sin die asse. “SSL VPN teenoor site-tot-site” slaag nie daardie toets nie, want die eerste term noem ’n meganisme-familie en die tweede noem ’n topologie.
Beskryf ’n ontplooiing sodat dit vergelyk kan word
Skryf vier slots en vul hulle in: eindpunte, meganisme, authenticering en toegangsoppervlak. ’n Takskakel kan lees as ’n IKEv2-poortpaar tussen twee genoemde voorvoegsels met sertifikaat-authentisering en geen gebruikervlak-portaal nie. ’n Afstandstoegang-diens kan lees as ’n TLS-gebaseerde kliënt wat per-gebruiker-adresse toeken, ’n tweede faktor by aanmelding vereis en slegs ’n interne DNS-sone publiseer.
Daardie sinne is vergelykbaar op ’n manier wat produkname nie is nie. Twee afstandstoegang-ontwerpe kan teen dieselfde gebruikerswerkvloei en dieselfde herroepingspad gemeet word, en twee intersite-ontwerpe teen dieselfde voorvoegsellys, verkeersbeleid en foutvereistes. Die etikette organiseer die vergelyking; hulle vervang dit nie.
Die terminologie het ook ’n gepubliseerde anker. Die IETF se dokument oor VPN-terminologie skei verskeie diensmodelle, insluitend afstandstoegang en site-tot-site, van die meganismes wat gebruik word om hulle te bou, wat presies die onderskeid is wat aanhoudend verlore gaan.
Lees die onderhandelde protokol, nie die produknaam nie
Die etiket op die boks bepaal nie waartoe ’n lopende tonnel ooreengekom het nie. Vra die eweknie direk, aan die TLS-kant, en lees die protokolweergawe en syfer wat die handdruk opgelewer het eerder as die weergawe in die brosjure.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefVir ’n IPsec-poort kom die ekwivalente waarneming uit die implementering se eie statusuitset, wat die IKE- en ESP-voorstelle in gebruik rapporteer. Hoe dit ook al sy, die punt is dieselfde: die meganisme-as moet uit die lewende sessie gelees word, want ’n kliënt en poort kan afonderhandel na iets ouer as wat enige van die administrateurs verwag het.
ipsec statusall | grep -E "IKE|ESP"Daarna is die oorblywende vrae dié wat geen etiket antwoord nie. Watter protokolweergawes word nog aanvaar, hoe word die poort se identiteit gevalideer, watter algoritme-stel word toegelaat, wie magtig ’n gegewe gebruiker vir ’n gegewe hulpbron, en wat trek toegang in wanneer ’n toestel verlore gaan. ’n Topologie-diagram en ’n meganisme-naam is die begin van daardie lys, nie ’n plaasvervanger daarvoor nie.
Hou dus die twee etikette, maar gebruik hulle vir wat hulle is: ’n kort manier om te sê watter eindpunte verbind word en hoe die tonnel gebou word. Die oomblik wat enige een gebruik word om die ander uit te sluit, het die beskrywing opgehou om enigiets te beskryf.