La verifica del flusso IP di Azure dice consentito, ma la VPN continua a fallire

Tunnel site-to-site connesso, VM sana, il client locale non riceve nulla. Apri Network Watcher, esegui la verifica del flusso IP e questa dice Access allowed, quindi il ticket viene chiuso come problema VPN. Quel risultato non significa ciò che sembra, perché la verifica del flusso IP valuta le regole di sicurezza per il flusso che hai descritto e non verifica mai se Azure ha una route verso il tuo prefisso locale.

La domanda di filtraggio e quella di instradamento sono separate, e Network Watcher risponde con strumenti diversi. Sapere quale hai posto è la maggior parte della diagnosi.

Cosa decide davvero la verifica del flusso IP

La verifica del flusso IP prende una VM, un’interfaccia di rete, una direzione, i valori della quintupla e un protocollo, poi riporta la decisione della regola NSG e dell’amministratore di sicurezza per quel flusso. Funziona su TCP e UDP, quindi non è un tester di regole ICMP e un ping bloccato non dimostra nulla sul tuo servizio. Dagli il flusso reale invece di una supposizione. Una connessione in entrata dall’ambiente locale verso una porta di database è una descrizione diversa da una connessione in uscita avviata dalla VM.

Se il gateway traduce gli indirizzi, usa l’indirizzo di origine che raggiunge il confine che stai valutando, non quello nella configurazione del client. Leggi il risultato anche per quello che è. Access allowed significa che il livello di filtraggio permetterebbe il pacchetto se arrivasse, e nulla di più.

Ciò che non può dirti è la route scelta da Azure, se il firewall del guest consente la porta o se qualcosa è in ascolto. Questo vive ad altri livelli.

Cosa aggiungono il salto successivo e le route efficaci

Il salto successivo risponde a una domanda di inoltro: per questa destinazione, quale tipo di salto successivo sceglie Azure, a quale indirizzo, da quale tabella delle route. Le route efficaci elencano ciò che la NIC ha realmente. Esegui entrambi e ottieni il percorso lato Azure che una verifica del flusso IP verde lascia vuoto.

La panoramica della verifica del flusso IP di Microsoft indica direttamente l’ambito del filtraggio, mentre le pagine sul salto successivo e sulla diagnostica delle route coprono il lato dell’inoltro. Cita la pagina giusta quando scrivi il risultato.

I comandi sono abbastanza brevi da eseguirli da una shell. az network nic show-effective-route-table elenca le route applicate all’interfaccia. az network watcher show-next-hop con un’origine e una destinazione restituisce il salto selezionato. Confronta il prefisso che ti interessa con quella tabella, poi conferma quale voce vince.

Percorri il percorso di ritorno dalla NIC della VM

Fallo dalla NIC della VM di destinazione, per il prefisso del client locale, non per internet. Il percorso di ritorno è dove si nascondono i guasti site-to-site, perché un controllo dello stato del tunnel riporta solo che le associazioni di sicurezza sono attive.

Se la route attesa manca, controlla i prefissi remoti forniti dalla configurazione del gateway, il progetto di connettività del VNet e qualsiasi impostazione di propagazione delle route. Un oggetto gateway di rete locale descrive il lato locale; la sua esistenza non dimostra che ogni prefisso richiesto sia presente e preferito sulla NIC. Sono fatti diversi, e solo uno di essi compare in un riepilogo del portale.

Leggi il tipo di salto successivo invece di copiare un esempio

Un percorso tramite gateway VPN gestito mostra normalmente VirtualNetworkGateway come tipo di salto successivo. VirtualAppliance descrive un progetto di inoltro diverso, di solito un firewall o un’appliance di rete virtuale.

Non creare una route di appliance verso un endpoint VPN ipotizzato solo perché una vecchia risposta di un forum usava quel tipo. Se una route definita dall’utente sostituisce il percorso previsto, trova il proprietario e lo scopo prima di modificarla. Una seconda NIC può anche cambiare quale interfaccia usa il guest, e rimuoverla può rompere un altro servizio invece di correggere questa route.

Passa al confine che continua a fallire

Quando filtraggio e instradamento corrispondono entrambi al progetto, il guasto è altrove. Controlla la tabella delle route del guest, il suo firewall e se l’ascoltatore è associato all’indirizzo atteso. Poi controlla i selettori di traffico protetto della VPN e il percorso di risposta locale. Ciascuno di essi è un test separato con un risultato separato.

Chiudi con una richiesta applicativa consentita e osservazioni da entrambe le estremità. Un risultato allow e un salto successivo corretto sono due pezzi di prova, non la prova che la connessione sia riuscita.