Migrarea de pe un VPN bazat pe PPP fără a copia ipotezele acestuia

O migrare VPN se termină când utilizatorii, destinațiile, rezolvarea numelor și comportamentul la eșec sunt încă toate corecte, nu când noul client afișează o pictogramă verde. Implementările vechi bazate pe PPP poartă ipoteze care nu au fost niciodată scrise: un secret partajat care era și singura verificare de identitate, un pool fix de adrese pe care firewall-ul îl ține pe lista de permise, un sufix DNS trimis de server. Înlocuirea protocolului fără inventarierea acestor ipoteze produce un tunel care finalizează handshake-ul și o graniță care nu există. Ordinea de mai jos este cea pe care o folosesc eu, iar ultimul pas este cel pe care echipele îl sar.

Pasul 1: inventariați ce oferă conexiunea veche

Inventarul se scrie, nu se reține. Notați clienții acceptați, rolurile de autentificare, pool-urile de adrese, rețelele protejate, cerințele DNS și permisiunile de serviciu de care are nevoie fiecare grup de utilizatori.

Pentru L2TP/IPsec, separați explicit cele două straturi. Identitatea partenerului IPsec autentifică mașinile; PPP autentifică utilizatorul, de obicei cu CHAP sau MSCHAPv2.

Exact în această separare își ascund implementările vechi ipotezele. O cheie pre-partajată partajată de fiecare client autentifică un grup, nu un dispozitiv, și adesea este singurul lucru care a fost vreodată rotit. Dacă contul PPP este controlul real pe utilizator, spuneți-o, pentru că înlocuitorul trebuie să reproducă acel control cu ceva ce nu este un șir partajat. Notați și adresele de sursă fixe și excepțiile pentru rețeaua locală, pentru că acestea sunt dependențele pe care nimeni nu le documentează până nu se strică.

Pasul 2: proiectați înlocuitorul în mod deliberat

Alegerea înlocuitorului este o mapare cerință cu cerință: un protocol și un client întreținut pe care organizația le acceptă, fiecare cerință de identitate și acces ajungând într-un mecanism real. Un secret partajat nu este automat echivalent cu o cheie sau un certificat per dispozitiv, iar un cont PPP per utilizator nu este echivalent cu un certificat de dispozitiv.

Coordonați intervalele de adrese înainte de orice altceva, pentru că un pool de înlocuire care se suprapune cu o rețea LAN de acasă sau de birou creează o defecțiune care nu are nimic de-a face cu puterea cifrului. Verificați pool-ul față de aceeași listă pe care ați construit-o pentru serviciul vechi, plus ceea ce noul client presupune implicit. Confirmați rutarea de retur pentru rețelele protejate și confirmați că noul client poate trimite sau documenta sufixul DNS pe care îl trimitea cel vechi. Aceste două puncte produc mai multe tichete de migrare decât schimbarea de protocol în sine.

Pasul 3: implementați etapizat și verificați atât permisiunea, cât și refuzul

Implementați cu un utilizator reprezentativ și o aplicație reprezentativă. Includeți în test rezolvarea DNS privată, pentru că un tunel care ajunge la o adresă dar nu poate rezolva un nume intern este migrat doar pe jumătate. Includeți și starea de indisponibilitate așteptată: ce trebuie să se întâmple când tunelul cade și dacă clientul impune acest lucru.

Apoi testați o destinație care trebuie să rămână refuzată. O regulă largă de permisiune temporară poate face noul tunel să pară sănătos în timp ce elimină în tăcere granița de autorizare pe care o aplica serviciul vechi, iar nimeni nu observă până la un audit. Comparați rezultatele de permisiune și refuz una lângă alta, din același client, în aceeași sesiune. Țineți serviciul vechi în funcțiune până când ambele coloane corespund proiectului.

Înainte de a muta accesul de administrator, confirmați că aveți o cale de recuperare autorizată care nu depinde de tunelul pe care îl modificați.

Pasul 4: retrageți identitatea veche

Retragerea corectă a identității vechi înseamnă revocarea utilizatorilor și a acreditărilor de dispozitiv învechite prin serviciul care le deține, apoi eliminarea profilurilor și a ascultătorilor vechi când nu mai rămâne nicio dependență. Ștergerea unui fișier local nu revocă o copie în altă parte, iar un ascultător vechi care încă acceptă vechiul secret partajat este o ușă fără supraveghere.

Acest punct merită încetinit. Un profil de client dezafectat pe un laptop nu este o acreditare revocată; acreditarea trăiește pe server și rămâne validă până când serverul încetează să o accepte. Căutați alte copii ale configurației vechi — dispozitive de test, un telefon uitat, un instalator pe care cineva l-a păstrat — și tratați oprirea ascultătorului ca momentul în care serviciul vechi se termină cu adevărat. Până atunci, migrarea are două uși din față.

Înregistrarea de acceptare este inventarul de la primul pas cu o coloană adăugată: ce face noul proiect pentru fiecare rând și cum ați verificat. Asta transformă o actualizare de protocol într-o cerință de serviciu cu dovezi.

Țineți rezultatul legat de ce are nevoie serviciul, nu de numele protocolului, pentru că un protocol modern cu ipotezele vechi copiate în el este același risc cu o ramă mai bună. RFC 3193 descrie cum L2TP este transportat peste IPsec, ceea ce este o reamintire utilă că cele două straturi au fost întotdeauna decizii separate. Dacă inventarul are un rând pe care nu îl puteți explica, opriți-vă și aflați ce depinde de el. Migrarea este gata când lista este plictisitoare.