VPN TLS kundër IPsec: pesë fushat që ia vlen të rishikohen

Renditja e VPN-ve TLS kundër VPN-ve IPsec sipas familjes së protokollit i përgjigjet një pyetjeje që askush nuk e bëri, dhe zakonisht citon një ndërtim që të dyja familjet e braktisën vite më parë. Ajo që një recensent mund të vlerësojë vërtet është mbrojtja e negociuar, identiteti i partnerit, modeli i klientit dhe shërbimi i ekspozuar. Këto katër gjëra janë të dukshme në një vendosje, dhe asnjëra nuk rrjedh nga etiketa e produktit. Kërkoni pesë fusha dhe biseda bëhet konkrete.

Pesë fusha, dhe etiketa nuk është një prej tyre

Fusha e parë është versioni i mbështetur i softuerit, sepse një përshkrim protokolli pa version është broshurë. E dyta është versioni i negociuar i protokollit, i cili vendos se cilat ndërtime janë fare të disponueshme. E treta është grupi i mbrojtjes, e katërta është metoda e vërtetimit si për partnerin ashtu edhe për përdoruesin, dhe e pesta është shtrirja e aksesit që produkti jep pas pranimit.

Etiketa VPN SSL mbulon të paktën tre produkte të ndryshme: një klient të plotë rrjeti, një përfaqësues aplikacioni dhe një portal të vjetër të bazuar në shfletues. Ato ekspozojnë shërbime të ndryshme dhe dështojnë ndryshe, prandaj etiketa nuk mund të zëvendësojë fushën e shtrirjes.

Çfarë ndryshon vërtet kriptimi i vërtetuar

TLS 1.3 kërkon kriptim të vërtetuar, i cili e heq ndërtimin më të vjetër MAC-then-encrypt nga protokolli në vend që ta lërë opsional. IPsec ESP ka pasur grupe kriptimi të vërtetuar po aq gjatë, me AES-GCM të përcaktuar në RFC-në e vet. Në të dyja familjet garancia vjen nga grupi i negociuar dhe jo nga emri i familjes, prandaj lista e fushave fillon me një version. Një recensent që nuk mund të emërojë grupin nuk ka çfarë të vlerësojë.

Prandaj krahasimi historik është mashtrues. Një vendosje e fiksuar në një version të vjetër të TLS me një grup CBC dhe një tjetër që ekzekuton TLS 1.3 me një grup AEAD nuk kanë të njëjtin qëndrim sigurie, edhe pse të dyja janë VPN TLS. E njëjta ndarje ekziston në anën IPsec midis një grupi modern ESP dhe një kombinimi të vjetër.

Lexoni vlerat e negociuara në vend të konfigurimit që kishit ndërmend. Komandat më poshtë tregojnë se për çfarë u dakordësuan vërtet një pikë fundore aktive dhe një tunel aktiv.

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

Nëse pika fundore nuk pranon të negociojë TLS 1.3, ky është një gjetje dhe jo një preferencë. Nëse tuneli liston një grup që nuk e prisnit, konfigurimi që ka rëndësi është ai që zgjodhën partnerët, jo ai në shabllon.

Identiteti i partnerit është një pyetje më vete

Kriptimi pa një partner të verifikuar mbron trafikun nga vëzhguesit dhe ia dorëzon kujtdo që iu përgjigj lidhjes. Vërtetimi i partnerit pyet se cili identitet pritet, çfarë materiali besimi e vërteton atë dhe si sillet klienti kur përgjigja nuk përputhet. Një zinxhir certifikatash, një çelës i fiksuar dhe një sekret i para-ndarë janë tre përgjigje të ndryshme me tre kosto operative të ndryshme.

Pastaj bëni të njëjtat pyetje për përdoruesin ose pajisjen. Një portë që vërteton makinën dhe pranon çdo përdorues, ose e kundërta, ka një qëndrim të caktuar që duhet shkruar, jo supozuar. Lejet e burimeve të zbatuara pas pranimit janë pjesë e së njëjtës fushë, sepse vërtetimi nuk është autorizim.

Ruajtja e kontrolleve të emrit të hostit dhe certifikatës ka më shumë rëndësi sesa njohja e dritares së hyrjes. Një klient i konfiguruar të anashkalojë verifikimin ka hequr hapin e vetëm që e dallon portën tuaj nga një imitim bindës.

Kufiri që ekspozon produkti

Një portal pa klient përfaqëson operacione të zgjedhura aplikacioni përmes portës, kështu që përdoruesi arrin një ndërfaqe dhe jo një rrjet. Një klient me tunel të plotë mbart atë që zgjedhin rrugët dhe politika e tij e filtrimit, që është një sipërfaqe shumë më e madhe. Krahasimi i të dyve sipas forcës së protokollit humb diferencën në atë që një sulmues mund të arrijë përmes tyre. Njëri ekspozon një ndërfaqe aplikacioni, tjetri një rrjet të rrugëzuar, dhe të dy kërkojnë rishikime të ndryshme.

Pyetni cili shërbim është i ekspozuar, cilat operacione janë të autorizuara dhe çfarë dëgjon vetë porta. Një ndërfaqe administrimi e arritshme nga e njëjta adresë si portali i përdoruesit është një gjetje e vendosjes, dhe asnjë zgjedhje protokolli nuk e kompenson atë.

Shtrirja për aplikacion e ngushton sipërfaqen më tej, dhe ndryshon edhe sjelljen në dështim kur tuneli bie. Një dizajn që supozon shtrirje të tunelit të plotë thyhet në mënyra që një dizajn për aplikacion nuk i njeh, dhe ngarkesa e mbështetjes vijon.

Vendosni rezultatin e dështimit dhe ciklin e jetës

Çfarë ndodh kur vërtetimi ose mbrojtja nuk është e disponueshme është një vendim politike që i përket rishikimit. Një rezultat i bllokuar dhe një kthim i drejtpërdrejtë i pashpallur kanë pasoja të ndryshme, dhe ndryshimi është i padukshëm në një listë veçorish. Deklaroni sjelljen e synuar pranë burimit që mbron.

Përfshini ciklin e jetës së patch-ave dhe mbështetjes së portës, veçoritë e saj të jashtme të aktivizuara dhe rrugën e përditësimit për klientët. Një zgjedhje e saktë protokolli nuk e bën të sigurt një shërbim të vendosur keq, dhe shumica e incidenteve jetojnë në atë boshllëk, jo në grup.

Shkruani pesë fushat, politikën e dështimit dhe pronarin e ciklit të jetës në një faqe. Ajo faqe është një rishikim; një krahasim i familjeve të protokollit është një mendim.