Varför SSL VPN och site-to-site-VPN inte är motsatser
SSL VPN och site-to-site beskriver olika axlar: vem som ansluter till nätverket och hur tunneln byggs. Att nämna båda samtidigt är ett kategorifel.
Be två administratörer beskriva samma VPN och den ena svarar kanske ”SSL VPN” medan den andra säger ”site-to-site”, som om de två var konkurrerande alternativ i en meny. De är svar på olika frågor, och att behandla dem som alternativ ger jämförelser som inte kan avgöras. Den ena etiketten säger vilka ändpunkter som kopplas samman; den andra säger vad som bär trafiken mellan dem. Håll axlarna åtskilda och det mesta av diskussionen försvinner.
Två etiketter, två separata frågor
Topologi svarar på vem som ansluter till vad. En fjärråtkomstdesign kopplar enskilda användare eller enheter till en gateway, vanligtvis med identitet per användare och en pool av adresser. En site-to-site-design kopplar samman två nätverk via gateways, så den intressanta identiteten är partnergatewayen och inte personen vid tangentbordet. Det är olika driftproblem, från adressplanering till vem som kan återkalla åtkomst klockan 2 på natten.
Mekanism svarar på hur tunneln byggs och autentiseras. IPsec med IKEv2, en TLS-baserad produkt som bär IP inuti sig, och en webbläsarinriktad applikationsportal är mekanismval, och var och en har sin egen förhandling, sina chifferpaket och sina felmoder. Ingen av dem innebär en topologi, och en topologi väljer inte en mekanism.
Sätt de två axlarna i en tabell och förvirringen blir synlig, eftersom varje cell i rutnätet kan fyllas. Vad rutnätet inte kan göra är att berätta vilken kombination din leverantör levererade, eftersom produktnamn smälter samman båda axlarna till en enda marknadsföringsfras.
Varifrån kategorifelet kommer
Leverantörer sålde ”SSL VPN” i åratal som motsatsen till ”IPsec VPN”, vilket fick en mekanismjämförelse att se ut som ett topologival. Uttrycket har också åldrats dåligt på sina egna villkor, eftersom dagens konstruktioner använder stödda TLS-versioner och namnet SSL lever vidare 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 |
Två besläktade myter följer av samma sammansmältning. Den första är att IPsec betyder site-to-site; IKEv2 konstruerades också för klient-till-gateway-relationer, så en enskild bärbar dator kan ansluta med IPsec. Den andra är att en TLS-baserad produkt bara betyder fjärråtkomst; OpenVPN används rutinmässigt för att bära trafik mellan två platser, och dess TLS-användning är koncentrerad till kontroll- och autentiseringsutbytet snarare än till en webbläsarsession.
Ett användbart test för varje beskrivning: om byte av ett ord ändrar både ändpunkterna och protokollet, blandar meningen axlarna. ”SSL VPN kontra site-to-site” klarar inte det testet, eftersom den första termen namnger en mekanismfamilj och den andra en topologi.
Beskriv en utrullning så att den kan jämföras
Skriv fyra fält och fyll i dem: ändpunkter, mekanism, autentisering och åtkomstyta. En filialförbindelse kan läsas som ett IKEv2-gatewaypar mellan två namngivna prefix med certifikatautentisering och utan portal på användarnivå. En fjärråtkomsttjänst kan läsas som en TLS-baserad klient som tilldelar adresser per användare, kräver en andra faktor vid inloggning och bara publicerar en intern DNS-zon.
De meningarna är jämförbara på ett sätt som produktnamn inte är. Två fjärråtkomstddesigner kan mätas mot samma användararbetsflöde och samma återkallningsväg, och två mellanplatsdesigner mot samma prefixlista, trafikpolicy och felkrav. Etiketterna organiserar jämförelsen; de ersätter den inte.
Terminologin har också ett publicerat ankare. IETF:s dokument om VPN-terminologi skiljer flera tjänstemodeller, inklusive fjärråtkomst och site-to-site, från de mekanismer de byggs med, och det är just den distinktion som ständigt går förlorad.
Läs det förhandlade protokollet, inte produktnamnet
Etiketten på lådan fastställer inte vad en pågående tunnel har kommit överens om. Fråga motparten direkt, på TLS-sidan, och läs protokollversionen och chiffret som handskakningen producerade i stället för versionen i broschyren.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefFör en IPsec-gateway kommer den motsvarande observationen från implementationens egen statusutskrift, som rapporterar de IKE- och ESP-förslag som används. Hur som helst är poängen densamma: mekanismaxeln måste läsas från den levande sessionen, eftersom en klient och en gateway kan förhandla ned till något äldre än vad någon av administratörerna förväntade sig.
ipsec statusall | grep -E "IKE|ESP"Därefter kvarstår frågorna som ingen etikett besvarar. Vilka protokollversioner som fortfarande accepteras, hur gatewayens identitet valideras, vilken algoritmuppsättning som är tillåten, vem som auktoriserar en given användare för en given resurs och vad som återkallar åtkomst när en enhet tappas bort. Ett topologidiagram och ett mekanismnamn är början på den listan, inte en ersättning för den.
Behåll alltså de två etiketterna, men använd dem för vad de är: ett kort sätt att säga vilka ändpunkter som kopplas samman och hur tunneln byggs. I samma stund som den ena används för att utesluta den andra har beskrivningen slutat beskriva något.