Hvorfor SSL VPN og nettsted-til-nettsted-VPN ikke er motsetninger
SSL VPN og nettsted-til-nettsted beskriver forskjellige akser: hvem som kobler seg til nettverket, og hvordan tunnelen bygges. Å nevne begge samtidig er en kategorifeil.
Be to administratorer beskrive den samme VPN-en, og den ene svarer kanskje «SSL VPN» mens den andre sier «nettsted-til-nettsted», som om de to var konkurrerende valg i en meny. De er svar på forskjellige spørsmål, og å behandle dem som alternativer gir sammenligninger som ikke kan avgjøres. Den ene etiketten sier hvilke endepunkter som kobles sammen; den andre sier hva som bærer trafikken mellom dem. Hold aksene atskilt, og det meste av diskusjonen forsvinner.
To etiketter, to atskilte spørsmål
Topologi svarer på hvem som kobler seg til hva. En fjernaksessdesign kobler enkeltbrukere eller -enheter til en gateway, vanligvis med identitet per bruker og en pool med adresser. En nettsted-til-nettsted-design kobler to nettverk sammen gjennom gatewayer, så den interessante identiteten er partner-gatewayen og ikke personen ved tastaturet. Dette er forskjellige driftsproblemer, fra adresseplanlegging til hvem som kan tilbakekalle tilgang klokken 2 om natten.
Mekanisme svarer på hvordan tunnelen bygges og autentiseres. IPsec med IKEv2, et TLS-basert produkt som bærer IP inne i seg, og en nettleserrettet applikasjonsportal er mekanismevalg, og hver har sin egen forhandling, chifferpakker og feilmoduser. Ingen av dem innebærer en topologi, og en topologi velger ikke en mekanisme.
Sett de to aksene i én tabell, og forvirringen blir synlig, fordi hver celle i rutenettet kan fylles. Det rutenettet ikke kan gjøre, er å fortelle deg hvilken kombinasjon leverandøren din leverte, siden produktnavn smelter begge aksene sammen til én markedsføringsfrase.
Hvor kategorifeilen kommer fra
Leverandører solgte «SSL VPN» i årevis som det motsatte av «IPsec VPN», noe som fikk en mekanismesammenligning til å se ut som et topologivalg. Uttrykket har også blitt dårlig eldet på egne vilkår, siden dagens design bruker støttede TLS-versjoner, og navnet 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 beslektede myter følger av den samme sammensmeltingen. Den første er at IPsec betyr nettsted-til-nettsted; IKEv2 ble også designet for klient-til-gateway-forhold, så en enkelt bærbar PC kan koble seg til med IPsec. Den andre er at et TLS-basert produkt bare betyr fjernaksess; OpenVPN brukes rutinemessig til å bære trafikk mellom to nettsteder, og TLS-bruken er konsentrert i kontroll- og autentiseringsutvekslingen snarere enn i en nettleserøkt.
En nyttig test for enhver beskrivelse: hvis det å bytte ut ett ord endrer både endepunktene og protokollen, blander setningen aksene. «SSL VPN kontra nettsted-til-nettsted» består ikke den testen, fordi det første begrepet navngir en mekanismefamilie og det andre en topologi.
Beskriv en utrulling slik at den kan sammenlignes
Skriv fire felt og fyll dem ut: endepunkter, mekanisme, autentisering og tilgangsflate. En filialforbindelse kan leses som et IKEv2-gatewaypar mellom to navngitte prefikser med sertifikatautentisering og uten portal på brukernivå. En fjernaksesstjeneste kan leses som en TLS-basert klient som tildeler adresser per bruker, krever en andre faktor ved pålogging og bare publiserer en intern DNS-sone.
Disse setningene er sammenlignbare på en måte produktnavn ikke er. To fjernaksessdesigner kan måles mot samme brukerarbeidsflyt og samme tilbakekallingsvei, og to mellomnettsteddesigner mot samme prefiksliste, trafikkpolitikk og feilkrav. Etikettene organiserer sammenligningen; de erstatter den ikke.
Terminologien har også et publisert anker. IETFs dokument om VPN-terminologi skiller flere tjenestemodeller, inkludert fjernaksess og nettsted-til-nettsted, fra mekanismene de bygges med, og det er nettopp den forskjellen som stadig går tapt.
Les den forhandlede protokollen, ikke produktnavnet
Etiketten på esken fastslår ikke hva en kjørende tunnel har blitt enige om. Spør motparten direkte, på TLS-siden, og les protokollversjonen og chifferen som håndtrykket produserte, i stedet for versjonen i brosjyren.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefFor en IPsec-gateway kommer den tilsvarende observasjonen fra implementeringens egen statusutskrift, som rapporterer IKE- og ESP-forslagene som brukes. Uansett er poenget det samme: mekanismeaksen må leses fra den levende økten, fordi en klient og en gateway kan forhandle ned til noe eldre enn noen av administratorene forventet.
ipsec statusall | grep -E "IKE|ESP"Etter det står spørsmålene som ingen etikett besvarer igjen. Hvilke protokollversjoner godtas fortsatt, hvordan valideres gatewayens identitet, hvilket algoritmesett er tillatt, hvem autoriserer en gitt bruker for en gitt ressurs, og hva tilbakekaller tilgang når en enhet går tapt. Et topologidiagram og et mekanismenavn er begynnelsen på den listen, ikke en erstatning for den.
Behold altså de to etikettene, men bruk dem til det de er: en kort måte å si hvilke endepunkter som kobles sammen og hvordan tunnelen bygges. I det øyeblikket den ene brukes til å utelukke den andre, har beskrivelsen sluttet å beskrive noe.