Migrimi nga një VPN i bazuar në PPP pa kopjuar supozimet e tij

Një migrim VPN përfundon kur përdoruesit, destinacionet, zgjidhja e emrave dhe sjellja në rast dështimi janë ende të sakta, jo kur klienti i ri shfaq një ikonë të gjelbër. Vendosjet e vjetra të bazuara në PPP mbajnë supozime që nuk u shkruan kurrë: një sekret i përbashkët që ishte edhe kontrolli i vetëm i identitetit, një grup fiks adresash që firewall-i e mban në listën e lejuar, dhe një prapashtesë DNS që dërgon serveri. Zëvendësimi i protokollit pa inventarizuar ato supozime prodhon një tunel që përfundon handshake-un dhe një kufi që nuk ekziston. Rendi më poshtë është ai që përdor unë, dhe hapi i fundit është ai që ekipet e anashkalojnë.

Hapi 1: inventarizoni çfarë ofron lidhja e vjetër

Inventari shkruhet, nuk mbahet mend. Regjistroni klientët e mbështetur, rolet e vërtetimit, grupet e adresave, rrjetet e mbrojtura, kërkesat për DNS dhe lejet e shërbimit që i nevojiten çdo grupi përdoruesish.

Për L2TP/IPsec, ndani qartë dy shtresat. Identiteti i partnerit IPsec vërteton makinat; PPP vërteton përdoruesin, zakonisht me CHAP ose MSCHAPv2.

Pikërisht në këtë ndarje vendosjet e vjetra fshehin supozimet e tyre. Një çelës i para-ndarë që ndahet nga çdo klient vërteton një grup dhe jo një pajisje, dhe shpesh është e vetmja gjë që është rrotulluar ndonjëherë. Nëse llogaria PPP është kontrolli i vërtetë për përdorues, thuajeni, sepse zëvendësimi duhet ta riprodhojë atë kontroll me diçka që nuk është varg i përbashkët. Shënoni edhe adresat fikse të burimit dhe përjashtimet e rrjetit lokal, sepse ato janë varësitë që askush nuk i dokumenton derisa të thyhen.

Hapi 2: projektojeni zëvendësimin me qëllim

Zgjedhja e zëvendësimit është një hartëzim kërkesë-për-kërkesë: një protokoll dhe një klient i mirëmbajtur që organizata mbështet, me çdo kërkesë identiteti dhe aksesi që zbarkon në një mekanizëm real. Një sekret i përbashkët nuk është automatikisht i barabartë me një çelës ose certifikatë për pajisje, dhe një llogari PPP për përdorues nuk është e barabartë me një certifikatë pajisjeje.

Koordinoni diapazonet e adresave para çdo gjëje tjetër, sepse një grup zëvendësues që mbivendoset me një LAN shtëpiak ose zyre krijon një dështim që nuk ka asnjë lidhje me forcën e shifrimit. Kontrolloni grupin kundrejt të njëjtës listë që ndërtuat për shërbimin e vjetër, plus atë që klienti i ri supozon si parazgjedhje. Konfirmoni rrugëtimin e kthimit për rrjetet e mbrojtura dhe konfirmoni që klienti i ri mund të shtyjë ose të dokumentojë prapashtesën DNS që shtynte ai i vjetri. Këto dy pika shkaktojnë më shumë tiketa migrimi sesa vetë ndryshimi i protokollit.

Hapi 3: vendoseni në faza dhe verifikoni si lejimin ashtu edhe refuzimin

Vendoseni me një përdorues përfaqësues dhe një aplikacion përfaqësues. Përfshini në test zgjidhjen private të DNS-së, sepse një tunel që arrin një adresë por nuk mund të zgjidhë një emër të brendshëm është migruar vetëm gjysmë. Përfshini edhe gjendjen e pritur të padisponueshmërisë: çfarë duhet të ndodhë kur tuneli bie dhe nëse klienti e zbaton atë.

Më pas testoni një destinacion që duhet të mbetet i refuzuar. Një rregull i gjerë lejimi i përkohshëm mund ta bëjë tunelin e ri të duket i shëndetshëm ndërsa heq në heshtje kufirin e autorizimit që zbatonte shërbimi i vjetër, dhe askush nuk e vë re deri në një auditim. Krahasoni rezultatet e lejimit dhe refuzimit krah për krah, nga i njëjti klient, në të njëjtën sesion. Mbani shërbimin e vjetër në punë derisa të dy kolonat të përputhen me projektin.

Para se të zhvendosni aksesin e administratorit, konfirmoni që keni një rrugë rikuperimi të autorizuar që nuk varet nga tuneli që po ndryshoni.

Hapi 4: tërhiqni identitetin e vjetër

Tërheqja e saktë e identitetit të vjetër do të thotë të revokoni përdoruesit dhe kredencialet e pajisjeve të vjetruara përmes shërbimit që i zotëron ato, pastaj të hiqni profilet dhe dëgjuesit e vjetër kur nuk mbetet asnjë varësi. Fshirja e një skedari lokal nuk revokon një kopje diku tjetër, dhe një dëgjues i vjetër që ende pranon sekretin e vjetër të përbashkët është një derë pa mbikëqyrje.

Kjo pikë meriton ngadalësim. Një profil klienti i çaktivizuar në një laptop nuk është kredencial i revokuar; kredenciali jeton në server dhe mbetet i vlefshëm derisa serveri të ndalojë pranimin e tij. Kërkoni kopje të tjera të konfigurimit të vjetër — pajisje testimi, një telefon i harruar, një instalues që dikush e ka mbajtur — dhe trajtojeni fikjen e dëgjuesit si momentin kur shërbimi i vjetër përfundon vërtet. Deri atëherë, migrimi ka dy dyer të përparme.

Regjistri i pranimit është inventari nga hapi i parë me një kolonë të shtuar: çfarë bën projektimi i ri për çdo rresht dhe si e verifikuat. Kjo e kthen një përmirësim protokolli në një kërkesë shërbimi me prova.

Mbajeni rezultatin të lidhur me atë që i nevojitet shërbimit dhe jo me emrin e protokollit, sepse një protokoll modern me supozimet e vjetra të kopjuara brenda është i njëjti rrezik me një kornizë më të mirë. RFC 3193 përshkruan si transportohet L2TP mbi IPsec, që është një kujtesë e dobishme se dy shtresat ishin gjithmonë vendime të ndara. Nëse inventari ka një rresht që nuk mund ta shpjegoni, ndaloni dhe zbuloni se çfarë varet prej tij. Migrimi përfundon kur lista është e mërzitshme.