Azure-UDR op e VPN-Gateway: eng Destinatioun, net den ganzen Ausgang

Riicht een Azure-Prefix op de VPN-Gateway, ouni den ganzen Ausgang ze verréckelen. Liest déi effektiv Routen, hängt d'Workload-Subnetz un a fäerdeg dann de Réckwee.

Dir füügt eng benotzerdefinéiert Route fir een externen Prefix dobäi, riicht se op de VPN-Gateway, an den Traffic verléisst Azure trotzdem iwwer den Internetspad. Oder en verléisst richteg an d'Äntwert kënnt ni zréck. Béid Resultater kommen aus deem selwechte Feeler: den nächsten Hop an Azure als de ganzen Design ze gesinn. D'Routentabelle entscheet nëmmen, wéi en Ausgang e Paket an Azure hëlt. Wat duerno am Tunnel geschitt, a wéi d'Äntwert zréckkënnt, ass eng zweet Hallschent, déi Dir bauen musst.

Den nächsten Hop ass e Gateway, net d'IP vun engem Apparat

Eng UDR schéckt e passende Prefix un en Typ fir den nächsten Hop, an VirtualNetworkGateway ass en Typ, keng Adress. D'Leit paste d'privat IP vum Gateway an eng VirtualAppliance-Route an froen sech dann, firwat näischt passt, well deen Typ amplaz eng NIC oder e internen Load Balancer erwaart. D'Routingdokumentatioun vu Microsoft limitéiert den nächsten Hop vum Gateway och op e virtuelle Netz, deem säi Gateway e VPN-Gateway ass. ExpressRoute, Route Server an e Virtual WAN-Hub ginn duerch déi Optioun net adresséiert.

Kuckt, wat de virtuelle Netz tatsächlech huet, ier Dir d'Route schreift. Wann den Design iwwer en Hub rout, gehéiert d'Route dem Routingbesëtzer vum Hub an net dem Spoke, deen Dir just ännert.

Liest déi effektiv Route, ier Dir eppes ännert

Azure kombinéiert Systemrouten, iwwer BGP geléiert Prefixen an UDRen an eng effektiv Routentabelle pro NIC, an de längsten passenden Prefix gewënnt, egal vu wou en kënnt. Fir dee selwechte Prefix gewënnt eng UDR géint eng BGP-Route. Dës Reihenfolge ass de Grond, firwat eng al UDR aus engem fréieren Experiment de Prefix, deen Dir just duerch den Tunnel geléiert hutt, roueg iwwerschreiwe kann.

Kuckt fir d'éischt op déi effektiv Tabelle an entscheet dann, ob Dir eng Route derbäi setzt oder eng ersetzt:

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

Liest och d'Quellkolonn, net nëmmen de Prefix. Eng Route mam richtege Prefix an der falscher Quell seet Iech, wéi en Objet ze änneren ass, an et spuert Iech eng zweet Route, déi géint déi éischt verléiert.

Schreift d'Route géint de richtege Prefix an d'richtegt Subnetz

Benotzt de richtege Prefix vum Zil, geholl aus dem Service, deen Dir tatsächlech erreecht, amplaz engem publicleche Beräich, deen aus engem Forumsbeitrag kopéiert gouf. Fänkt mat engem genehmegte Service un, ier Dir eng Standardroute betruecht, déi den ganzen Ausgang verréckelt. Dann hänkt d'Routentabelle un d'Subnetz vun der Workload. D'Gateway-Subnetz huet seng eege Fuerderungen, an Är Tabelle do unzehänken brécht de Gateway amplaz d'Workload ze leeden.

Erstellt d'Route, a verbënnt dann d'Tabelle mat dem Subnetz, dat d'Workload beherbergt:

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

D'Propagatioun ass och wichteg. Mat BGP-Propagatioun op där Tabelle erschéngen geléiert Prefixen nieft deenen, déi Dir geschriwwen hutt, an e méi spezifesche geléierte Prefix kann eng méi breet UDR schloen. Deaktivéiert d'Propagatioun nëmmen, wann Dir wëllt, datt den UDR-Set fir dat Subnetz autoritativ ass.

Fäerdeg déi lokal Hallschent, soss stierft de Floss do

Den lokale Gateway muss d'Azure-Quell ugehuelen, se un d'Zil weiderleeden an d'Applikatioun erlaben. Säi weidere Wee kann en Internetausgang oder en aneren private Hop sinn, awer dës Entscheedung gehéiert an de Plang an net an d'Azure-Routentabelle. Den übleche Feeler ass de Réckwee. En Internetziel wäert eng privat Azure-Quell net zréck zu Iech routen, also geet d'Äntwert op säin eegene Standard-Gateway an stierft, oder se verléisst ni.

Zwee Designen léisen dat an se sinn net austauschbar. Iwwersetzt d'Quell um Ausgang, sou datt d'Zil op eng publiclech Adress äntwert, déi den lokalen Netz besëtzt. Oder behält d'Quell a baut eng geroutete Réckbezéiung, sou datt Äntwerten duerch den Tunnel zréckkommen. Wielt eng a schreift op, wéi eng Adress d'Applikatioun gesinn wäert.

Selektoren an Erlaabnislëschte sinn dovun getrennt. En Azure-Next-Hop ze wielen erweidert d'VPN-Trafficselektoren net, an et ännert keng Quell-Erlaabnislëscht vun engem externen Service.

Iwwerpréift mat der Quell, déi d'Zil gesäit

Schéckt d'Ufro vun der richtege Workload amplaz vun engem Spronghost an engem aneren Subnetz, an liest dann d'Quelladress, déi d'Zil gesinn huet. Deen eenzege Wäert seet Iech, wéi ee vun den zwee Réckdesignen aktiv ass. Préift duerno de Réckwee, a bestätegt, datt normale Verwaltungstraffic op d'VM nach funktionéiert, well eng Standardroute, déi aus Versehen dobäi gesat gouf, sech als gebrachte SSH-Sessioun vill méi fréi weist wéi als gebrachte Applikatioun.

En Transit iwwer e gewielte Prefix ass eng vill méi enk Ännerung wéi erzwongen Tunneling. Hält en enk an de Réckzuch ass eng Route läschen.

Ähnlech Artikelen