IP statico in Azure P2S VPN: perché cambia l'indirizzo del client

Ogni client Azure point-to-site riceve un indirizzo dal pool quando si autentica, e lo conserva solo per la durata di quella connessione. Non c'è una tabella di prenotazioni, non c'è una mappatura per utente e non c'è un'impostazione del gateway che significhi «dai sempre 172.16.0.10 a questa persona». Proprio questo unico meccanismo spiega entrambi i sintomi che le persone incontrano più tardi: una regola NSG che smette di corrispondere a un utente a cui prima corrispondeva, e una lista di autorizzati che ammette in silenzio una macchina che nessuno ha aggiunto di proposito. Sostituire la regola con una regola IP più scaltra non risolve né l'una né l'altra, perché ciò che la regola nomina viene riassegnato secondo un calendario che non controlli.

Il pool è capacità, non identità. Esiste perché i tunnel simultanei ottengano indirizzi unici, e li ricicla nel momento in cui un contratto di locazione termina. Una volta chiaro questo, la domanda utile smette di essere «come fisso questo client» e diventa «contro cosa posso scrivere una regola che il gateway non riciclerà».

Che cosa fa realmente il gateway quando un client si connette

Il gateway mantiene il pool di indirizzi dei client configurato e lo tratta come una tabella di locazioni. Alla connessione prende il successivo indirizzo libero, in pratica il più basso disponibile, e lo assegna all'adattatore del tunnel finché il client non si disconnette o la locazione non scade. Decide l'ordine, non l'identità: chi si riconnette per primo dopo un periodo tranquillo ottiene l'indirizzo più basso che in quel momento risulta libero.

La dimensione del pool nasconde il comportamento. Un pool di laboratorio più grande di uno o due indirizzi rispetto al numero di tester sembra deterministico, perché lo stesso portatile tende a riconnettersi nello stesso ordine ogni mattina. Aggiungi una terza macchina, ridimensiona il pool o lascia una sessione connessa durante il pranzo, e lo schema si rompe. L'indirizzo non è mai stato stabile; la coda lo era.

Qualsiasi modifica alla configurazione point-to-site azzera anche lo spazio delle locazioni. Un tipo di autenticazione diverso, un pool ridimensionato, un nuovo intervallo del pool o un gateway abbattuto e ricostruito riportano tutti i client in un pool che non corrisponde più ai loro vecchi indirizzi. Nulla di quella modifica tocca il tuo NSG, ed è per questo che il guasto sembra spontaneo.

Puoi vederlo accadere in circa un minuto. Connettiti, annota l'indirizzo del tunnel nei dettagli di connessione del client, disconnettiti, collega una seconda macchina, poi ricollega la prima. L'indirizzo che ottieni dipende da ciò che tiene la seconda macchina, e nessuna impostazione del portale ripristinerà il precedente su richiesta.

Un NSG basato sull'IP del client è in realtà una regola sull'ordine di connessione

La regola che si scrive per prima è quella ovvia: una regola in ingresso sulla NIC della VM di gestione o sulla sua subnet, con l'indirizzo interno del client VPN come origine. È breve, supera il test il giorno in cui viene scritta e fallisce non appena il pool ha più di un indirizzo libero.

Ne derivano due modalità di guasto, e solo una sembra un bug. Un utente legittimo viene negato perché qualcun altro in quel momento detiene l'indirizzo che la regola nomina, e questo arriva come un fastidioso ticket di assistenza. Oppure un utente non previsto viene ammesso perché ha ereditato un indirizzo di cui la regola si fida ancora, e questo non arriva come nulla finché qualcuno non verifica l'accesso.

Poiché la regola segue la locazione, la politica effettiva recita «la prima persona che si connette ottiene l'accesso amministrativo». È una descrizione dell'ordine di connessione travestita da intenzione, e nessuna igiene delle regole la rende espressione di un'intenzione.

La locazione del client e l'indirizzo del gateway sono oggetti diversi

La maggior parte della confusione viene da una parola. Il gateway ha un IP pubblico relativamente stabile; i client hanno indirizzi privati dal pool che non lo sono. Per un gateway VPN non ridondante per zone l'IP pubblico viene assegnato dinamicamente, ma sopravvive a un ridimensionamento, a un ripristino e alla manutenzione ordinaria: cambia quando il gateway stesso viene eliminato e ricreato. Le SKU del gateway ridondanti per zone e zonali usano un IP pubblico di SKU Standard, e quell'assegnazione deve essere statica.

