Azure UDR al VPN-pordego: unu celo, ne la tuta eliro

Vi aldonas uzantodifinitan itineron por unu ekstera prefikso, direktas ĝin al la VPN-pordego, kaj la trafiko ankoraŭ eliras per la interreta vojo de Azure. Aŭ ĝi eliras ĝuste kaj la respondo neniam revenas. Ambaŭ rezultoj venas de la sama eraro: trakti la sekvan salteton de Azure kiel la tutan dezajnon. La itinertabelo nur decidas, kiun eliron paketo prenas ene de Azure. Kio okazas al ĝi post la tunelo, kaj kiel la respondo revenas, estas dua duono, kiun vi devas konstrui.

La sekva salteto estas pordego, ne IP de aparato

UDR sendas kongruan prefikson al tipo de sekva salteto, kaj VirtualNetworkGateway estas tipo, ne adreso. Homoj gluas la privatan IP de la pordego en VirtualAppliance-itineron kaj poste demandas sin, kial nenio kongruas, ĉar tiu tipo atendas NIC aŭ internan ŝarĝbalancilon anstataŭe. La enkursiga dokumentaro de Microsoft ankaŭ limigas la pordegan sekvan salteton al virtuala reto, kies pordego estas VPN-pordego. ExpressRoute, Route Server kaj Virtual WAN-hubo ne estas adresataj per tiu opcio.

Kontrolu, kion la virtuala reto efektive havas, antaŭ ol skribi la itineron. Se la dezajno enkursigas tra hubo, la itinero apartenas al la enkursiga posedanto de la hubo, ne al la spoko, kiun vi hazarde redaktas.

Legu la efikan itineron antaŭ ol ŝanĝi ion ajn

Azure kunigas sistemajn itinerojn, per BGP lernitajn prefiksojn kaj UDR-ojn en efikan itinertabelon por ĉiu NIC, kaj la plej longa kongrua prefikso venkas sendepende de tio, de kie ĝi venis. Por la sama prefikso, UDR superas BGP-itineron. Tiu ordo estas kial malnova UDR el antaŭa eksperimento povas kviete superregi la prefikson, kiun vi ĵus lernis tra la tunelo.

Rigardu unue la efikan tabelon, poste decidu, ĉu vi aldonas itineron aŭ anstataŭigas unu:

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

Legu ankaŭ la fontan kolumnon, ne nur la prefikson. Itinero kun la ĝusta prefikso kaj malĝusta fonto diras al vi, kiun objekton redakti, kaj savas vin de aldono de dua itinero, kiu malvenkas al la unua.

Skribu la itineron laŭ la reala prefikso kaj subreto

Uzu la realan prefikson de la celo, prenitan el la servo, kiun vi efektive atingas, anstataŭ publika gamo kopiita el forumafiŝo. Komencu per unu aprobita servo antaŭ ol konsideri defaŭltan itineron, kiu movas la tutan eliron. Poste alkroĉu la itinertabelon al la subreto de la laborŝarĝo. La pordega subreto havas proprajn postulojn, kaj alkroĉi vian tabelon tie rompas la pordegon anstataŭ direkti la laborŝarĝon.

Kreu la itineron, poste ligi la tabelon al la subreto, kiu gastigas la laborŝarĝon:

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

Ankaŭ disvastigo gravas. Kun BGP-disvastigo ŝaltita sur tiu tabelo, lernitaj prefiksoj aperas apud tiuj, kiujn vi skribis, kaj pli specifa lernita prefikso povas venki pli larĝan UDR-on. Malŝaltu disvastigon nur kiam vi volas, ke la UDR-aro estu aŭtoritata por tiu subreto.

Finu la lokan duonon, alie la fluo mortas tie

La loka pordego devas akcepti la Azure-fonton, plusendi ĝin al la celo kaj permesi la aplikaĵon. Ĝia plua vojo povas esti interreta eliro aŭ alia privata salteto, sed tiu decido apartenas al la plano, ne al la Azure-itinertabelo. La kutima malsukceso estas la reveno. Interreta celo ne enkursigos privatan Azure-fonton reen al vi, do la respondo iras al sia propra defaŭlta pordego kaj mortas, aŭ tute ne eliras.

Du dezajnoj solvas tion kaj ili ne estas interŝanĝeblaj. Traduku la fonton ĉe la eliro, por ke la celo respondu al publika adreso, kiun posedas la loka reto. Aŭ konservu la fonton kaj konstruu enkursigitan revenan rilaton, por ke respondoj revenu tra la tunelo. Elektu unu kaj skribu, kiun adreson la aplikaĵo vidos.

Selektiloj kaj permeslistoj estas apartaj de ĉio ĉi. Elekti Azure-sekvan salteton ne larĝigas la VPN-trafikselektilojn kaj ne ŝanĝas la fontpermesliston de ekstera servo.

Kontrolu per la fonto, kiun la celo observas

Sendu la peton el la reala laborŝarĝo anstataŭ el saltgastiganto en alia subreto, poste legu la fontadreson, kiun la celo observis. Tiu unu valoro diras al vi, kiu el la du revenaj dezajnoj estas en loko. Poste kontrolu la respondan vojon kaj konfirmu, ke ordinara administra trafiko al la VM ankoraŭ funkcias, ĉar defaŭlta itinero aldonita hazarde montriĝas kiel rompita SSH-sesio longe antaŭ ol ĝi montriĝas kiel rompita aplikaĵo.

Traveturo tra elektita prefikso estas multe pli mallarĝa ŝanĝo ol devigita tunelado. Tenu ĝin mallarĝa kaj la retroiro estas forigi unu itineron.