Hvorfor SSL VPN og site-til-site VPN ikke er modsætninger
SSL VPN og site-til-site beskriver forskellige akser: hvem der tilslutter sig netværket, og hvordan tunnelen bygges. At kalde begge dele på én gang er en kategorifejl.
Bed to administratorer om at beskrive den samme VPN, og den ene svarer måske „SSL VPN“, mens den anden siger „site-til-site“, som om de to var rivaliserende muligheder i en menu. De er svar på forskellige spørgsmål, og at behandle dem som alternativer giver sammenligninger, der ikke kan afgøres. Den ene betegnelse siger, hvilke endepunkter der sammenkobles; den anden siger, hvad der bærer trafikken mellem dem. Hold akserne adskilt, og det meste af diskussionen forsvinder.
To betegnelser, to adskilte spørgsmål
Topologi besvarer, hvem der tilslutter sig hvad. Et fjernadgangsdesign kobler enkelte brugere eller enheder til en gateway, normalt med identitet pr. bruger og en pulje af adresser. Et site-til-site-design sammenkobler to netværk gennem gateways, så den interessante identitet er peer-gatewayen snarere end personen ved tastaturet. Det er forskellige driftsproblemer, fra adresseplanlægning til hvem der kan tilbagekalde adgang kl. 2 om natten.
Mekanisme besvarer, hvordan tunnelen bygges og autentificeres. IPsec med IKEv2, et TLS-baseret produkt, der bærer IP inde i sig, og en browserrettet applikationsportal er mekanismevalg, og hver har sin egen forhandling, cipher-suiter og fejltilstande. Ingen af dem antyder en topologi, og en topologi vælger ikke en mekanisme.
Sæt de to akser i én tabel, og forvirringen bliver synlig, fordi hver celle i gitteret kan udfyldes. Det, gitteret ikke kan, er at fortælle dig, hvilken kombination din leverandør leverede, da produktnavne smelter begge akser sammen til én marketingfrase.
Hvor kategorifejlen kommer fra
Leverandører solgte „SSL VPN“ i årevis som det modsatte af „IPsec VPN“, hvilket fik en mekanismesammenligning til at ligne et topologivalg. Udtrykket er også blevet dårligt ældet på sine egne betingelser, da nutidige design bruger understøttede TLS-versioner, 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 beslægtede myter følger af den samme sammensmeltning. Den første er, at IPsec betyder site-til-site; IKEv2 blev også designet til klient-til-gateway-forhold, så en enkelt bærbar computer kan tilslutte sig med IPsec. Den anden er, at et TLS-baseret produkt kun betyder fjernadgang; OpenVPN bruges rutinemæssigt til at bære trafik mellem to sites, og dets TLS-brug er koncentreret i kontrol- og autentificeringsudvekslingen snarere end i en browsersession.
En nyttig test for enhver beskrivelse: hvis udskiftning af ét ord ændrer både endepunkterne og protokollen, blander sætningen akserne. „SSL VPN kontra site-til-site“ består ikke den test, fordi det første udtryk navngiver en mekanismefamilie, og det andet navngiver en topologi.
Beskriv en udrulning, så den kan sammenlignes
Skriv fire felter og udfyld dem: endepunkter, mekanisme, autentificering og adgangsflade. En filialforbindelse kan læses som et IKEv2-gatewaypar mellem to navngivne præfikser med certifikatautentificering og ingen portal på brugerniveau. En fjernadgangstjeneste kan læses som en TLS-baseret klient, der tildeler adresser pr. bruger, kræver en anden faktor ved login og kun publicerer en intern DNS-zone.
Disse sætninger er sammenlignelige på en måde, produktnavne ikke er. To fjernadgangsdesign kan måles mod den samme brugerarbejdsgang og den samme tilbagekaldelsesvej, og to mellemsite-design mod den samme præfikseliste, trafikpolitik og fejlkrav. Betegnelserne organiserer sammenligningen; de erstatter den ikke.
Terminologien har også et offentliggjort anker. IETF's dokument om VPN-terminologi adskiller flere servicemodeller, herunder fjernadgang og site-til-site, fra de mekanismer, der bruges til at bygge dem, og det er netop den sondring, der hele tiden går tabt.
Læs den forhandlede protokol, ikke produktnavnet
Etiketten på æsken fastslår ikke, hvad en kørende tunnel har accepteret. Spørg peer'en direkte, på TLS-siden, og læs den protokolversion og cipher, som håndtrykket frembragte, i stedet for versionen i brochuren.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefFor en IPsec-gateway kommer den tilsvarende observation fra implementeringens egen statusudskrift, som rapporterer de anvendte IKE- og ESP-forslag. Under alle omstændigheder er pointen den samme: mekanismeaksen skal læses fra den levende session, fordi en klient og en gateway kan forhandle ned til noget ældre, end nogen af administratorerne forventede.
ipsec statusall | grep -E "IKE|ESP"Derefter er de resterende spørgsmål dem, ingen etiket besvarer. Hvilke protokolversioner accepteres stadig, hvordan valideres gatewayens identitet, hvilket algoritmesæt er tilladt, hvem autoriserer en given bruger til en given ressource, og hvad tilbagekalder adgang, når en enhed mistes. Et topologidiagram og et mekanismenavn er begyndelsen på den liste, ikke en erstatning for den.
Behold altså de to betegnelser, men brug dem til det, de er: en kort måde at sige, hvilke endepunkter der sammenkobles, og hvordan tunnelen bygges. I det øjeblik den ene bruges til at udelukke den anden, er beskrivelsen holdt op med at beskrive noget.