Come un'app Web di Azure raggiunge l'ambiente locale tramite una VPN

La richiesta in uscita dell'app Web lascia un lavoratore che non vedi mai, da una fonte che non hai scelto, e il firewall dell'ufficio deve accettarla. Questo è tutto il problema in una frase. L'integrazione della rete virtuale regionale fornisce alla richiesta un percorso in una rete virtuale e la VPN da sito a sito la trasporta da lì. Tutto ciò che poi va storto riguarda l'intervallo di origine e il percorso effettivamente utilizzato dal pacchetto.

Ciò che effettivamente invia il lavoratore

Il servizio app esegue il codice sui lavoratori che si trovano all'esterno della visualizzazione di rete dell'abbonamento. Con l'integrazione regionale abilitata, il traffico in uscita viene trasferito a una subnet delegata in una rete virtuale nella stessa area e il pacchetto viene visualizzato lì prima di continuare. L'integrazione non sposta l'app nella rete virtuale e non ne modifica l'indirizzo in ingresso. Fornisce solo ai flussi in uscita un primo hop diverso.

Per impostazione predefinita, solo lo spazio degli indirizzi privati segue questo percorso, quindi le destinazioni Internet ordinarie partono comunque direttamente dal lavoratore. Il routing di tutto attraverso la rete virtuale è un'impostazione separata e una decisione separata, perché invia anche le dipendenze pubbliche attraverso il tunnel.

Il traffico di configurazione, ad esempio il pull dell'immagine del contenitore all'avvio, segue le proprie regole di routing e può non riuscire mentre le chiamate API hanno esito positivo.

La sottorete di integrazione è l'origine che devi consentire

L'ufficio vede l'intervallo di indirizzi della sottorete di integrazione o qualunque cosa lo traduca l'appliance, non gli indirizzi in uscita pubblici dell'app. Inserisci tale intervallo nei selettori di traffico della VPN del sito e nella regola del firewall locale. Se il tunnel è basato su criteri, i selettori che lo omettono rilasciano il pacchetto anche quando esiste una route.

Non consentire l'indirizzo di un singolo lavoratore che ti è capitato di osservare. Le istanze cambiano con la scalabilità e la manutenzione della piattaforma e una regola fissata a un indirizzo si interrompe nel momento peggiore.

Mantieni il lato di destinazione ristretto: un servizio, un porto, una direzione, con il percorso di ritorno consentito esplicitamente.

Il peering e il transito del gateway sono espliciti

Se il gateway VPN si trova in una rete virtuale dell'hub e la subnet di integrazione in uno speak, il percorso richiede che il transito del gateway sia consentito sul peering dell'hub e che l'uso del gateway remoto sia abilitato sul peering dello speak. Il peering di per sé trasporta il traffico tra le due reti virtuali e nient'altro. I percorsi effettivi sulla sottorete di integrazione sono quelli in cui confermi che l'hop successivo del gateway è realmente presente.

Una progettazione hub-and-spoke la cui tabella di routing invia 0.0.0.0/0 a un firewall è una variante comune e tale firewall necessita quindi di una propria regola per il prefisso locale.

Disegna il percorso su carta prima di aprire un ticket con il team della rete, perché ti risparmia una giornata di tentativi. Includi la direzione di ritorno nel disegno, poiché è la metà che le persone dimenticano.

L'endpoint privato in entrata è l'altra direzione

Un endpoint privato rende l'app raggiungibile dall'interno di una rete virtuale. Non fa nulla per la chiamata in uscita dell'app verso l'ufficio e i team ne configurano regolarmente una mentre il requisito effettivo era il contrario.

La documentazione precedente descrive l'integrazione richiesta dal gateway basata su VPN da punto a sito, una funzionalità diversa con requisiti propri. Microsoft pianifica il ritiro di questa funzionalità per il 31 marzo 2027 e consiglia invece l'integrazione regionale.

Non copiare una configurazione da punto a sito legacy solo perché la utilizzava un vecchio esempio.

Verifica con il contesto dell'app

Esegui il test dall'app distribuita, non dal tuo laptop e non da una VM nella stessa rete virtuale. Registra separatamente l'indirizzo risolto, il risultato della connessione e la risposta a livello di applicazione, perché un errore DNS, un timeout TCP e un rifiuto di autenticazione puntano su tre proprietari diversi. Se la risoluzione dei nomi fallisce, correggi il DNS privato per la rete virtuale prima di toccare il tunnel.

Lo stato del tunnel verde dimostra solo che il gateway è attivo. Non dice nulla su selettori, regole firewall o DNS.

Quando la richiesta finalmente funziona, scrivi l'intervallo di origine, la porta di destinazione e la zona DNS nel runbook dell'app. La prossima persona che effettuerà il debug inizierà dalla tua nota invece che dalla pagina di stato del gateway.