Waarom SSL VPN en site-to-site VPN geen tegenpolen zijn

Vraag twee beheerders dezelfde VPN te beschrijven en de een antwoordt misschien „SSL VPN“ terwijl de ander „site-to-site“ zegt, alsof het twee concurrerende opties in een menu zijn. Het zijn antwoorden op verschillende vragen, en ze als alternatieven behandelen levert vergelijkingen op die niet kunnen worden beslecht. Het ene label zegt welke eindpunten worden verbonden; het andere zegt wat het verkeer ertussen draagt. Houd de assen gescheiden en het grootste deel van de discussie verdwijnt.

Twee labels, twee afzonderlijke vragen

Topologie beantwoordt wie met wat verbindt. Een ontwerp voor externe toegang koppelt individuele gebruikers of apparaten aan een gateway, meestal met identiteit per gebruiker en een pool adressen. Een site-to-site-ontwerp verbindt twee netwerken via gateways, dus de interessante identiteit is de peergateway en niet de persoon achter het toetsenbord. Dat zijn verschillende operationele problemen, van adresplanning tot wie om 2 uur 's nachts de toegang kan intrekken.

Mechanisme beantwoordt hoe de tunnel wordt gebouwd en geauthenticeerd. IPsec met IKEv2, een TLS-gebaseerd product dat IP in zich draagt, en een op de browser gericht applicatieportaal zijn mechanismekeuzes, en elk heeft zijn eigen onderhandeling, cijfersuites en faalmodi. Geen ervan impliceert een topologie, en een topologie kiest geen mechanisme.

Zet de twee assen in één tabel en de verwarring wordt zichtbaar, omdat elke cel van het raster kan worden ingevuld. Wat het raster niet kan, is je vertellen welke combinatie je leverancier heeft geleverd, omdat productnamen beide assen samenpersen tot één marketingfrase.

Waar de categoriefout vandaan komt

Leveranciers verkochten jarenlang „SSL VPN“ als het tegenovergestelde van „IPsec VPN“, waardoor een mechanismevergelijking op een topologiekeuze leek. De uitdrukking is ook op eigen voorwaarden slecht verouderd, omdat huidige ontwerpen ondersteunde TLS-versies gebruiken en de naam SSL vooral als productcategorie voortleeft.

Twee verwante mythen volgen uit dezelfde samendrukking. De eerste is dat IPsec site-to-site betekent; IKEv2 is ook ontworpen voor client-naar-gatewayrelaties, dus een individuele laptop kan met IPsec deelnemen. De tweede is dat een TLS-gebaseerd product alleen externe toegang betekent; OpenVPN wordt regelmatig gebruikt om verkeer tussen twee sites te dragen, en het TLS-gebruik is geconcentreerd in de uitwisseling van besturing en authenticatie in plaats van in een browsersessie.

Een nuttige test voor elke beschrijving: als het vervangen van één woord zowel de eindpunten als het protocol verandert, mengt de zin de assen. „SSL VPN versus site-to-site“ slaagt niet voor die test, omdat de eerste term een mechanismefamilie noemt en de tweede een topologie.

Beschrijf een uitrol zodat die vergelijkbaar is

Schrijf vier velden en vul ze in: eindpunten, mechanisme, authenticatie en toegangsoppervlak. Een filiaalverbinding kan worden gelezen als een IKEv2-gatewaypaar tussen twee genoemde prefixen met certificaatauthenticatie en zonder portaal op gebruikersniveau. Een dienst voor externe toegang kan worden gelezen als een TLS-gebaseerde client die adressen per gebruiker toewijst, bij aanmelding een tweede factor eist en alleen een interne DNS-zone publiceert.

Die zinnen zijn vergelijkbaar op een manier waarop productnamen dat niet zijn. Twee ontwerpen voor externe toegang kunnen worden gemeten tegen dezelfde gebruikersworkflow en hetzelfde intrekkingspad, en twee ontwerpen tussen sites tegen dezelfde prefixlijst, verkeersbeleid en faaleisen. De labels organiseren de vergelijking; ze vervangen die niet.

De terminologie heeft ook een gepubliceerd anker. Het IETF-document over VPN-terminologie scheidt verschillende dienstmodellen, waaronder externe toegang en site-to-site, van de mechanismen waarmee ze worden gebouwd, en dat is precies het onderscheid dat steeds verloren gaat.

Lees het onderhandelde protocol, niet de productnaam

Het etiket op de doos stelt niet vast waar een draaiende tunnel het over eens is geworden. Vraag de peer rechtstreeks, aan de TLS-kant, en lees de protocolversie en het cijfer dat de handshake heeft opgeleverd in plaats van de versie in de brochure.

openssl s_client -connect vpn.example.net:443 -tls1_3 -brief

Voor een IPsec-gateway komt de gelijkwaardige observatie uit de eigen statusuitvoer van de implementatie, die de gebruikte IKE- en ESP-voorstellen meldt. Hoe dan ook, het punt is hetzelfde: de mechanismeas moet uit de levende sessie worden gelezen, omdat een client en een gateway naar iets oudere kunnen onderhandelen dan een van beide beheerders verwachtte.

ipsec statusall | grep -E "IKE|ESP"

Daarna blijven de vragen over die geen enkel label beantwoordt. Welke protocolversies nog worden geaccepteerd, hoe de identiteit van de gateway wordt gevalideerd, welke algoritmeset is toegestaan, wie een bepaalde gebruiker voor een bepaalde bron autoriseert en wat de toegang intrekt wanneer een apparaat verloren gaat. Een topologiediagram en een mechanismenaam zijn het begin van die lijst, geen vervanging ervoor.

Houd dus de twee labels, maar gebruik ze voor wat ze zijn: een korte manier om te zeggen welke eindpunten worden verbonden en hoe de tunnel wordt gebouwd. Op het moment dat een van beide wordt gebruikt om de andere uit te sluiten, is de beschrijving opgehouden iets te beschrijven.