UDR d'Azure cap a una passarel·la VPN: una destinació, no tota la sortida

Afegiu una ruta definida per l'usuari per a un prefix extern, l'apunteu a la passarel·la VPN i el trànsit segueix sortint pel camí d'internet d'Azure. O surt correctament i la resposta no torna mai. Tots dos resultats vénen del mateix error: tractar el següent salt d'Azure com tot el disseny. La taula de rutes només decideix quina sortida pren un paquet dins d'Azure. Què li passa després del túnel i com torna la resposta és una segona meitat que heu de construir.

El següent salt és una passarel·la, no la IP d'un aparell

Una UDR envia un prefix coincident a un tipus de següent salt, i VirtualNetworkGateway és un tipus, no una adreça. La gent enganxa la IP privada de la passarel·la en una ruta VirtualAppliance i després es pregunta per què no coincideix res, perquè aquest tipus espera una NIC o un balancejador de càrrega intern. La documentació d'encaminament de Microsoft també limita el següent salt de passarel·la a una xarxa virtual amb una passarel·la VPN. ExpressRoute, Route Server i un concentrador de Virtual WAN no s'adrecen amb aquesta opció.

Comproveu què té realment la xarxa virtual abans d'escriure la ruta. Si el disseny encamina a través d'un concentrador, la ruta pertany al propietari de l'encaminament del concentrador i no a la branca que esteu editant.

Llegiu la ruta efectiva abans de modificar res

Azure combina rutes de sistema, prefixos après per BGP i UDR en una taula de rutes efectiva per NIC, i guanya el prefix coincident més llarg vingui d'on vingui. Per al mateix prefix, una UDR guanya una ruta BGP. Aquest ordre és la raó per la qual una UDR antiga d'un experiment anterior pot superar en silenci el prefix que acabeu d'aprendre pel túnel.

Mireu primer la taula efectiva i després decidiu si afegiu una ruta o en substituïu una:

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

Llegiu també la columna d'origen, no només el prefix. Una ruta amb el prefix correcte i l'origen equivocat us diu quin objecte editar i us estalvia afegir una segona ruta que perd contra la primera.

Escriviu la ruta amb el prefix i la subxarxa reals

Feu servir el prefix real de la destinació, pres del servei al qual arribeu de debò, en lloc d'un rang públic copiat d'un missatge de fòrum. Comenceu amb un servei aprovat abans de plantejar una ruta per defecte que mogui tota la sortida. Després adjunteu la taula de rutes a la subxarxa de la càrrega de treball. La subxarxa de passarel·la té els seus propis requisits, i adjuntar-hi la vostra taula trenca la passarel·la en lloc de dirigir la càrrega.

Creeu la ruta i després lligueu la taula a la subxarxa que allotja la càrrega:

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

La propagació també importa. Amb la propagació BGP activada en aquesta taula, els prefixos apresos apareixen al costat dels que heu escrit, i un prefix après més específic pot guanyar una UDR més àmplia. Desactiveu la propagació només quan vulgueu que el conjunt d'UDR sigui autoritatiu per a aquesta subxarxa.

Acabeu la meitat local o el flux mor allà

La passarel·la local ha d'acceptar l'origen d'Azure, encaminar-lo a la destinació i permetre l'aplicació. El seu camí posterior pot ser una sortida a internet o un altre salt privat, però aquesta decisió pertany al pla i no a la taula de rutes d'Azure. La fallada habitual és la tornada. Una destinació d'internet no encaminarà un origen privat d'Azure de tornada cap a vosaltres, així que la resposta va al seu propi portal d'enllaç i mor, o no surt mai.

Dos dissenys ho resolen i no són intercanviables. Traduïu l'origen a la sortida, de manera que la destinació respon a una adreça pública que posseeix la xarxa local. O conserveu l'origen i construïu una relació de retorn encaminada perquè les respostes tornin pel túnel. Trieu-ne un i anoteu quina adreça veurà l'aplicació.

Els selectors i les llistes d'autorització són a part de tot això. Triar un següent salt d'Azure no amplia els selectors de trànsit de la VPN ni canvia la llista d'orígens permesos d'un servei extern.

Verifiqueu amb l'origen que observa la destinació

Envieu la petició des de la càrrega real i no des d'un amfitrió de salt en una altra subxarxa, i després llegiu l'adreça d'origen que ha observat la destinació. Aquest sol valor us diu quin dels dos dissenys de retorn hi ha. Comproveu després el camí de resposta i confirmeu que el trànsit habitual de gestió a la VM encara funciona, perquè una ruta per defecte afegida per accident es mostra com una sessió SSH trencada molt abans que com una aplicació trencada.

Un trànsit per un prefix seleccionat és un canvi molt més estret que el túnel forçat. Manteniu-lo estret i la reversió és esborrar una ruta.