Migrar una VPN: llicències, funcions i política com un sol registre

Les sessions que encara funcionen al concentrador antic semblen una prova que la migració està gairebé feta. Són un sol element de l’inventari, i el menys interessant. El que el canvi necessita és un registre que lligui la passarel·la de destinació, el client compatible, el dret adquirit i la política d’admissió aplicada en un sol artefacte que algú posseeixi. Sense això, la migració és una sèrie de supòsits que, per separat, semblen raonables.

Quatre columnes, no una llista de verificació

Què pot suportar el maquinari, què permet el contracte i què autoritza el conjunt de regles són tres preguntes separades, i barrejar-les produeix un pla que ningú pot auditar. Mantingueu-les en columnes separades i feu que cadascuna citi la seva font. Un dispositiu que accepta una connexió demostra que un dispositiu es pot connectar, i no explica res sobre l’abast de les funcions ni la base de recompte. Tres columnes que no coincideixen són molt més útils que un paràgraf que sona segur.

El registre s’acaba quan algú amb dret a fer-ho omple les quatre columnes. Una columna signada pel propietari equivocat és un rumor amb data.

Plataforma i dret

Registreu la passarel·la compatible, els sistemes operatius del client, el camí d’autenticació i les eines de gestió. No mantingueu viu un client obsolet només perquè el seu perfil antic encara s’obre, ja que aquest perfil és una afirmació de compatibilitat que el proveïdor potser ja no complirà. Comproveu la declaració de suport actual contra la versió que penseu desplegar.

Pel que fa al dret, registreu el producte, el tipus de llicència, el termini i la base de recompte, i després reconcileu-ho a través del propietari del compte. Inferir drets a partir d’un comptador històric de sessions és com una organització descobreix un dèficit després del canvi i no abans.

Les guies de comanda dels proveïdors il·lustren per què importen aquestes distincions. La guia de comanda de Secure Client de Cisco, per exemple, separa els nivells Advantage, Premier i VPN Only, cadascun amb la seva pròpia mesura i abast de funcions. Feu servir l’acord actual en lloc de traduir mecànicament una etiqueta antiga.

Funcions i política aplicada

Enumereu les capacitats que el desplegament necessita realment: modes de túnel permesos, avaluació de dispositius, integració d’autenticació i qualsevol altre mòdul. Comproveu el suport i el dret de cadascuna per separat, perquè una funció pot estar suportada i sense llicència, o amb llicència i no suportada a la versió triada. Només compta una fila que digui sí a les dues preguntes.

Quan l’objectiu és un ASA, la columna de funcions es llegeix del propi equip i no del contracte, així que captureu la passarel·la abans del dia del canvi. show vpn-sessiondb summary dona l’inventari de sessions actives i els recomptes amb què es mesura el vostre dret, show vpn-sessiondb detail anyconnect mostra quin tipus de client i quin perfil ha usat realment cada sessió atribuïda, i show running-config webvpn captura la configuració de la passarel·la de què depenen aquestes sessions, que és l’única part del registre que cap document de llicència pot contenir.

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

Després del canvi, executeu les mateixes tres ordres a la passarel·la nova i compareu-les amb les còpies capturades. Que els recomptes de sessions es moguin és esperable; un tipus de client o una estrofa webvpn que apareix en un costat i no a l’altre és la troballa, i pertany al registre amb una explicació, no a un comentari d’un tiquet. Deseu les captures en brut així com les diferències, perquè el proper revisor voldrà veure què s’ha comparat. Amb un altre proveïdor l’equivalent és la taula de sessions i l’exportació de perfils d’aquella plataforma, en un format que no coincidirà, així que compareu les preguntes que li feu i no el text.

Després mapeu usuaris i dispositius a les regles de la destinació, els permisos de recursos i el comportament de rebuig. Una llicència que habilita una funció no és una configuració que l’exerceixi, i la bretxa entre les dues és on viuen la majoria de sorpreses de migració.

Escriviu els casos de rebuig amb la mateixa cura que els casos permesos. Un pla que només demostra que un administrador es pot connectar ha provat el camí més fàcil i cap de les fronteres.

Accepteu a banda i banda de la decisió

Abans del canvi, executeu un pla d’acceptació aprovat per als tipus de client previstos, els mètodes d’autenticació i els recursos. Incloeu un dispositiu o una identitat que s’hagi de rebutjar, i confirmeu quina regla l’ha seleccionat i a què pot arribar la sessió resultant. Acordeu els casos de denegació abans que s’obri la finestra de canvi, perquè ningú no els pugui descartar en silenci sota pressió de temps. Un pla sense cap cas de denegació ha provat el camí feliç i res més.

Mantingueu un camí de reversió i una ruta de gestió que no depengui del que s’està migrant. Preserveu la configuració i els registres d’identitat de manera segura, i deixeu enrere els paràmetres criptogràfics obsolets en lloc de portar-los endavant. No enganxeu mai identificadors de llicència ni registres d’usuaris en notes públiques.

Feu que el propietari signi el dret i el mapatge de política alhora. El registre acabat respon dues preguntes alhora: què té llicència per desplegar l’organització i quines regles admeten i restringeixen realment els seus usuaris.