TLS VPN tsjin IPsec: de fiif fjilden dy't it neisjen wurdich binne
Fergelykje in TLS VPN en in IPsec VPN op útjefte, protokolferzje, suite, peer-identiteit en bleatsteld omfang, plus de flaterútkomst dy't jo eins konfigurearre hawwe.
TLS VPN's tsjin IPsec VPN's op protokolfamylje sette beantwurdet in fraach dy't nimmen stelde, en it ferwiist meastentiids nei in konstruksje dy't beide famyljes jierren lyn al farre litten hawwe. Wat in beoardieler echt fêststelle kin, is de ûnderhannele beskerming, de peer-identiteit, it klintmodel en de bleatstelde tsjinst. Dy fjouwer dingen binne sichtber yn in útrôl, en gjin fan allegear folget út it produktlabel. Freegje om fiif fjilden en it petear wurdt konkreet.
Fiif fjilden, en it label is der gjin ien fan
It earste fjild is de stipe software-útjefte, want in protokolbeskriuwing sûnder ferzje is in brosjure. It twadde is de ûnderhannele protokolferzje, dy't beslút hokker konstruksjes uberhaupt beskikber binne. It tredde is de beskermingssuite, it fjirde de autentikaasjemetoade foar sawol peer as brûker, en it fyfde it tagongsomfang dat it produkt nei talitting jout.
In SSL VPN-label beslacht teminsten trije ferskillende produkten: in folsleine netwurkklint, in applikaasje-proxy en in âlderwetsk browserbasearre portaal. Se bleatstelle ferskillende tsjinsten en falle oars, dus it label kin it omfangsfjild net ferfange.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
Wat autentisearre fersifering echt feroaret
TLS 1.3 easket autentisearre fersifering, wat de âldere MAC-then-encrypt-konstruksje út it protokol hellet ynstee fan dy opsjoneel te litten. IPsec ESP hat like lang autentisearre-fersiferingssuites hân, mei AES-GCM definiearre yn in eigen RFC. Yn beide famyljes komt de garânsje út 'e ûnderhannele suite en net út 'e famyljenamme, en dêrom begjint de fjildlist mei in ferzje. In beoardieler dy't de suite net neame kin, hat neat te beoardieljen.
Dêrom is de histoaryske fergeliking misliedend. In útrôl fêstset op in âlde TLS-ferzje mei in CBC-suite en ien dy't TLS 1.3 mei in AEAD-suite draait, binne net deselde befeiligingshâlding, ek al binne it beide TLS VPN's. Deselde splitsing bestiet oan 'e IPsec-kant tusken in moderne ESP-suite en in âldere kombinaasje.
Lês de ûnderhannele wearden ynstee fan 'e konfiguraasje dy't jo bedoelden. De opdrachten hjirûnder litte sjen wat in libbend einpunt en in libbende tunnel echt ôfpraat hawwe.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasAs it einpunt gjin TLS 1.3 ûnderhannelje wol, is dat in befiningspunt en net in foarkar. As de tunnel in suite listet dy't jo net ferwachte, is de konfiguraasje dy't telt dyjinge dy't de peers keazen, net dy yn it sjabloan.
Peer-identiteit is in aparte fraach
Fersifering sûnder ferifiearre peer beskermet it ferkear tsjin waarnimmers en jout it oan wa't de ferbining ek beantwurde. Peer-autentikaasje freget hokker identiteit ferwachte wurdt, hokker fertrouwensmateriaal dy falidearret, en hoe't de klint him hâldt as it antwurd net past. In sertifikaatkeatling, in fêstsette kaai en in foarôf dield geheim binne trije ferskillende antwurden mei trije ferskillende operasjonele kosten.
Stel dan deselde fragen oer de brûker of it apparaat. In gateway dy't de masine autentisearret en elke brûker talit, of oarsom, hat in spesifike hâlding dy't opskreaun wurde moat ynstee fan oannommen. Boarnemachtigingen dy't nei talitting tapast wurde, hearre by itselde fjild, want autentikaasje is gjin autorisaasje.
It behâlden fan hostnamme- en sertifikaatkontrôles is wichtiger as de fertroudheid fan it oanmeldskerm. In klint dy't konfigurearre is om ferifikaasje te negearjen, hat de iennige stap fuorthelle dy't jo gateway ûnderskiedt fan in oertsjûgjende neibeard.
De grins dy't it produkt bleatstelt
In klintleas portaal proxy't selektearre applikaasjeoperaasjes troch de gateway, sadat de brûker in ynterface berikt ynstee fan in netwurk. In folsleine-tunnelsklint draacht wat syn rûtes en filterbelied selektearje, wat in folle grutter oerflak is. De beide fergelykje op protokolsterkte mist it ferskil yn wat in oanfaller der troch berikke kin. De iene bleatstelt in applikaasje-ynterface, de oare in rûte netwurk, en de beide easkje ferskillende beoardielingen.
Freegje hokker tsjinst bleatsteld is, hokker operaasjes autorisearre binne en wêr't de gateway sels nei harket. In behearynterface dat berikber is fan itselde adres as it brûkersportaal is in útrôlfynst, en gjin protokolkar kompensearret dat.
Omfang per applikaasje ferneaut it oerflak fierder, en it feroaret ek it flatergedrach as de tunnel falt. In ûntwerp dat folsleine tunnelberik oannimt, sil brekke op manieren dy't in per-app-ûntwerp dat net docht, en de stipebelesting folget.
Bepaal de flaterútkomst en de libbenssyklus
Wat der bart as autentikaasje of beskerming net beskikber is, is in beliedsbeslissing dy't yn 'e beoardieling heart. In blokkearre útkomst en in oankundige direkte weromfal hawwe ferskillende gefolgen, en it ferskil is ûnsichtber yn in funksjelist. Fermeld it bedoelde gedrach njonken de boarne dy't it beskermet.
Nim de patch- en stipe-libbenssyklus fan 'e gateway op, syn ynskeakele eksterne funksjes en it fernijingspaad foar klinten. In krekte protokolkar makket in min útrôle tsjinst net feilich, en de measte foarfallen libje yn dat gat en net yn 'e suite.
Skriuw de fiif fjilden, it flaterbelied en de eigner fan 'e libbenssyklus op ien side. Dy side is in beoardieling; in fergeliking fan protokolfamyljes is in miening.