Azure da punto a sito si connette ma nessuna risorsa privata risponde
Connesso significa solo che il tunnel è attivo. Verifica cosa può trasportare il gateway, confronta gli spazi di indirizzi, poi risolvi un nome e prova il servizio stesso.
Connesso è uno stato del tunnel, non un'affermazione sulla raggiungibilità. Un client da punto a sito può completare IKE, ricevere un indirizzo e comunque non raggiungere nulla, perché il gateway inoltra traffico solo per le reti che il VNet conosce già. Esegui questi cinque controlli in ordine e fermati al primo fallimento. Saltare avanti è il modo in cui un problema DNS viene trattato come un problema di firewall per un'ora.
L'ordine conta più dell'elenco.
Controllo 1: decidi cosa deve trasportare il tunnel
Azure VPN Gateway termina il tunnel e inoltra il traffico che appartiene al VNet; non èun'uscita Internet generica. Se gli utenti si aspettano che la loro navigazione esca tramite Azure, il progetto è sbagliato prima ancora che entri in gioco qualsiasi impostazione del client. Attiva lo split tunneling perché Internet locale resti sul percorso locale, e usa un'istanza NAT o un tunnel da sito a sito quando serve davvero un indirizzo di uscita fisso.
Annota cosa deve raggiungere il client prima di testare qualsiasi cosa. Senza quell'elenco, ogni risultato parziale sembra un progresso.
Controllo 2: confronta gli spazi di indirizzi prima dei certificati
La sovrapposizione si giudica sugli intervalli più ampi, quindi due reti che sembrano diverse a livello di subnet si scontrano comunque se i loro blocchi padre si sovrappongono. La subnet del gateway deve essere dedicata e abbastanza grande per lo SKU, e il pool di indirizzi client non deve scontrarsi con il VNet né con nulla raggiungibile tramite un peering. Cambia il piano e ridistribuisci, perché aggiungere route per compensare produce un tunnel che funziona per alcune destinazioni e inspiegabilmente non per altre. Il provisioning qui fallisce rumorosamente, che è il caso buono.
L'autenticazione è la porta successiva. I profili certificato, RADIUS ed Entra ID non sono intercambiabili, e il pacchetto client è diverso per ciascuno.
Controllo 3: risolvi un nome privato dall'interno
Il client mantiene il proprio resolver a meno che il profilo scaricato non contenga i server DNS del VNet, e quell'elenco è incorporato al momento del download. Aggiungi un forwarder nel VNet, impostalo come server DNS del VNet, poi scarica e importa di nuovo il pacchetto client. Riusare il vecchio pacchetto verifica solo il vecchio elenco di resolver.
Prova prima un indirizzo, perché separa l'instradamento dalla denominazione in un solo passaggio: Test-NetConnection 10.20.1.4 -Port 3389.
Se l'indirizzo risponde e il nome no, interroga il resolver direttamente con Resolve-DnsName files.corp.example -Server 10.20.0.4. Se entrambi falliscono, il guasto non è DNS e dovresti smettere di modificare le impostazioni DNS. Il DNS della piattaforma Azure su 168.63.129.16 risponde solo dall'interno del VNet, quindi un client esterno non può usare quell'indirizzo come resolver.
Controllo 4: prova il servizio dietro il tunnel
Un tunnel sano e una porta chiusa sembrano identici dal lato client. Controlla il firewall del guest, poi il gruppo di sicurezza di rete sulla subnet o sulla NIC, poi se il servizio è in ascolto sull'indirizzo privato invece che solo su loopback. Consenti il pool client come origine invece di aprire una regola verso Internet, e ricorda che SMB verso Azure Files richiede il percorso dell'endpoint privato instradato attraverso il tunnel. Quando una risorsa risponde per IP ma non per nome, torna al controllo 3 invece di toccare il gateway.
Una tabella tiene separati i livelli mentre lavori:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Controllo 5: registra il profilo prima di escalare
Metti il tipo di gateway, il tipo di tunnel, il metodo di autenticazione e il sistema operativo del client nel ticket. Un profilo IKEv2 con certificato e un profilo RADIUS falliscono per motivi diversi, e un client creato per un altro tipo di tunnel si connette solo quando il gateway offre un protocollo compatibile.
Per un team piccolo il progetto durevole è un VNet, un forwarder DNS e un client split-tunnel documentato. Se il requisito è un'uscita pubblica fissa, termina un tunnel da sito a sito su un firewall che controlli e instrada lì il traffico Internet, invece di chiedere al gateway da punto a sito qualcosa per cui non è mai stato costruito.