Azure UDR nei in VPN-gateway: ien bestimming, net alle útgong

Jo foegje in brûker definiearre rûte ta foar ien ekstern prefiks, rjochtsje dy op 'e VPN-gateway, en it ferkear giet noch altyd út fia Azure syn ynternetpaad. Of it giet goed út en it antwurd komt nea werom. Beide útkomsten komme fan deselde flater: de Azure-folgjende sprong as it hiele ûntwerp behannelje. De rûtetabel beslútt allinne hokker útgong in pakket yn Azure nimt. Wat der nei de tunnel mei bart, en hoe't it antwurd weromkomt, is in twadde helte dy't jo bouwe moatte.

De folgjende sprong is in gateway, net in IP fan in apparaat

In UDR stjoert in oerienkommend prefiks nei in folgjende-sprong-type, en VirtualNetworkGateway is in type, net in adres. Minsken plakke it privee-IP fan de gateway yn in VirtualAppliance-rûte en freegje har dan ôf wêrom't neat oerienkomt, want dat type ferwachtet earder in NIC of in ynterne load balancer. De routingdokumintaasje fan Microsoft beheint ek de gateway-folgjende-sprong ta in firtueel netwurk waans gateway in VPN-gateway is. ExpressRoute, Route Server en in Virtual WAN-hub wurde net troch dy opsje oansprutsen.

Kontrolearje wat it firtuele netwurk eins hat foardat jo de rûte skriuwe. As it ûntwerp fia in hub rûtet, heart de rûte ta oan de routingeigner fan 'e hub, net oan 'e spoke dy't jo tafallich bewurkje.

Lês de effektive rûte foardat jo wat feroarje

Azure kombinearret systeemrûtes, prefiksen leard fia BGP en UDR's yn in effektive rûtetabel per NIC, en it langste oerienkommende prefiks wint, itsij wêr't it wei komt. Foar itselde prefiks wint in UDR fan in BGP-rûte. Dy folchoarder is wêrom't in ferâldere UDR út in earder eksperimint it prefiks dat jo krekt fia de tunnel leard hawwe, stil oerskriuwe kin.

Sjoch earst nei de effektive tabel en beslút dan oft jo in rûte tafoegje of ien ferfange:

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

Lês ek de boarnekolom, net allinnich it prefiks. In rûte mei it goede prefiks en de ferkearde boarne fertelt jo hokker objekt te bewurkjen, en it rêdt jo fan it tafoegjen fan in twadde rûte dy't fan 'e earste ferliest.

Skriuw de rûte tsjin it echte prefiks en subnet

Brûk it echte prefiks fan 'e bestimming, nommen út 'e tsjinst dy't jo echt berikke, ynstee fan in iepenbier berik kopiearre fan in forumberjocht. Begjin mei ien goedkarde tsjinst foardat jo in standertrûte oerweagje dy't alle útgong ferpleatst. Befêstigje dan de rûtetabel oan it wurklastsubnet. It gatewaysubnet hat syn eigen easken, en jo tabel dêr befêstigje brekt de gateway ynstee fan 'e wurklast te stjoeren.

Meitsje de rûte oan en byn dan de tabel oan it subnet dat de wurklast húsmannet:

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

Propagaasje is ek wichtich. Mei BGP-propagaasje oan op dy tabel ferskine learde prefiksen njonken dy't jo skreaun hawwe, en in mear spesifyk leard prefiks kin in bredere UDR ferslaan. Skeakelje propagaasje allinnich út as jo wolle dat de UDR-set foar dat subnet gesachhawwend is.

Meitsje de lokale helte dien, oars stjert de stream dêr

De lokale gateway moat de Azure-boarne akseptearje, dy trochstjoere nei de bestimming en de applikaasje tastean. Syn fierdere paad kin in ynternetútgong of in oare privee sprong wêze, mar dy beslissing heart yn it plan, net yn 'e Azure-rûtetabel. De gewoane flater is de weromwei. In ynternetbestimming sil in privee Azure-boarne net werom nei jo rûte, dus it antwurd giet nei syn eigen standertgateway en stjert, of giet hielendal net fuort.

Twa ûntwerpen lossen dat op en se binne net útwikselber. Oerset de boarne by de útgong, sadat de bestimming antwurdet op in iepenbier adres dat it lokale netwurk besit. Of bewarje de boarne en bou in rûtearre weromrelaasje sadat antwurden fia de tunnel weromkomme. Kies ien en skriuw op hokker adres de applikaasje sjocht.

Selektors en tastiene listen steane apart fan dit alles. It kiezen fan in Azure-folgjende-sprong ferbreedt de VPN-ferkearsselektors net, en it feroaret de boarne-tastiene list fan in eksterne tsjinst net.

Ferifiearje mei de boarne dy't de bestimming sjocht

Stjoer it fersyk fan 'e echte wurklast ynstee fan fan in springhost yn in oar subnet, en lês dan it boarnadres dat de bestimming seach. Dy iene wearde fertelt jo hokker fan 'e twa weromûntwerpen yn plak is. Kontrolearje dêrnei it antwurdpaad, en befêstigje dat gewoan beheartferkear nei de VM noch wurket, want in standertrûte dy't by ûngelok tafoege is, lit him as in brutsen SSH-sesje sjen folle earder as as in brutsen applikaasje.

Transyt fia in selektearre prefiks is in folle smeller feroaring as twongen tunnelling. Hâld it smel en de weromset is ien rûte fuortsmite.