Questa stabilità è ciò di cui un peer locale ha bisogno nella propria configurazione, e non dice nulla sull'identificazione di un singolo client. Quando un partner chiede quale indirizzo vedrà, la risposta è l'IP pubblico del gateway in site-to-site, o un intervallo NAT condiviso: mai la locazione del tunnel di un portatile.

I pool di gruppo ti danno un intervallo contro cui vale la pena scrivere regole

Virtual WAN point-to-site supporta i gruppi di utenti, e a ogni gruppo può essere assegnato il proprio pool di indirizzi client. L'appartenenza è decisa dall'identità, quindi l'intervallo in cui finisce un client diventa prevedibile: le operazioni in un intervallo, i fornitori in un altro, e l'intervallo è qualcosa che una regola del firewall o dell'NSG può nominare senza indovinare.

L'insieme di regole risultante ha una forma che puoi rivedere:

• un pool per pubblico, dimensionato per i picchi di sessioni simultanee e non per il numero di persone;
• l'appartenenza ai gruppi gestita tramite identità, non modificando le regole ogni volta che qualcuno si aggiunge;
• regole NSG o Azure Firewall scritte contro intervalli del pool, mai contro singole locazioni;
• un hub o un gateway separati per i pubblici che non devono mai condividere un intervallo.

Mettere un intero pool nella lista degli autorizzati è onesto ma grossolano: ogni client connesso in quell'intervallo ottiene lo stesso accesso. È una decisione di politica che vale la pena dire ad alta voce invece di scoprirla durante una revisione. Tutto ciò che richiede ancora una risposta per persona appartiene alla risorsa, tramite assegnazioni di ruolo, non al filtro dei pacchetti.

Quando la distribuzione non può passare a Virtual WAN

Molti gateway restano semplici gateway VPN, e passare a Virtual WAN non è un cambiamento banale. La risposta pratica è spostare la decisione per utente dal filtro dei pacchetti a qualcosa che sa già chi è l'utente.

L'identità a livello di risorsa è la versione più economica. Storage, SQL e Key Vault supportano tutti l'autenticazione Entra ID con assegnazioni di ruolo per utente o per gruppo, quindi la VPN deve solo dimostrare la raggiungibilità di rete. Un jump host con account nominativi fa lo stesso lavoro per le attività amministrative, perché l'host registra la persona e il tunnel trasporta solo pacchetti. Registrare i client nel DNS e autorizzare il nome invece del numero sposta la regola di un livello. L'identità a livello applicativo — un soggetto di certificato, un'attestazione di token, un'appartenenza a un gruppo — funziona quando è l'applicazione, non la rete, a dover decidere.

Per un partner che insiste su un indirizzo di origine fisso, la risposta è site-to-site o ExpressRoute con un prefisso peer definito. Loro autorizzano il prefisso peer, l'indirizzo che appare dalla loro parte appartiene al gateway, e non cambia quando qualcuno riavvia un portatile.

Controlla il pool prima di modificare un'altra lista di autorizzati

Due proprietà del pool causano la maggior parte del comportamento che le persone attribuiscono al client. Un pool troppo piccolo ricicla le locazioni in fretta, quindi gli indirizzi sembrano muoversi continuamente e qualsiasi regola basata sull'indirizzo appare inaffidabile per costruzione. Un pool che si sovrappone agli intervalli locali o allo spazio degli indirizzi della rete virtuale crea un'ambiguità di routing che nessuna regola del firewall ripara.

Metti tre cose su una pagina prima di toccare una regola: il pool point-to-site, lo spazio degli indirizzi della rete virtuale e gli intervalli locali. Non devono sovrapporsi, e il pool ha bisogno di spazio per ogni client simultaneo più un margine per le riconnessioni.

Poi chiudi il ciclo in questo ordine:

• Connettiti da due macchine in entrambi gli ordini e confronta gli indirizzi; se possono scambiarsi, nessuna regola basata sull'indirizzo è sicura.
• Controlla se il gateway è di Virtual WAN; se lo è, usa i pool di gruppo invece delle regole per indirizzo.
• Chiedi cosa accade quando una regola colpisce la persona sbagliata; se la risposta è un incidente di accesso, sposta il controllo sull'identità.
• Annota quale intervallo appartiene a quale gruppo nello stesso repository delle definizioni NSG.
• Ripeti il test dopo qualsiasi modifica al pool, all'autenticazione o al gateway, perché quelle modifiche riscrivono la mappatura senza annunciarlo.