Migrarea unui VPN: licențe, funcții și politică într-un singur registru

Sesiunile care încă funcționează pe vechiul concentrator par o dovadă că migrarea este aproape încheiată. Sunt însă un singur element de inventar, și cel mai puțin interesant. Ceea ce trecerea are nevoie este un registru care leagă gateway-ul țintă, clientul acceptat, dreptul achiziționat și politica de admitere aplicată într-un singur artefact pe care cineva îl deține. Fără el, migrarea este o serie de presupuneri care, luate separat, par rezonabile.

Patru Coloane, Nu o Listă de Verificare

Ce poate duce hardware-ul, ce permite contractul și ce admite setul de reguli sunt trei întrebări separate, iar amestecarea lor produce un plan pe care nimeni nu îl poate audita. Țineți-le în coloane separate și cereți fiecăreia să își citeze sursa. Un dispozitiv care acceptă o conexiune dovedește că un dispozitiv se poate conecta, și nu explică nimic despre aria funcțiilor sau baza de numărare. Trei coloane care nu sunt de acord sunt mult mai utile decât un paragraf care sună sigur.

Registrul este terminat când toate cele patru coloane sunt completate de cineva care are dreptul să le completeze. O coloană semnată de proprietarul greșit este un zvon cu o dată pe el.

Platformă și Drept

Înregistrați gateway-ul acceptat, sistemele de operare ale clientului, calea de autentificare și instrumentele de administrare. Nu țineți în viață un client învechit doar pentru că profilul său vechi încă se deschide, fiindcă acel profil este o afirmație de compatibilitate pe care furnizorul poate să nu o mai onoreze. Comparați declarația de suport actuală cu versiunea pe care intenționați să o implementați.

Pentru drept, înregistrați produsul, tipul de licență, termenul și baza de numărare, apoi reconciliați-l prin proprietarul contului. Deducerea drepturilor dintr-un contor istoric de sesiuni este modul în care o organizație descoperă un deficit după trecere, nu înainte.

Ghidurile de comandă ale furnizorilor arată de ce contează aceste distincții. De exemplu, ghidul de comandă Secure Client de la Cisco separă nivelurile Advantage, Premier și VPN Only, fiecare cu propria măsură și arie de funcții. Folosiți acordul actual în loc să traduceți mecanic o etichetă veche.

Funcții și Politică Aplicată

Enumerați capacitățile de care implementarea are nevoie cu adevărat: moduri de tunel permise, evaluarea dispozitivelor, integrarea autentificării și orice alt modul. Verificați suportul și dreptul pentru fiecare separat, fiindcă o funcție poate fi acceptată și nelicențiată, sau licențiată și neacceptată în versiunea aleasă. Contează doar rândul care răspunde da la ambele întrebări.

Când ținta este un ASA, coloana funcțiilor se citește de pe echipament și nu din contract, așa că capturați gateway-ul înainte de ziua trecerii. show vpn-sessiondb summary oferă inventarul sesiunilor active și numerele față de care este măsurat dreptul dumneavoastră, show vpn-sessiondb detail anyconnect arată ce tip de client și ce profil a folosit efectiv fiecare sesiune atribuită, iar show running-config webvpn capturează configurația gateway-ului de care depind acele sesiuni, și aceasta este singura parte a registrului pe care niciun document de licență nu o poate conține.

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

După trecere, rulați aceleași trei pe noul gateway și comparați-le cu copiile capturate. Schimbarea numărului de sesiuni este de așteptat; un tip de client sau un bloc webvpn care apare pe o parte și nu pe cealaltă este constatarea, și ea aparține registrului cu o explicație, nu unui comentariu de tichet. Păstrați capturile brute precum și diferențele, fiindcă următorul examinator va vrea să vadă ce s-a comparat. La alt furnizor echivalentul este tabelul de sesiuni și exportul de profiluri al acelei platforme, într-un format care nu se va potrivi, așa că comparați întrebările puse acesteia și nu textul.

Apoi mapați utilizatorii și dispozitivele la regulile țintei, permisiunile de resurse și comportamentul de respingere. O licență care activează o funcție nu este o configurație care o exercită, iar golul dintre cele două este locul unde trăiesc cele mai multe surprize ale migrării.

Scrieți cazurile de respingere cu aceeași grijă ca cazurile permise. Un plan care dovedește doar că un administrator se poate conecta a testat cea mai ușoară cale și niciuna dintre limite.

Acceptați pe Ambele Părți ale Deciziei

Înainte de trecere, rulați un plan de acceptare aprobat pe tipurile de client vizate, metodele de autentificare și resurse. Includeți un dispozitiv sau o identitate care trebuie respinsă și confirmați ce regulă l-a selectat și la ce poate ajunge sesiunea rezultată. Conveniți asupra cazurilor de refuz înainte de deschiderea ferestrei de schimbare, ca nimeni să nu le poată elimina în liniște sub presiunea timpului. Un plan fără caz de refuz a testat calea fericită și nimic altceva.

Păstrați o cale de revenire și o rută de administrare care nu depinde de ceea ce se migrează. Preservați configurația și înregistrările de identitate în siguranță și lăsați în urmă setările criptografice învechite în loc să le duceți mai departe. Nu lipiți niciodată identificatori de licență sau înregistrări de utilizatori în note publice.

Puneți proprietarul să semneze dreptul și maparea politicii împreună. Registrul terminat răspunde la două întrebări deodată: ce are organizația licență să implementeze și ce reguli îi admit și îi constrâng cu adevărat utilizatorii.