Azure UDR uz VPN vārteju: viens galamērķis, ne visa izeja

Jūs pievienojat lietotāja definētu maršrutu vienam ārējam prefiksam, novirzāt to uz VPN vārteju, un trafiks joprojām iziet pa Azure interneta ceļu. Vai arī tas iziet pareizi un atbilde nekad neatgriežas. Abi rezultāti nāk no vienas kļūdas: uzskatīt Azure nākamo lēcienu par visu dizainu. Maršrutu tabula tikai nosaka, kuru izeju pakete izvēlas Azure iekšienē. Kas ar to notiek pēc tuneļa un kā atgriežas atbilde, ir otrā puse, kas jums jāizbūvē.

Nākamais lēciens ir vārteja, nevis ierīces IP

UDR sūta atbilstošu prefiksu nākamā lēciena tipam, un VirtualNetworkGateway ir tips, nevis adrese. Cilvēki ielīmē vārtejas privāto IP VirtualAppliance maršrutā un tad brīnās, kāpēc nekas nesakrīt, jo šis tips tā vietā gaida NIC vai iekšēju slodzes balansētāju. Microsoft maršrutēšanas dokumentācija arī ierobežo vārtejas nākamo lēcienu ar virtuālo tīklu, kura vārteja ir VPN vārteja. ExpressRoute, Route Server un Virtual WAN centrmezgls ar šo opciju netiek adresēti.

Pirms rakstāt maršrutu, pārbaudiet, kas virtuālajam tīklam patiešām ir. Ja dizains maršrutē caur centrmezglu, maršruts pieder centrmezgla maršrutēšanas īpašniekam, nevis spokam, kuru jūs tieši rediģējat.

Izlasiet spēkā esošo maršrutu pirms kaut kā maiņas

Azure apvieno sistēmas maršrutus, ar BGP apgūtos prefiksus un UDR vienā spēkā esošā maršrutu tabulā katram NIC, un garākais atbilstošais prefikss uzvar neatkarīgi no tā, no kurienes tas nācis. Vienam prefiksam UDR pārspēj BGP maršrutu. Šī kārtība ir iemesls, kāpēc novecojis UDR no iepriekšēja eksperimenta var klusi pārrakstīt prefiksu, ko tikko apguvāt caur tuneli.

Vispirms apskatiet spēkā esošo tabulu, tad izlemiet, vai pievienojat maršrutu vai aizstājat esošo:

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

Lasiet arī avota kolonnu, ne tikai prefiksu. Maršruts ar pareizu prefiksu un nepareizu avotu pasaka, kuru objektu rediģēt, un pasargā no otra maršruta pievienošanas, kas zaudē pirmajam.

Rakstiet maršrutu pret īsto prefiksu un apakštīklu

Izmantojiet īsto galamērķa prefiksu, kas ņemts no pakalpojuma, kuru jūs patiešām sasniedzat, nevis publisku diapazonu, kas nokopēts no foruma ieraksta. Sāciet ar vienu apstiprinātu pakalpojumu, pirms apsverat noklusējuma maršrutu, kas pārvieto visu izeju. Pēc tam piesaistiet maršrutu tabulu darba slodzes apakštīklam. Vārtejas apakštīklam ir savas prasības, un tabulas piesaiste tur salauž vārteju, nevis vada slodzi.

Izveidojiet maršrutu, pēc tam saistiet tabulu ar apakštīklu, kurā atrodas slodze:

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

Arī izplatīšana ir svarīga. Ja šajā tabulā ir iespējota BGP izplatīšana, apgūtie prefiksi parādās līdzās jūsu rakstītajiem, un konkrētāks apgūts prefikss var pārspēt plašāku UDR. Atspējojiet izplatīšanu tikai tad, kad vēlaties, lai UDR kopa būtu autoritatīva šim apakštīklam.

Pabeidziet vietējo pusi, citādi plūsma tur nomirst

Vietējai vārtejai jāpieņem Azure avots, jāpārsūta tas galamērķim un jāatļauj lietojumprogramma. Tās tālākais ceļš var būt interneta izeja vai cits privāts lēciens, bet šis lēmums pieder plānam, nevis Azure maršrutu tabulai. Ierastā kļūda ir atgriešanās. Interneta galamērķis nemaršrutēs privātu Azure avotu atpakaļ pie jums, tāpēc atbilde aiziet uz savu noklusējuma vārteju un nomirst, vai arī nemaz neiziet.

Divi dizaini to atrisina, un tie nav savstarpēji aizstājami. Tulkojiet avotu izejā, lai galamērķis atbildētu uz publisku adresi, kas pieder vietējam tīklam. Vai arī saglabājiet avotu un izveidojiet maršrutētu atgriešanās attiecību, lai atbildes atgrieztos pa tuneli. Izvēlieties vienu un pierakstiet, kuru adresi lietojumprogramma redzēs.

Selektori un atļauto saraksti ir atsevišķi no visa šī. Azure nākamā lēciena izvēle nepaplašina VPN trafika selektorus un nemaina ārēja pakalpojuma avota atļauto sarakstu.

Pārbaudiet ar avotu, ko redz galamērķis

Sūtiet pieprasījumu no īstās slodzes, nevis no lēciena resursdatora citā apakštīklā, pēc tam nolasiet avota adresi, ko galamērķis redzēja. Šī vienīgā vērtība pasaka, kurš no diviem atgriešanās dizainiem ir ieviests. Pēc tam pārbaudiet atbildes ceļu un apstipriniet, ka parastais pārvaldības trafiks uz VM joprojām darbojas, jo nejauši pievienots noklusējuma maršruts parādās kā pārtraukta SSH sesija daudz agrāk, nekā parādās kā bojāta lietojumprogramma.

Tranzīts caur atlasītu prefiksu ir daudz šaurākas izmaiņas nekā piespiedu tuneļošana. Turiet to šauru, un atsaukšana ir viena maršruta dzēšana.