Scegliere una fonte di registrazione stabile per i membri di GET VPN

Qualcuno punta la registrazione del membro del gruppo su un indirizzo loopback e dichiara risolta l'instabilità di GET VPN. A volte è vero. Spesso il loopback è raggiungibile solo dalla tabella di routing del membro stesso e da nessun'altra parte, così la registrazione si rompe di nuovo la volta successiva in cui l'uplink che la trasportava oscilla. L'indirizzo di registrazione è un'identità nel piano di controllo, e aiuta solo quando esiste un percorso reale in entrambe le direzioni. Sceglierlo deliberatamente vale la pena, ed è un cambiamento più piccolo di quanto suggerisca la voce popolare.

Che cosa identifica l'indirizzo di registrazione

In una distribuzione GDOI il membro del gruppo si registra presso il server delle chiavi e ne riceve la politica di gruppo. L'indirizzo che il server delle chiavi registra è l'identità del membro per quella conversazione.

Questa identità copre la conversazione di controllo: registrazione, rinnovo delle chiavi e download della politica. Non diventa l'origine del traffico dei clienti, e non cambia quali interfacce proteggono quali flussi.

Tenere separate le due cose è il primo passo, perché gran parte della confusione su questa impostazione nasce dall'attesa che un cambiamento nel piano di controllo risolva un sintomo del piano dati.

Un loopback vale quanto la sua route

Un loopback dà al membro un indirizzo logico che non scompare quando un uplink fisico si guasta. È un vantaggio reale su un router con diversi percorsi verso il server delle chiavi.

Ma è anche solo un indirizzo. Se il server delle chiavi non ha una route di ritorno verso di esso, la registrazione fallisce esattamente come prima. Se la tabella di routing del membro raggiunge il server delle chiavi solo attraverso un uplink, il loopback è stabile e il percorso no.

Verifica la raggiungibilità in entrambe le direzioni attraverso ogni uplink che vuoi far sopravvivere. Un loopback che resta amministrativamente attivo non dimostra nulla sull'inoltro, e il guasto appare come un server delle chiavi irraggiungibile più che come un problema di interfaccia. Scrivi la verifica come comando per uplink, non come supposizione. Allora la prossima finestra di cambiamento parte da prove e non da uno schema.

Tieni separati controllo e traffico protetto

La guida al bypass GDOI di Cisco documenta l'interfaccia di registrazione e il rapporto tra registrazione e gestione del bypass. Leggi il comportamento della release che esegui davvero invece di trattare una frase come un comando universale.

Esamina filtraggio e traduzione sul percorso di controllo, e conferma che il traffico di gestione delle chiavi non venga trascinato per errore in una politica di protezione che dipende proprio dalla politica di gruppo che sta cercando di ottenere. Quella dipendenza circolare è un modo classico di far fallire una distribuzione funzionante dopo un cambio di politica.

La politica del piano dati è un progetto separato. Cambiare da dove arriva la registrazione lascia i flussi protetti, i selettori e le regole di bypass esattamente dove erano.

Verifica l'identità durante la transizione

Prima del cambiamento, annota il gruppo, l'indirizzo di registrazione scelto, la destinazione del server delle chiavi, il contesto di routing e il percorso di controllo consentito. Dopo un cambio di uplink approvato, ispeziona di nuovo la vista dei membri registrati sul server delle chiavi e lo stato di controllo del membro.

Quello che vuoi vedere è l'endpoint logico previsto ancora raggiungibile e ancora rappresentato come l'hai progettato. Quello che non vuoi è una seconda registrazione da un indirizzo non previsto, perché è così che compaiono le voci duplicate dei membri.

Poi prova il traffico applicativo protetto separatamente. Un trasferimento può riuscire mentre il rinnovo delle chiavi successivo non ha dove andare, e una registrazione riuscita non dice nulla sul fatto che un flusso specifico sia selezionato e instradato correttamente.

Che cosa non risolve una fonte stabile

Non elimina le voci duplicate dei membri create da una configurazione errata precedente. Non ripara un guasto del rinnovo delle chiavi causato da una discrepanza di politica tra membro e server delle chiavi. Non sopravvive al guasto di un percorso fisico che ha rimosso l'unica route verso il server delle chiavi.

Quello che fa è rimuovere una variabile: l'identità non cambia più quando cambia un indirizzo di uplink. Vale la pena averlo, ed è una riga in un progetto e non tutto il progetto.

Ordine di lavoro: nominare il percorso di controllo, scegliere un indirizzo con route in entrambe le direzioni, confermare la vista del server delle chiavi, poi provare il traffico protetto separatamente. Se la registrazione fallisce ancora, il loopback non è mai stato il problema.