Azure UDR na 'n VPN-gateway: een bestemming, nie alle uitgaande verkeer nie

Jy voeg 'n gebruikergedefinieerde roete vir een eksterne voorvoegsel by, wys dit na die VPN-gateway, en die verkeer verlaat steeds Azure se internetpad. Of dit verlaat korrek en die antwoord kom nooit terug nie. Albei uitkomste kom uit dieselfde fout: om die Azure-volgende sprong as die hele ontwerp te beskou. Die roetetabel besluit net watter uitgang 'n pakket binne Azure neem. Wat na die tonnel daarmee gebeur, en hoe die antwoord terugkom, is 'n tweede helfte wat jy moet bou.

Die volgende sprong is 'n gateway, nie 'n toestel se IP nie

'n UDR stuur 'n ooreenstemmende voorvoegsel na 'n volgende-sprong-tipe, en VirtualNetworkGateway is 'n tipe, nie 'n adres nie. Mense plak die gateway se private IP in 'n VirtualAppliance-roete en wonder dan waarom niks pas nie, want daardie tipe verwag eerder 'n NIC of 'n interne lasbalanseerder. Microsoft se roeteringdokumentasie beperk ook die gateway-volgende-sprong tot 'n virtuele netwerk wie se gateway 'n VPN-gateway is. ExpressRoute, Route Server en 'n Virtual WAN-hub word nie deur daardie opsie geadresseer nie.

Kontroleer wat die virtuele netwerk werklik het voordat jy die roete skryf. As die ontwerp deur 'n hub roeteer, behoort die roete aan die hub se roeteringseienaar eerder as aan die spoke wat jy toevallig redigeer.

Lees die effektiewe roete voordat jy enigiets wysig

Azure kombineer stelselroetes, BGP-geleerde voorvoegsels en UDR's in 'n effektiewe roetetabel per NIC, en die langste ooreenstemmende voorvoegsel wen ongeag waar dit vandaan kom. Vir dieselfde voorvoegsel wen 'n UDR bo 'n BGP-roete. Dié volgorde is waarom 'n verouderde UDR uit 'n vroeëre eksperiment die voorvoegsel wat jy pas deur die tonnel geleer het, stilweg kan oorheers.

Kyk eers na die effektiewe tabel en besluit dan of jy 'n roete byvoeg of een vervang:

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

Lees ook die bron-kolom, nie net die voorvoegsel nie. 'n Roete met die regte voorvoegsel en die verkeerde bron wys jou watter objek om te wysig, en dit voorkom dat jy 'n tweede roete byvoeg wat teen die eerste verloor.

Skryf die roete teen die werklike voorvoegsel en subnet

Gebruik die bestemming se werklike voorvoegsel, geneem van die diens wat jy werklik bereik, eerder as 'n openbare reeks wat uit 'n forumpos gekopieer is. Begin met een goedgekeurde diens voordat jy 'n verstekroete oorweeg wat alle uitgaande verkeer verskuif. Heg dan die roetetabel aan die werklading-subnet. Die gateway-subnet het sy eie vereistes, en om jou tabel daar te heg, breek die gateway eerder as om die werklading te stuur.

Skep die roete en bind dan die tabel aan die subnet wat die werklading huisves:

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

Voortplanting maak ook saak. Met BGP-voortplanting op daardie tabel geaktiveer, verskyn geleerde voorvoegsels langs die wat jy geskryf het, en 'n meer spesifieke geleerde voorvoegsel kan bo 'n breër UDR wen. Deaktiveer voortplanting net wanneer jy bedoel dat die UDR-stel gesaghebbend vir daardie subnet moet wees.

Voltooi die plaaslike helfte, anders sterf die vloei daar

Die plaaslike gateway moet die Azure-bron aanvaar, dit na die bestemming aanstuur en die toepassing toelaat. Sy pad verder kan 'n internetuitgang of 'n ander private sprong wees, maar daardie besluit hoort in die plan eerder as in die Azure-roetetabel. Die gewone fout is die terugpad. 'n Internetbestemming sal nie 'n private Azure-bron na jou terugroeteer nie, so die antwoord gaan na sy eie verstekgateway en sterf, of verlaat nooit.

Twee ontwerpe los dit op, en hulle is nie uitruilbaar nie. Vertaal die bron by die uitgang, sodat die bestemming antwoord na 'n openbare adres wat die plaaslike netwerk besit. Of behou die bron en bou 'n gerouteerde terugverhouding sodat antwoorde deur die tonnel terugkom. Kies een en skryf neer watter adres die toepassing sal sien.

Keuses en toelatingslyste staan apart hiervan. Om 'n Azure-volgende-sprong te kies verbreed nie die VPN-verkeerskeuses nie, en dit verander nie 'n eksterne diens se bron-toelatingslys nie.

Verifieer met die bron wat die bestemming sien

Stuur die versoek vanaf die werklike werklading eerder as vanaf 'n spronggasheer in 'n ander subnet, en lees dan die bronadres wat die bestemming gesien het. Daardie enkele waarde wys watter van die twee terugontwerpe in plek is. Kontroleer daarna die antwoordpad, en bevestig dat gewone bestuursverkeer na die VM steeds werk, want 'n verstekroete wat per ongeluk bygevoeg is, wys as 'n gebreekte SSH-sessie lank voordat dit as 'n gebreekte toepassing wys.

Transito vir 'n gekose voorvoegsel is 'n veel nouer verandering as gedwonge tonneling. Hou dit nou, en die terugrol is om een roete te skrap.