Kvifor SSL VPN og nettstad-til-nettstad-VPN ikkje er motsetnader
SSL VPN og nettstad-til-nettstad skildrar ulike aksar: kven som koplar seg til nettet, og korleis tunnelen blir bygd. Å nemne begge samstundes er ein kategorifeil.
Be to administratorar skildre den same VPN-en, og den eine svarar kanskje «SSL VPN» medan den andre seier «nettstad-til-nettstad», som om dei to var konkurrerande val i ein meny. Dei er svar på ulike spørsmål, og å handsame dei som alternativ gir samanlikningar som ikkje kan avgjerast. Den eine etiketten seier kva endepunkt som blir knytte saman; den andre seier kva som ber trafikken mellom dei. Hald aksane åtskilde, og det meste av diskusjonen forsvinn.
To etikettar, to åtskilde spørsmål
Topologi svarar på kven som koplar seg til kva. Eit fjernaksessdesign koplar einskildbrukarar eller -einingar til ein gateway, vanlegvis med identitet per brukar og ein pool med adresser. Eit nettstad-til-nettstad-design koplar to nettverk saman gjennom gatewayar, så den interessante identiteten er partnargatewayen og ikkje personen ved tastaturet. Dette er ulike driftsproblem, frå adresseplanlegging til kven som kan trekkje tilbake tilgang klokka 2 om natta.
Mekanisme svarar på korleis tunnelen blir bygd og autentisert. IPsec med IKEv2, eit TLS-basert produkt som ber IP inne i seg, og ein nettlesarretta applikasjonsportal er mekanismeval, og kvar har si eiga forhandling, chifferpakkar og feilmodusar. Ingen av dei inneber ein topologi, og ein topologi vel ikkje ein mekanisme.
Set dei to aksane i éin tabell, og forvirringa blir synleg, fordi kvar celle i rutenettet kan fyllast. Det rutenettet ikkje kan gjere, er å fortelje deg kva kombinasjon leverandøren din leverte, sidan produktnamn smeltar begge aksane saman til éin marknadsføringsfrase.
Kvar kategorifeilen kjem frå
Leverandørar selde «SSL VPN» i årevis som det motsette av «IPsec VPN», noko som fekk ei mekanismesamanlikning til å sjå ut som eit topologival. Uttrykket har òg blitt dårleg elda på eigne vilkår, sidan dagens design brukar støtta TLS-versjonar, og namnet SSL overlever mest som produktkategori.
| 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 |
To skylde mytar følgjer av den same samansmeltinga. Den første er at IPsec tyder nettstad-til-nettstad; IKEv2 blei òg designa for klient-til-gateway-tilhøve, så ein einaste berbar PC kan kopie seg til med IPsec. Den andre er at eit TLS-basert produkt berre tyder fjernaksess; OpenVPN blir rutinemessig brukt til å bere trafikk mellom to nettstader, og TLS-bruken er konsentrert i kontroll- og autentiseringsutvekslinga snarare enn i ein nettlesarøkt.
Ein nyttig test for kva som helst skildring: viss det å byte ut eitt ord endrar både endepunkta og protokollen, blandar setninga aksane. «SSL VPN kontra nettstad-til-nettstad» står ikkje den testen, fordi det første omgrepet namngir ein mekanismefamilie og det andre ein topologi.
Skildre ein utrulling slik at han kan samanliknast
Skriv fire felt og fyll dei ut: endepunkt, mekanisme, autentisering og tilgangsflate. Ei filialforbindelse kan lesast som eit IKEv2-gatewaypar mellom to namngjevne prefiks med sertifikatautentisering og utan portal på brukarnivå. Ein fjernaksessteneste kan lesast som ein TLS-basert klient som tildeler adresser per brukar, krev ein andre faktor ved pålogging og berre publiserer ei intern DNS-sone.
Desse setningane er samanliknbare på ein måte produktnamn ikkje er. To fjernaksessdesign kan målast mot same brukararbeidsflyt og same tilbakekallingsveg, og to mellom-nettstad-design mot same prefiksliste, trafikkpolitikk og feilkrav. Etikettane organiserer samanlikninga; dei erstattar henne ikkje.
Terminologien har òg eit publisert anker. IETF-dokumentet om VPN-terminologi skil fleire tenestemodellar, inkludert fjernaksess og nettstad-til-nettstad, frå mekanismane dei blir bygde med, og det er nettopp den skilnaden som stadig går tapt.
Les den forhandla protokollen, ikkje produktnamnet
Etiketten på eska fastslår ikkje kva ein køyrande tunnel har blitt samde om. Spør motparten direkte, på TLS-sida, og les protokollversjonen og chifferen som handtrykket produserte, i staden for versjonen i brosjyren.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefFor ein IPsec-gateway kjem den tilsvarande observasjonen frå implementasjonen si eiga statusutskrift, som rapporterer IKE- og ESP-forslaga som blir brukte. Uansett er poenget det same: mekanismeaksen må lesast frå den levande økta, fordi ein klient og ein gateway kan forhandle ned til noko eldre enn nokon av administratorane venta.
ipsec statusall | grep -E "IKE|ESP"Etter det står spørsmåla som ingen etikett svarar på att. Kva protokollversjonar blir framleis godtekne, korleis blir identiteten til gatewayen validert, kva algoritmesett er tillate, kven autoriserer ein gjeven brukar for ein gjeven ressurs, og kva trekkjer tilbake tilgang når ei eining går tapt. Eit topologidiagram og eit mekanismenamn er byrjinga på den lista, ikkje ei erstatning for henne.
Hald altså dei to etikettane, men bruk dei til det dei er: ein kort måte å seie kva endepunkt som blir knytte saman og korleis tunnelen blir bygd. I det augneblunken den eine blir brukt til å utelukke den andre, har skildringa slutta å skildre noko.