Siirtyminen pois PPP-pohjaisesta VPN:stä kopioimatta sen oletuksia

VPN-migraatio on valmis, kun käyttäjät, kohteet, nimien ratkaiseminen ja vikatilanteen käyttäytyminen ovat edelleen oikein, ei silloin, kun uusi asiakasohjelma näyttää vihreää kuvaketta. Vanhat PPP-pohjaiset käyttöönotot kantavat oletuksia, joita ei koskaan kirjoitettu: jaettu salaisuus, joka oli myös ainoa identiteettitarkistus, kiinteä osoitepooli, jonka palomuuri on sallittujen listalla, DNS-liite, jonka palvelin työntää. Protokollan vaihtaminen ilman näiden oletusten inventointia tuottaa tunnelin, joka tekee kättelyn, ja rajan, jota ei ole. Alla oleva järjestys on se, jota minä käytän, ja viimeinen vaihe on se, jonka tiimit ohittavat.

Vaihe 1: inventoi, mitä vanha yhteys tarjoaa

Inventaario kirjoitetaan, ei muisteta. Kirjaa tuetut asiakasohjelmat, todennusroolit, osoitepoolit, suojatut verkot, DNS-vaatimukset ja palveluoikeudet, joita kukin käyttäjäryhmä tarvitsee.

Kohdassa L2TP/IPsec erota kaksi kerrosta nimenomaisesti. IPsec-vertaiskumppanin identiteetti todentaa koneet; PPP todentaa käyttäjän, yleensä CHAP- tai MSCHAPv2-menetelmällä.

Juuri tässä erottelussa vanhat käyttöönotot piilottavat oletuksensa. Jokaisen asiakasohjelman jakama ennalta jaettu avain todentaa ryhmän eikä laitetta, ja se on usein ainoa asia, jota on koskaan kierrätetty. Jos PPP-tili on todellinen käyttäjäkohtainen valvonta, sano se, koska korvaavan ratkaisun on toistettava tämä valvonta jollakin muulla kuin jaetulla merkkijonolla. Kirjaa myös kiinteät lähdeosoitteet ja paikallisverkon poikkeukset, sillä ne ovat riippuvuuksia, joita kukaan ei dokumentoi ennen kuin ne hajoavat.

Vaihe 2: suunnittele korvaava ratkaisu tarkoituksella

Korvaavan ratkaisun valinta on vaatimus vaatimukselta -kartoitus: protokolla ja ylläpidetty asiakasohjelma, jota organisaatio tukee, ja jokainen identiteetti- ja käyttöoikeusvaatimus päätyy todelliseen mekanismiin. Jaettu salaisuus ei ole automaattisesti sama asia kuin laitekohtainen avain tai varmenne, eikä käyttäjäkohtainen PPP-tili vastaa laitevarmenteita.

Sovita osoitealueet ennen muuta, koska kotiverkkoon tai toimistoverkkoon päällekkäinen korvaava pooli aiheuttaa vian, jolla ei ole mitään tekemistä salauksen vahvuuden kanssa. Tarkista pooli samaa listaa vasten, jonka laadit vanhalle palvelulle, sekä sitä, mitä uusi asiakasohjelma olettaa oletuksena. Vahvista suojattujen verkkojen paluureititys ja vahvista, että uusi asiakasohjelma pystyy työntämään tai dokumentoimaan sen DNS-liitteen, jonka vanha työnsi. Nämä kaksi kohtaa aiheuttavat enemmän migraatiotikettejä kuin itse protokollan vaihto.

Vaihe 3: ota käyttöön vaiheittain ja varmista sekä sallinta että esto

Ota käyttöön yhdellä edustavalla käyttäjällä ja yhdellä edustavalla sovelluksella. Sisällytä testiin yksityinen DNS-nimien ratkaisu, koska tunneli, joka saavuttaa osoitteen mutta ei pysty ratkaisemaan sisäistä nimeä, on vain puoliksi migroitu. Sisällytä myös odotettu poissaolotila: mitä pitäisi tapahtua, kun tunneli putoaa, ja pakottaako asiakasohjelma sen.

Testaa sitten kohde, jonka pitäisi pysyä estettynä. Laaja tilapäinen sallintasääntö voi saada uuden tunnelin näyttämään terveeltä, kun se samalla hiljaa poistaa sen valtuutusrajan, jonka vanha palvelu toteutti, eikä kukaan huomaa sitä ennen auditointia. Vertaa sallinta- ja estotuloksia rinnakkain, samasta asiakasohjelmasta, samassa istunnossa. Pidä vanha palvelu käynnissä, kunnes molemmat sarakkeet vastaavat suunnitelmaa.

Ennen kuin siirrät pääkäyttäjän käyttöoikeutta, vahvista, että sinulla on valtuutettu palautumispolku, joka ei riipu tunnelista, jota olet muuttamassa.

Vaihe 4: poista vanha identiteetti käytöstä

Vanhan identiteetin asianmukainen poisto käytöstä tarkoittaa vanhentuneiden käyttäjien ja laitetunnusten peruuttamista sen palvelun kautta, joka ne omistaa, ja sitten vanhojen profiilien ja kuuntelijoiden poistamista, kun riippuvuuksia ei enää ole. Paikallisen tiedoston poistaminen ei peruuta kopiota muualla, ja vanha kuuntelija, joka yhä hyväksyy vanhan jaetun salaisuuden, on valvomaton ovi.

Tässä kohdassa kannattaa hidastaa. Kannettavan tietokoneen poistettu asiakasprofiili ei ole peruutettu tunnus; tunnus elää palvelimella ja pysyy voimassa, kunnes palvelin lakkaa hyväksymästä sen. Etsi vanhan kokoonpanon muita kopioita — testilaitteet, unohdettu puhelin, jonkun tallessa pitämä asennusohjelma — ja pidä kuuntelijan sammuttamista hetkenä, jolloin vanha palvelu todella päättyy. Siihen asti migraatiolla on kaksi etuovea.

Hyväksyntätietue on vaiheen yksi inventaario, johon on lisätty sarake: mitä uusi suunnitelma tekee kullekin riville ja miten varmistit sen. Se muuttaa protokollapäivityksen palveluvaatimukseksi, jolla on todisteet.

Pidä lopputulos sidottuna siihen, mitä palvelu tarvitsee, ei protokollan nimeen, koska nykyaikainen protokolla, johon vanhat oletukset on kopioitu, on sama riski paremmalla kehyksellä. RFC 3193 kuvaa, miten L2TP kulkee IPsecin päällä, mikä on hyödyllinen muistutus siitä, että kaksi kerrosta olivat aina erillisiä päätöksiä. Jos inventaariossa on rivi, jota et osaa selittää, pysähdy ja selvitä, mikä siitä riippuu. Migraatio on valmis, kun lista on tylsä.