Può una sola interfaccia WAN servire la VPN tra sedi e l’accesso remoto?

Un solo indirizzo pubblico può servire contemporaneamente un tunnel di sede e un pool di utenti in mobilità. Ma non può servire un’unica regola di ammissione condivisa. Il peer della sede e l’utente in mobilità differiscono in chi dichiarano di essere, in come quella prova viene verificata, negli indirizzi che ricevono e nei prefissi che possono rispondere loro. Quando tratti l’indirizzo esterno come un dettaglio di trasporto e non come un’identità, il progetto diventa molto più semplice.

Una rapida prova di buon senso: prova a scrivere entrambi i record di ammissione prima di toccare il router. Se una sola condizione di abbinamento deve coprire entrambi, la politica è già ambigua, e il primo sintomo sembrerà un guasto di routing o del firewall mentre in realtà è un guasto di identità.

Due record prima di qualsiasi configurazione

Il record della sede è breve e stabile. Elenca l’indirizzo del peer o il nome del certificato, la chiave precondivisa o il trustpoint del certificato, le sottoreti protette su entrambi i lati, l’interfaccia del tunnel e la rotta statica che invia il traffico verso la sede dentro quel tunnel. Ogni campo riguarda un peer noto e un insieme fisso di prefissi.

Il record della mobilità è più ampio e più personale. Elenca il protocollo e la porta del client, come si autentica un utente o un dispositivo, il pool di indirizzi assegnato alla connessione, le risorse che quel pool può raggiungere, i prefissi del tunnel diviso, i server DNS spinti verso il client e qualsiasi secondo fattore. Ogni campo risponde a una domanda su un numero imprecisato di utenti e non su un solo gateway.

Questa differenza di granularità è l’intera ragione per cui i due ruoli divergono. Un profilo di sede può fidarsi tranquillamente di una sola chiave perché la chiave appartiene a un solo dispositivo in un solo sito. Un profilo di mobilità che si fida di una sola chiave di gruppo per tutti annulla la responsabilità per utente, cosa che di solito si scopre più tardi, durante la revisione di un incidente e non durante il rollout.

Dove divergono abbinamento dei peer e autenticazione

Su IOS XE il profilo IKEv2 porta i parametri che non si possono negoziare e le condizioni usate per selezionare il peer. Questo significa che il lato sede e il lato mobilità hanno bisogno ciascuno del proprio profilo, anche quando terminano sulla stessa interfaccia e anche quando condividono una stessa PKI crittografica. Cisco documenta i ruoli del profilo, dell’autenticazione e dell’abbinamento nella sua guida alla configurazione di IKEv2 per IOS XE 17.

Il profilo della sede di solito abbina un’identità stretta: un indirizzo remoto, un FQDN o un soggetto di certificato. Qualcosa come match identity remote address 198.51.100.10 255.255.255.255 blocca un solo peer, e authentication remote pre-share con una chiave memorizzata per sito basta. Mantieni l’abbinamento più specifico che l’inventario dei peer consente, perché un carattere jolly che si sovrappone più in alto nell’ordine di selezione può trascinare il traffico della sede nel profilo sbagliato.

Il profilo della mobilità non può bloccare un indirizzo, quindi abbina un gruppo, un key-id o un campo del certificato, poi affida il vero controllo dell’utente ad AAA o alla politica di autorizzazione legata al profilo. Questa separazione conta: l’autenticazione del peer risponde se il client può costruire un tunnel, e l’autorizzazione per utente risponde quale pool e quali risorse ottiene. Usare la chiave della sede come accesso universale getta via la seconda risposta.

L’inoltro e la traduzione hanno bisogno della stessa separazione

Ammissione e raggiungibilità sono problemi separati. Uno scambio IKE e IPsec riuscito dimostra che le parti concordano sulle chiavi; non crea una rotta verso il pool che il client ha ricevuto. I pool di accesso remoto hanno quindi bisogno di un percorso di ritorno, o una rotta statica che punta all’interfaccia del tunnel o un protocollo di routing che inietta il riepilogo del pool. I prefissi della sede di solito arrivano dallo stesso processo di routing che serve il resto del sito.

La traduzione è il punto in cui i due ruoli si scontrano più spesso. Il traffico tra sedi che deve conservare i propri indirizzi privati ha bisogno di un’esenzione NAT limitata a quei due prefissi, in entrambe le direzioni. I client in mobilità di solito hanno bisogno dell’esenzione anche per il traffico nel tunnel, ma il loro traffico verso internet o aggira il tunnel con il tunnel diviso o esce all’hub dopo il NAT. Esentare tutto ciò che arriva da un tunnel è l’errore classico, perché toglie la traduzione anche a traffico che ne ha davvero bisogno.

Mantieni le regole di esenzione strette come quelle di ammissione. Se un riepilogo di pool e un prefisso di sede si sovrappongono, il percorso di ritorno diventa ambiguo molto prima che venga scartato un solo pacchetto, e il sintomo appare come un sito che perde una sottorete a intermittenza e non come un guasto netto del tunnel.

Casi di accettazione che smascherano una politica incrociata

Costruisci quattro casi ed eseguili in ordine. Un host della sede raggiunge una risorsa riservata alla sede. Un client in mobilità raggiunge la stessa risorsa tramite l’indirizzo del suo pool. Un client in mobilità tenta un prefisso della sede che non dovrebbe toccare. Un peer della sede tenta di ottenere un indirizzo dal pool di accesso remoto. Gli ultimi due sono quelli che catturano un profilo condiviso, perché falliscono in silenzio nel monitoraggio normale.

Poi conferma il piano dati e non la configurazione. show crypto ikev2 sa e show crypto ipsec sa dicono quale profilo e quali selettori hanno portato ogni flusso, mentre show ip nat translations e i contatori del tunnel mostrano se il percorso di ritorno e l’esenzione hanno davvero combaciato. Un tracer o una cattura di pacchetti sull’interfaccia del tunnel chiude il cerchio.

Annota l’identità osservata, l’indirizzo del pool e la politica scelta accanto a ogni risultato. La tornata è conclusa quando ogni caso corrisponde esattamente a un record e nessun caso ha bisogno di un’eccezione temporanea per passare.