Dit is hoe ik deze protocollen begrijp, het is mogelijk niet 100% accuraat, en ik ben benieuwd wat /r/networking metamind hierover te zeggen heeft, en hopelijk wat meer inzicht te verkrijgen in het proces. Voel je vrij om te reageren/correcties aan te brengen waar je maar wilt.
IPsec opereert op laag 3 en lijkt daarmee een goede kandidaat voor LAN naar LAN connectiviteit (hoewel Client to LAN IPsec VPN ook redelijk gangbaar is). Het kan multicast- en broadcast-verkeer verwerken (al heb ik dat nooit gebruikt). Overlay op IP (of als ESP of UDP bij gebruik van NAT-traversal mode) biedt het een connectionless service, net als gewoon IP. Wanneer gebruikt in interface/VTI mode, biedt het veel flexibiliteit qua dynamische routing. Hoewel de manier waarop ik het zie, interface- of beleidmodus niet inherent aan IPSec zelf is, maar aan de specifieke implementatie. Uiteindelijk stelt IKE de tunnelparameters in en stroomt de versleutelde ESP (of UDP) pakketten tussen de eindpunten. Het andere eindpunt weet niet en geeft er ook niet om of de configuratie interface- of beleidsstijl was om te bepalen welke pakketten versleuteld en gestuurd worden. Aanvankelijk dacht ik dat SSLVPN niet zo flexibel kon zijn, maar nu ik erover nadenk, is OpenVPN in principe ook een SSLVPN en kan het LAN naar LAN doen (inclusief dynamische routing), hoewel ik nog nooit een commerciële SSLVPN heb gezien die dat kan.
IPsec biedt tunnel- en transportmodi. Mijn gebruik hiervan was meestal tunnelmodus (en afgezien van Cisco routers lijken de andere apparaten die ik heb gebruikt niet eens een transportmodus te hebben, tenzij je heel diep graaft in de nerdknoppen). Ik heb alleen transportmodus gezien op Cisco en Mikrotik. Het enige gebruiksgeval dat ik voor transportmodus zie, is wanneer je GRE over IPSEC gebruikt, dan bespaart het wat overhead, aangezien GRE de interne IP-header al heeft. Hoewel ik weet dat je GRE over IPsec met tunnelmodus IPsec kunt gebruiken en dat het gewoon werkt. Weet iemand nog andere gebruiksgevallen voor transportmodus? Ook, tenzij er GRE bovenop zit, is transportmodus vrijwel nutteloos (je zou het kunnen gebruiken om het apparaat zelf te beheren, maar SSH doet hetzelfde en dat is prima, waarom het wiel opnieuw uitvinden).
IPsec is iets standaardvoller dan SSLVPN doordat een firewall van vendor A meestal een tunnel kan opzetten naar een firewall van vendor B (of een Windows/Linux station), terwijl SSLVPN-implementaties vendor-specifiek zijn en je ofwel een applicatie van die vendor op de client nodig hebt (of soms een browserplug-in). Maar goed, er is ook OpenVPN.
SSLVPN gebruikt dezelfde TLS als HTTPS, dus werkt op laag 4 (of hoger als je TLS als een apart sessielaagje beschouwt). Ik zou zeggen dat dit het gemakkelijker maakt om te gebruiken achter een firewall die je niet beheert. Elke gastwifi van hotel of luchthaven zal TCP 443 waarschijnlijk toestaan, en hetzelfde kan niet gezegd worden voor IKE en ESP.
Ik heb dit nog nooit meegemaakt, maar ik las ergens dat het mogelijk is dat het flow control/retransmissiemechanisme van TCP de SSL-verbinding kan verstoren met de TCP-sessies in de tunnel. Ik denk dat er geen problemen zouden moeten zijn met UDP-verkeer andere dan het negatie van de lichte eigenschappen van UDP. Maar een scenario waarin twee flow control/retransmissiemechanismen onafhankelijk van elkaar werken, kan meer kwaad dan goed doen.
De SSLVPN-implementaties die ik heb gebruikt, waren uitsluitend voor client-server verkeer.
Alle SSLVPN-implementaties die ik heb gezien, draaien in principe in tunnelmodus.
Ik heb nog geen LAN naar LAN SSLVPN-implementatie gezien van grote vendors (wat niet betekent dat zo’n stuk niet bestaat). Wat ik wel herinner is een OpenVPN+BGP (met Quagga), maar dat begreep ik toen niet goed. Achteraf denk ik dat het dicht in de buurt kwam van DMVPN qua dynamische failover-mogelijkheden, hoewel het niet zo ver ging als dynamische spoke-to-spoke tunnels, maar een orchestratielaag erbovenop met Puppet maakte het heel dichtbij. En als ik het goed begrijp, is OpenVPN in wezen een open SSLVPN-implementatie.
Denkend, wat bieden propriëtaire SSLVPN-implementaties dat OpenVPN niet biedt? Ik vergis me waarschijnlijk, maar het enige dat ik zie dat een propriëtaire SSLVPN biedt, is het ontbreken van compatibiliteit met andere vendors.
SSH “VPN” daar gebruik ik maar zelden, lijkt erg op SSLVPN. Alle opmerkingen zijn welkom.
Tijdens het schrijven van deze post moest ik heroverwegen hoe het allemaal werkt. In het begin dacht ik dat IPsec voor LAN naar LAN was, en SSLVPN voor host naar LAN, maar halverwege besefte ik dat OpenVPN (wat SSLVPN is) LAN naar LAN en host naar LAN kan doen (en ik wist vanaf het begin dat client IPsec VPN mogelijk was). Functioneel gezien, bij vergelijking tussen OpenVPN en IKE/IPsec VPN, zie ik geen zinvolle verschillen (hoewel er mogelijk aanzienlijke verschillen zijn in de specifieke implementatie). Het kan zijn dat IKE/IPsec meer interoperabiliteit biedt (mogelijk omdat firewallvendors hier meer in investeren, hetzelfde had met SSLVPN gedaan kunnen worden), en dat SSLVPN makkelijker door firewalls heen komt, maar dat is het wel ongeveer.
Nu vraag ik me af waarom we met twee verschillende protocollen zitten die eigenlijk hetzelfde doen. Welke was er eerst, en waarom was er nog een ander uitgevonden toen er al een eerste was?