Il NAT di Azure VPN non risolve gli indirizzi VNet sovrapposti
Due VNet con lo stesso intervallo privato non si connettono solo perché esiste NAT. Verificate prima il tipo di connessione, poi rinumerate o possedete un alias di traduzione.
Entrambe le VNet usano 10.40.1.0/24, i tunnel salgono e nulla funziona. Aggiungere un secondo gateway VPN non cambia nulla, e nemmeno una metrica di route più bassa, perché il problema non è la selezione del percorso. Due carichi di lavoro che rispondono allo stesso indirizzo privato lasciano ogni pacchetto con una destinazione ambigua e un percorso di ritorno non verificabile. Prima di pianificare qualsiasi traduzione, scoprite quale tipo di connessione avete creato davvero, perché quella sola scelta decide se la funzione NAT di Azure è disponibile o meno.
Che cosa vi sta dicendo davvero il sintomo
Quando un host nella VNet A invia a 10.40.1.10, la tabella di routing può solo indirizzarlo da qualche parte. Se anche la VNet B contiene 10.40.1.10, quell'indirizzo non è una destinazione che il percorso possa distinguere; è un indirizzo con due proprietari.
Il secondo gateway che di solito si distribuisce non aiuta. Dà un altro tunnel, non un altro indirizzo, e l'intervallo duplicato viaggia invariato dentro il tunnel. Raddoppia anche la configurazione che dovete mantenere coerente. Ciò che non può fare è far significare due host a un indirizzo.
Cambiare gli indirizzi pubblici dei peer VPN non fa nulla neanche. Quegli indirizzi identificano gli estremi del tunnel, mentre la collisione è nell'intervallo privato trasportato all'interno.
Il tipo di connessione decide se NAT è disponibile
Azure VPN Gateway ha effettivamente una capacità NAT, ed è documentata per le connessioni IPsec tra sedi basate su route su specifici SKU del gateway. La stessa documentazione esclude le connessioni VNet-to-VNet e point-to-site, quindi la funzione non è una casella di controllo che compare su ogni relazione di gateway.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Anche la VNet-to-VNet nativa richiede che gli intervalli VNet e di rete locale non si sovrappongano fin dall'inizio, il che è coerente con l'esclusione. Il peering VNet non è una soluzione alla sovrapposizione per lo stesso motivo.
Esiste un'alternativa supportata che la gente confonde con il tipo nativo: modellare l'altra VNet come rete locale e collegarla come connessione da sito a sito. È una risorsa diversa e un progetto diverso, quindi trattate una connessione rinominata come una modifica da validare, non come una semplice rinomina.
Rinumerate, o traducete con qualcosa che possiede l'alias
Se entrambe le VNet sono vostre, confrontate una rinumerazione pianificata con il costo continuo della traduzione. La rinumerazione tocca la configurazione delle applicazioni, i record DNS, le regole di sicurezza e ogni connessione esistente, ma lascia una rete che poi si legge normalmente. Fatelo una subnet alla volta, con la modifica DNS per ultima. Un intervallo rinumerato a metà è peggio di entrambe le opzioni, perché allora entrambi i prefissi sembrano autorevoli a chi leggerà la tabella dopo.
Dove la rinumerazione non è pratica, usate un progetto tradotto con un proprietario reale dell'alias. I chiamanti nella VNet A possono raggiungere 10.40.1.10 della VNet B come 10.140.1.10, ma quell'alias richiede un dispositivo che traduca, una route verso di esso e un comportamento corrispondente per la risposta. Un indirizzo aggiunto solo al DNS non è una traduzione.
Registrate entrambi gli intervalli in entrambe le direzioni: cosa compone il chiamante, cosa vede la destinazione come origine e quale lato può iniziare. Le regole NAT di Azure includono la traduzione inversa per le loro mappature SNAT, quindi non scrivete a mano una regola DNAT corrispondente, ma questa comodità si ferma ai tipi di connessione supportati dalla funzione.
Ciò che non funzionerà
Una route definita dall'utente o una metrica di route non possono creare una distinzione di indirizzi mancante. Entrambe operano su una destinazione ancora ambigua, e il pacchetto arriva al prossimo salto che la tabella preferisce.
Aggiungere l'intervallo duplicato a una tabella di route come prefisso più specifico sposta l'ambiguità solo di un passo. Tende anche a rompere l'altra direzione, dove la risposta ora ha due origini plausibili.
Accettate il progetto con traffico in entrambe le direzioni
Dimostrate il progetto con un'operazione consentita nuova da ciascun lato, non con lo stato del tunnel. Un tunnel IPsec connesso dice che i peer concordano sulla crittografia; non dice nulla sul fatto che le destinazioni siano diventate distinguibili.
Poi eseguite i percorsi negati: un indirizzo che deve restare irraggiungibile e un servizio che la policy deve bloccare. Se entrambi riescono ancora, la traduzione è più ampia di quanto il progetto intendesse.
Chiudete con i fatti che spiegheranno l'installazione più avanti: l'intervallo originale, l'intervallo presentato, il dispositivo che traduce e la direzione in cui ciascun lato può iniziare. Se ne manca uno, l'ingegnere successivo eredita una rete in cui due host condividono un nome e nessuno ricorda perché uno di loro risponda.