Ordigi TLS VPN-ojn kontraŭ IPsec VPN-oj laŭ protokola familio respondas demandon, kiun neniu demandis, kaj kutime citas konstruaĵon, kiun ambaŭ familioj forlasis antaŭ jaroj. Kion revizianto vere povas taksi, estas la intertraktita protekto, la identeco de la partnero, la klienta modelo kaj la elmontrita servo. Tiuj kvar aferoj videblas en efektivigo, kaj neniu el ili sekvas el la produkta etikedo. Petu kvin kampojn kaj la konversacio fariĝas konkreta.

Kvin kampoj, kaj la etikedo ne estas unu el ili

La unua kampo estas la subtenata programara eldono, ĉar protokola priskribo sen versio estas broŝuro. La dua estas la intertraktita protokola versio, kiu decidas, kiuj konstruaĵoj eĉ disponeblas. La tria estas la protekta suito, la kvara la aŭtentiga metodo por kaj partnero kaj uzanto, kaj la kvina la alira amplekso, kiun la produkto donas post akcepto.

Etikedo SSL VPN kovras almenaŭ tri malsamajn produktojn: plenan retan klienton, aplikaĵan prokurilon kaj malnovan retumilan portalon. Ili elmontras malsamajn servojn kaj malsukcesas malsame, do la etikedo ne povas anstataŭigi la ampleksan kampon.

FieldWhat a usable answer looks like
ReleaseA version with a support window, not a family name
Protocol versionTLS 1.3 or IKEv2 with the ESP suite named
Protection suiteAn authenticated-encryption algorithm, not a cipher list
AuthenticationPeer identity plus user or device identity, separately
Access scopeThe services reachable after admission

Kion aŭtentigita ĉifrado vere ŝanĝas

TLS 1.3 postulas aŭtentigitan ĉifradon, kio forigas la pli malnovan MAC-then-encrypt-konstruaĵon el la protokolo anstataŭ lasi ĝin laŭvola. IPsec ESP havas suitojn de aŭtentigita ĉifrado same longe, kun AES-GCM difinita en propra RFC. En ambaŭ familioj la garantio venas de la intertraktita suito kaj ne de la familia nomo, tial la kampolisto komenciĝas per versio. Revizianto, kiu ne povas nomi la suiton, havas nenion takseblan.

Tial la historia komparo estas misgvida. Efektivigo fiksita al malnova TLS-versio kun CBC-suito kaj alia funkcianta kun TLS 1.3 kaj AEAD-suito ne estas la sama sekureca sinteno, kvankam ambaŭ estas TLS VPN-oj. La sama divido ekzistas ĉe la IPsec-flanko inter moderna ESP-suito kaj malnova kombinaĵo.

Legu la intertraktitajn valorojn anstataŭ la agordon, kiun vi intencis. La subaj komandoj montras, pri kio funkcianta finpunkto kaj funkcianta tunelo vere interkonsentis.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Se la finpunkto ne volas intertrakti TLS 1.3, tio estas trovo, ne prefero. Se la tunelo listigas suiton, kiun vi ne atendis, la decida agordo estas tiu, kiun la partneroj elektis, ne tiu en la ŝablono.

Identeco de la partnero estas aparta demando

Ĉifrado sen kontrolita partnero protektas la trafikon kontraŭ observantoj kaj transdonas ĝin al kiu ajn respondis la konekton. Aŭtentigo de la partnero demandas, kiu identeco estas atendata, kiu fida materialo kontrolas ĝin, kaj kiel la kliento kondutas, kiam la respondo ne kongruas. Atestila ĉeno, fiksita ŝlosilo kaj antaŭdividita sekreto estas tri malsamaj respondoj kun tri malsamaj funkciaj kostoj.

Poste demandu la samajn demandojn pri la uzanto aŭ aparato. Pordego, kiu aŭtentigas la maŝinon kaj akceptas ajnan uzanton, aŭ inverse, havas specifan sintenon, kiun oni skribu anstataŭ supozi. Rimedpermesoj aplikataj post akcepto apartenas al la sama kampo, ĉar aŭtentigo ne estas rajtigo.

Konservi la kontrolojn de gastignomo kaj atestilo pli gravas ol la konateco de la ensaluta fenestro. Kliento agordita ignori kontrolon forigis la solan paŝon, kiu distingas vian pordegon de konvinka imitaĵo.

La limo, kiun la produkto elmontras

Senklienta portalo prokurigas elektitajn aplikaĵajn operaciojn tra la pordego, do la uzanto atingas interfacon anstataŭ reton. Plentunela kliento portas tion, kion elektas ĝiaj itineroj kaj filtra politiko, kio estas multe pli granda surfaco. Kompari la du laŭ protokola forto maltrafas la diferencon en tio, kion atakanto povas atingi tra ili. Unu elmontras aplikaĵan interfacon, la alia itinerigitan reton, kaj ambaŭ postulas malsamajn reviziojn.

Demandu, kiu servo estas elmontrita, kiuj operacioj estas rajtigitaj kaj kion la pordego mem aŭskultas. Administra interfaco atingebla de la sama adreso kiel la uzanta portalo estas efektiviga trovo, kaj neniu protokola elekto kompensas ĝin.

Amplekso por aplikaĵo plu mallarĝigas la surfacon, kaj ĝi ankaŭ ŝanĝas la malsukcesan konduton, kiam la tunelo falas. Dezajno, kiu supozas plentunelan atingon, rompiĝas laŭ manieroj, kiujn por-aplikaĵa dezajno ne konas, kaj la subtena ŝarĝo sekvas.

Decidu la malsukcesan rezulton kaj la vivociklon

Kio okazas, kiam aŭtentigo aŭ protekto ne disponeblas, estas politika decido, kiu apartenas al la revizio. Blokita rezulto kaj neanoncita rekta refalo havas malsamajn sekvojn, kaj la diferenco estas nevidebla en trajto-listo. Deklaru la intencitan konduton apud la rimedo, kiun ĝi protektas.

Inkluzivu la flik- kaj subten-vivociklon de la pordego, ĝiajn ebligitajn eksterajn trajtojn kaj la ĝisdatigan vojon por klientoj. Ĝusta protokola elekto ne faras sekura servon malbone efektivigitan, kaj plej multaj incidentoj vivas en tiu breĉo, ne en la suito.

Skribu la kvin kampojn, la malsukcesan politikon kaj la posedanton de la vivociklo sur unu paĝon. Tiu paĝo estas revizio; komparo de protokolaj familioj estas opinio.

Rilataj artikoloj