UDR Azure verso un gateway VPN: una destinazione, non tutta l'uscita

Aggiungi una route definita dall'utente per un prefisso esterno, la punti al gateway VPN e il traffico esce comunque dal percorso internet di Azure. Oppure esce correttamente e la risposta non torna mai. Entrambi gli esiti nascono dallo stesso errore: considerare il next hop di Azure come l'intero progetto. La tabella delle route decide solo quale uscita prende un pacchetto dentro Azure. Cosa gli succede dopo il tunnel e come torna la risposta è la seconda metà che devi costruire.

Il next hop è un gateway, non l'IP di un'appliance

Una UDR invia un prefisso corrispondente a un tipo di next hop, e VirtualNetworkGateway è un tipo, non un indirizzo. Le persone incollano l'IP privato del gateway in una route VirtualAppliance e poi si chiedono perché nulla corrisponda, perché quel tipo si aspetta invece una NIC o un load balancer interno. Anche la documentazione di routing di Microsoft limita il next hop del gateway a una rete virtuale il cui gateway è un gateway VPN. ExpressRoute, Route Server e un hub Virtual WAN non vengono indirizzati da quell'opzione.

Controlla cosa ha davvero la rete virtuale prima di scrivere la route. Se il progetto instrada attraverso un hub, la route appartiene al proprietario del routing dell'hub e non allo spoke che stai modificando.

Leggi la route effettiva prima di modificare qualsiasi cosa

Azure combina route di sistema, prefissi appresi tramite BGP e UDR in una tabella di route effettiva per NIC, e vince il prefisso corrispondente più lungo, da qualunque parte provenga. Per lo stesso prefisso, una UDR batte una route BGP. Quest'ordine è il motivo per cui una UDR obsoleta di un esperimento precedente può sovrascrivere silenziosamente il prefisso appena appreso attraverso il tunnel.

Guarda prima la tabella effettiva, poi decidi se aggiungere una route o sostituirne una:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Leggi anche la colonna di origine, non solo il prefisso. Una route con il prefisso giusto e l'origine sbagliata ti dice quale oggetto modificare e ti risparmia di aggiungere una seconda route che perde contro la prima.

Scrivi la route sul prefisso e sulla subnet reali

Usa il prefisso reale della destinazione, preso dal servizio che raggiungi davvero, invece di un intervallo pubblico copiato da un post del forum. Inizia con un servizio approvato prima di considerare una route predefinita che sposta tutta l'uscita. Poi collega la tabella delle route alla subnet del carico di lavoro. La subnet del gateway ha i suoi requisiti, e collegarvi la tua tabella rompe il gateway invece di indirizzare il carico.

Crea la route, poi associa la tabella alla subnet che ospita il carico:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Anche la propagazione conta. Con la propagazione BGP attiva su quella tabella, i prefissi appresi compaiono accanto a quelli che hai scritto, e un prefisso appreso più specifico può battere una UDR più ampia. Disattiva la propagazione solo quando vuoi che l'insieme di UDR sia autorevole per quella subnet.

Completa la metà locale o il flusso muore lì

Il gateway locale deve accettare l'origine Azure, inoltrarla alla destinazione e consentire l'applicazione. Il suo percorso successivo può essere un'uscita internet o un altro hop privato, ma quella decisione appartiene al piano e non alla tabella delle route di Azure. Il guasto abituale è il ritorno. Una destinazione internet non instraderà un'origine Azure privata verso di te, quindi la risposta va al proprio gateway predefinito e muore, oppure non esce affatto.

Due progetti lo risolvono e non sono intercambiabili. Traduci l'origine all'uscita, così che la destinazione risponda a un indirizzo pubblico posseduto dalla rete locale. Oppure conserva l'origine e costruisci una relazione di ritorno instradata, così che le risposte tornino attraverso il tunnel. Scegline uno e annota quale indirizzo vedrà l'applicazione.

I selettori e le liste di autorizzazione sono separati da tutto questo. Scegliere un next hop di Azure non allarga i selettori di traffico VPN e non cambia la lista di origine consentita di un servizio esterno.

Verifica con l'origine osservata dalla destinazione

Invia la richiesta dal carico reale invece che da un jump host in un'altra subnet, poi leggi l'indirizzo di origine osservato dalla destinazione. Quel singolo valore ti dice quale dei due progetti di ritorno è in atto. Controlla poi il percorso di risposta e conferma che il normale traffico di gestione verso la VM funzioni ancora, perché una route predefinita aggiunta per errore si manifesta come sessione SSH rotta molto prima di manifestarsi come applicazione rotta.

Un transito su un prefisso selezionato è un cambiamento molto più stretto del tunneling forzato. Mantienilo stretto e il rollback consiste nel cancellare una route.