Ridimensiona le sessioni VPN per ruolo, poi verifica il margine di guasto

Aggiungi un secondo gateway, la console mostra due membri sani e il tetto delle sessioni si muove appena, perché nulla ha detto ai client come raggiungere la nuova macchina. Ridimensionare un servizio VPN sono due decisioni in sequenza: quale meccanismo distribuisce i client per questo tipo di connessione e quanta capacità resta dopo la peggiore perdita singola. Prenderle nell'ordine inverso produce un progetto che sembra ridondante e fallisce proprio quando serve. Parti dalla console, poi fai l'aritmetica.

Accoppia il meccanismo al tipo di sessione

Gli utenti remoti, i peer tra sedi e i tunnel dei dispositivi sempre attivi non sono sessioni intercambiabili. Una funzione di distribuzione costruita per uno di essi di solito reindirizza un client durante la negoziazione, il che non significa nulla per un peer che ha già un indirizzo fisso e una configurazione statica.

La guida all'alta disponibilità ASA di Cisco tiene separati tre elementi: bilanciamento del carico VPN per accesso remoto, failover con stato e clustering tra sedi. Solo il primo sposta un client idoneo da una voce di gruppo a un membro, e le connessioni LAN-to-LAN restano fuori da quella distribuzione. Un bilanciatore TCP generico non può sostituire la fase di reindirizzamento propria del protocollo, perché l'handshake del tunnel non è HTTP semplice che un proxy possa riscrivere. Il risultato pratico è un bilanciatore che accetta la connessione e lascia comunque il client incapace di creare il tunnel.

Leggi l'elenco delle funzioni rispetto al tuo tipo di sessione prima di ordinare un secondo dispositivo. La riga della licenza e la riga del meccanismo sono voci separate, e una non implica l'altra.

Calcola l'esempio invece di indovinare

Supponi che tre gateway siano convalidati ciascuno a 800 tunnel simultanei con il carico che hai approvato, per un totale di 2,400. Un obiettivo di 1,650 nell'ora di punta sembra comodo finché non si perde un'unità, e allora la coppia superstite deve tenere 1,650 contro un 1,600 rigido. Il progetto ha già fallito, e nessuna regolazione del failover ripara l'aritmetica.

Fissa l'obiettivo in modo che l'insieme superstite lo rispetti ancora, il che per un gruppo di tre membri significa restare sotto i due terzi del totale. Quel rapporto è una proprietà dell'aritmetica e non di un prodotto, quindi ricalcolalo quando cambia la cifra convalidata di un membro. Tieni il numero concesso in licenza, il massimo documentato e la tua cifra misurata in tre colonne, perché raramente coincidono e la più piccola comanda. Una quarta colonna per il picco osservato nell'ora di punta mantiene il piano onesto dopo il primo mese.

Metti a budget la raffica di riconnessione, non solo lo stato stazionario

Le sessioni di un membro guasto non riappaiono silenziosamente altrove. A seconda del meccanismo, fanno failover con lo stato, rinegoziano da zero o aspettano che l'applicazione riprovi secondo il proprio calendario.

Alcune migliaia di client che riprovano entro un minuto sono un evento diverso da un 1,650 stabile, e i server di autenticazione lo avvertono per primi. Controlla anche lo spazio del pool, perché il reindirizzamento non lo consulta: un membro che non può allocare un indirizzo accetta comunque il client e poi ne scarta il traffico.

Verifica la capacità con il pool e la rotta a portata di mano

La verifica è un esercizio in sola lettura che intercetta la maggior parte degli errori di progetto prima che si apra una finestra di manutenzione. Raccogli il pool per membro, il numero di sessioni attive e la rotta di ritorno verso la sottorete dei client, poi confronta ciascuno con il piano. L'esaurimento del pool e una rotta di ritorno mancante appaiono entrambi come un client che si autentica e poi perde traffico.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Esegui quelle letture su ogni membro durante un'ora di punta normale e non una tranquilla. Un membro che segnala sessioni ma non ha indirizzi liberi è già al suo limite pratico, qualunque cosa dica la licenza. Annota la versione del firmware accanto a ogni output, perché i nomi dei comandi cambiano tra le release.

Prova la perdita una volta di proposito, fuori orario di lavoro, e registra ciò che i membri superstiti segnalano mentre accade. Un membro che accetta il reindirizzamento ma non ha spazio nel pool appare come allocazione fallita, cosa che la larghezza di banda extra non corregge mai. Conserva le cifre convalidate con la data accanto al piano, così la prossima revisione della capacità parte da prove invece che da un foglio di licenze. Aggiungi l'esito di quella prova alla stessa pagina, anche quando le cifre corrispondono al piano.