Wêrom SSL VPN en side-nei-side VPN gjin tsjinstellingen binne
SSL VPN en side-nei-side beskriuwe ferskillende assen: wa't him by it netwurk jout en hoe't de tunnel boud wurdt. Beide tagelyk neame is in kategoryflater.
Freegje twa behearders deselde VPN te beskriuwen en de iene antwurdet miskien „SSL VPN“, wylst de oare „side-nei-side“ seit, as wiene de twa konkurrearjende opsjes yn in menu. It binne antwurden op ferskillende fragen, en se as alternativen behannelje liedt ta fergelikingen dy't net oplost wurde kinne. It iene label seit hokker einpunten ferbûn wurde; it oare seit wat it ferkear tusken har draacht. Hâld de assen skieden en it grutste part fan 'e diskusje ferdwynt.
Twa labels, twa aparte fragen
Topology beantwurdet wa't him wêr by jout. In ûntwerp foar op ôfstân tagong ferbynt yndividuele brûkers of apparaten oan in gateway, meastentiids mei identiteit per brûker en in pool fan adressen. In ûntwerp foar side-nei-side ferbynt twa netwurken fia gateways, dus de nijsgjirrige identiteit is de peer-gateway, net de persoan efter it toetseboerd. Dat binne ferskillende operasjonele problemen, fan adresplanning oant wa't tagong weromlûke kin om 2 oere nachts.
Meganisme beantwurdet hoe't de tunnel boud en autentisearre wurdt. IPsec mei IKEv2, in TLS-basearre produkt dat IP yn him draacht, en in op 'e browser rjochte applikaasjeportaal binne meganismekeuzes, en elk hat syn eigen ûnderhanneling, syfersuites en flatermodi. Gjin fan allen ymplisearret in topology, en in topology kiest gjin meganisme.
Set de twa assen yn ien tabel en de betizing wurdt sichtber, want elke sel fan it roaster kin fol wurde. Wat it roaster net kin, is dy fertelle hokker kombinaasje dyn leveransier levere hat, om't produktnammen beide assen yn ien marketingfrase gearfetsje.
Wêr't de kategoryflater wei komt
Leveransiers ferkochten jierrenlang „SSL VPN“ as it tsjinoerstelde fan „IPsec VPN“, wat in meganismefergeliking as in topologyske kar lykje liet. De útdrukking is ek op syn eigen betingsten min ferâldere, om't hjoeddeiske ûntwerpen stipe TLS-ferzjes brûke en de namme SSL benammen as produktkategory oerlibbet.
| 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 |
Twa besibbe myten folgje út deselde gearfetting. De earste is dat IPsec side-nei-side betsjut; IKEv2 waard ek ûntwurpen foar relaasjes tusken klant en gateway, dus in yndividuele laptop kin him mei IPsec ferbine. De twadde is dat in TLS-basearre produkt allinnich tagong op ôfstân betsjut; OpenVPN wurdt geregeld brûkt om ferkear tusken twa siden te dragen, en syn TLS-brûk is konsintrearre yn 'e útwikseling fan kontrôle en autentikaasje yn stee fan in browsersesje.
In nuttige test foar elke beskriuwing: as it ferfangen fan ien wurd sawol de einpunten as it protokol feroaret, mingt de sin de assen. „SSL VPN tsjin side-nei-side“ slagget net foar dy test, om't de earste term in meganismefamylje neamt en de twadde in topology.
Beskriuw in ynset sadat it fergelike wurde kin
Skriuw fjouwer fakken en folje se yn: einpunten, meganisme, autentikaasje en tagongsoerflak. In filiaalferbining kin lêze as in IKEv2-gatewaypear tusken twa neamde prefiksen mei sertifikaatautentikaasje en sûnder portaal op brûkersnivo. In tsjinst foar tagong op ôfstân kin lêze as in TLS-basearre klant dy't adressen per brûker tawiist, by oanmelden in twadde faktor freget en allinnich in ynterne DNS-sône publisearret.
Dy sinnen binne fergelykber op in manier dy't produktnammen net binne. Twa ûntwerpen foar tagong op ôfstân kinne mei wurde tsjin itselde brûkerswurkproses en deselde weromlûkingsrûte, en twa ûntwerpen tusken siden tsjin deselde prefikslist, ferkearsbelied en flaterfoarskriften. De labels organisearje de fergeliking; se ferfange dy net.
De terminology hat ek in publisearre anker. It IETF-dokumint oer VPN-terminology skiedt ferskate tsjinstmodellen, wêrûnder tagong op ôfstân en side-nei-side, fan 'e meganismen wêrmei't se boud wurde, en dat is krekt it ûnderskie dat hieltiten ferlern giet.
Lês it ûnderhannele protokol, net de produktnamme
It label op 'e doaze fêstiget net wêr't in rinnende tunnel it oer iens wurden is. Freegje de peer direkt, oan 'e TLS-kant, en lês de protokolferzje en it syfer dat de hântsjoening makke hat yn stee fan de ferzje yn 'e brosjuere.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefFoar in IPsec-gateway komt de lykweardige observaasje út 'e eigen statusútfier fan 'e ymplemintaasje, dy't de brûkte IKE- en ESP-foarstellen rapportearret. Hoe dan ek, it punt is itselde: de meganisme-as moat út 'e libbene sesje lêzen wurde, om't in klant en in gateway ôfprate kinne nei eat âlders as wat ien fan beide behearders ferwachte.
ipsec statusall | grep -E "IKE|ESP"Dêrnei binne de oerbleaune fragen dy't gjin label beantwurdet. Hokker protokolferzjes wurde noch akseptearre, hoe't de identiteit fan 'e gateway falidearre wurdt, hokker algoritmeset tastien is, wa't in beskaat brûker foar in beskaat helpmiddel autorisearret en wat tagong weromlûkt as in apparaat ferlern giet. In topologyske diagram en in meganismenamme binne it begjin fan dy list, net in ferfanger.
Hâld dus de twa labels, mar brûk se foar wat se binne: in koarte manier om te sizzen hokker einpunten ferbûn wurde en hoe't de tunnel boud wurdt. It momint dat ien brûkt wurdt om de oare út te sluten, hat de beskriuwing ophâlden eat te beskriuwen.