UDR ng Azure patungo sa gateway VPN: isang destinasyon, hindi lahat ng labasan

Nagdaragdag ka ng rutang tinukoy ng gumagamit para sa isang panlabas na prefix, itinuturo ito sa VPN gateway, at lumalabas pa rin ang trapiko sa internet path ng Azure. O lumalabas ito nang tama at hindi kailanman bumabalik ang sagot. Ang parehong resulta ay nagmumula sa iisang pagkakamali: ituring ang susunod na hop ng Azure bilang buong disenyo. Ang talahanayan ng ruta ay nagpapasya lamang kung aling labasan ang kinukuha ng packet sa loob ng Azure. Ano ang nangyayari dito pagkatapos ng tunnel, at paano bumabalik ang sagot, ay ang ikalawang kalahati na kailangan mong buuin.

Ang susunod na hop ay isang gateway, hindi IP ng appliance

Nagpapadala ang UDR ng tugmang prefix sa isang uri ng susunod na hop, at ang VirtualNetworkGateway ay isang uri, hindi address. Idinidikit ng mga tao ang pribadong IP ng gateway sa rutang VirtualAppliance at pagkatapos ay nagtatanong kung bakit walang tugma, dahil ang uri na iyon ay umaasa ng NIC o panloob na load balancer sa halip. Nililimitahan din ng dokumentasyon ng routing ng Microsoft ang susunod na hop ng gateway sa isang virtual network na ang gateway ay VPN gateway. Ang ExpressRoute, Route Server at isang hub ng Virtual WAN ay hindi natutugunan ng opsyong iyon.

Tingnan kung ano talaga ang mayroon ang virtual network bago isulat ang ruta. Kung ang disenyo ay nagruruta sa isang hub, ang ruta ay pag-aari ng may-ari ng routing ng hub, hindi ng spoke na ine-edit mo.

Basahin ang epektibong ruta bago magbago ng anuman

Pinagsasama ng Azure ang mga rutang system, mga prefix na natutunan sa BGP at mga UDR sa isang epektibong talahanayan ng ruta bawat NIC, at ang pinakamahabang tugmang prefix ang nananalo saanman ito galing. Para sa parehong prefix, ang UDR ay nananalo sa rutang BGP. Ang pagkakasunod-sunod na iyon ang dahilan kung bakit ang lumang UDR mula sa naunang eksperimento ay maaaring tahimik na maagaw ang prefix na natutunan mo lang sa tunnel.

Tingnan muna ang epektibong talahanayan, pagkatapos ay magpasya kung nagdaragdag ka ng ruta o pumapalit ng isa:

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

Basahin din ang hanay ng pinagmulan, hindi lang ang prefix. Ang rutang may tamang prefix at maling pinagmulan ay nagsasabi kung aling bagay ang i-edit, at inililigtas ka sa pagdaragdag ng pangalawang ruta na natatalo sa una.

Isulat ang ruta ayon sa tunay na prefix at subnet

Gamitin ang tunay na prefix ng patutunguhan, kinuha mula sa serbisyong talagang naaabot mo, sa halip na pampublikong saklaw na kinopya mula sa post sa forum. Magsimula sa isang aprubadong serbisyo bago isaalang-alang ang default na ruta na naglilipat ng lahat ng labasan. Pagkatapos ay ikabit ang talahanayan ng ruta sa subnet ng workload. Ang subnet ng gateway ay may sariling mga kinakailangan, at ang pagkakabit ng iyong talahanayan doon ay sumisira sa gateway sa halip na magdirekta ng workload.

Gumawa ng ruta, pagkatapos ay itali ang talahanayan sa subnet na nagho-host ng workload:

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

Mahalaga rin ang pagpapalaganap. Kapag pinagana ang pagpapalaganap ng BGP sa talahanayang iyon, lumilitaw ang mga natutunang prefix kasama ng mga isinulat mo, at ang mas tiyak na natutunang prefix ay maaaring manalo sa mas malawak na UDR. Huwag paganahin ang pagpapalaganap kapag gusto mo na ang set ng UDR ang maging awtoridad para sa subnet na iyon.

Tapusin ang kalahating on-premises o mamamatay ang daloy doon

Dapat tanggapin ng on-premises na gateway ang pinagmulang Azure, ipasa ito sa patutunguhan at payagan ang aplikasyon. Ang karagdagang landas nito ay maaaring labasan sa internet o ibang pribadong hop, ngunit ang desisyong iyon ay nasa plano, hindi sa talahanayan ng ruta ng Azure. Ang karaniwang kabiguan ay ang pagbabalik. Ang patutunguhan sa internet ay hindi magruruta ng pribadong pinagmulang Azure pabalik sa iyo, kaya ang sagot ay pumupunta sa sarili nitong default na gateway at namamatay, o hindi lumalabas.

Dalawang disenyo ang lumulutas nito at hindi sila mapagpapalit. Isalin ang pinagmulan sa labasan, upang tumugon ang patutunguhan sa pampublikong address na pag-aari ng on-premises na network. O panatilihin ang pinagmulan at bumuo ng rutadong ugnayan ng pagbabalik upang bumalik ang mga sagot sa tunnel. Pumili ng isa at isulat kung aling address ang makikita ng aplikasyon.

Ang mga selector at listahan ng pinapayagan ay hiwalay sa lahat ng ito. Ang pagpili ng susunod na hop ng Azure ay hindi nagpapalawak ng mga selector ng trapiko ng VPN, at hindi binabago ang listahan ng pinapayagang pinagmulan ng panlabas na serbisyo.

I-verify gamit ang pinagmulang nakikita ng patutunguhan

Ipadala ang kahilingan mula sa tunay na workload sa halip na mula sa jump host sa ibang subnet, pagkatapos ay basahin ang address ng pinagmulan na naobserbahan ng patutunguhan. Ang nag-iisang halagang iyon ay nagsasabi kung alin sa dalawang disenyo ng pagbabalik ang nakalagay. Pagkatapos ay tingnan ang landas ng sagot, at tiyakin na gumagana pa rin ang ordinaryong trapiko ng pamamahala patungo sa VM, dahil ang default na rutang naidagdag nang aksidente ay lumilitaw bilang sirang session ng SSH bago pa lumitaw bilang sirang aplikasyon.

Ang pagdaan sa isang piniling prefix ay mas makitid na pagbabago kaysa sapilitang tunneling. Panatilihin itong makitid at ang pag-urong ay pagbura ng isang ruta.