UDR ya Azure kwa lango la VPN: lengo moja, si njia yote ya kutoka

Unaongeza njia iliyofafanuliwa na mtumiaji kwa kiambishi kimoja cha nje, unaielekeza kwenye lango la VPN, na trafiki bado inatoka kupitia njia ya intaneti ya Azure. Au inatoka kwa usahihi na jibu halirudi kamwe. Matokeo yote mawili yanatoka kwenye kosa moja: kuchukua hatua inayofuata ya Azure kama muundo mzima. Jedwali la njia huamua tu ni njia gani ya kutoka ambayo pakiti huchukua ndani ya Azure. Kinachotokea nayo baada ya handaki, na jibu linavyorudi, ni nusu ya pili ambayo unapaswa kuijenga.

Hatua inayofuata ni lango, si IP ya kifaa

UDR hutuma kiambishi kinacholingana kwa aina ya hatua inayofuata, na VirtualNetworkGateway ni aina, si anwani. Watu hubandika IP ya faragha ya lango kwenye njia ya VirtualAppliance kisha hujiuliza kwa nini hakuna kinacholingana, kwa sababu aina hiyo inatarajia NIC au kisawazishaji cha mzigo cha ndani badala yake. Nyaraka za uelekezaji za Microsoft pia huzuia hatua inayofuata ya lango kwenye mtandao pepe ambao lango lake ni lango la VPN. ExpressRoute, Route Server na kitovu cha Virtual WAN hazishughulikiwi na chaguo hilo.

Angalia mtandao pepe unacho kweli kabla ya kuandika njia. Ikiwa muundo unaelekeza kupitia kitovu, njia ni mali ya mmiliki wa uelekezaji wa kitovu, si tawi unalohariri.

Soma njia inayotumika kabla ya kubadilisha chochote

Azure huunganisha njia za mfumo, viambishi vilivyojifunzwa kupitia BGP na UDR kwenye jedwali la njia linalotumika kwa kila NIC, na kiambishi kirefu zaidi kinacholingana hushinda bila kujali kilitoka wapi. Kwa kiambishi kimoja, UDR hushinda njia ya BGP. Mpangilio huo ndio sababu UDR ya zamani kutoka jaribio la awali inaweza kufunika kwa kimya kiambishi ulichojifunza hivi punde kupitia handaki.

Angalia jedwali linalotumika kwanza, kisha amua ikiwa unaongeza njia au unabadilisha moja:

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

Soma pia safu ya chanzo, si kiambishi pekee. Njia yenye kiambishi sahihi na chanzo kisichofaa inakuambia kitu gani cha kuhariri, na inakuokoa kuongeza njia ya pili inayoshindwa na ya kwanza.

Andika njia kulingana na kiambishi na subnet halisi

Tumia kiambishi halisi cha lengo, kilichochukuliwa kutoka huduma unayofikia kwa kweli, badala ya masafa ya umma yaliyonakiliwa kutoka chapisho la jukwaa. Anza na huduma moja iliyoidhinishwa kabla ya kuzingatia njia ya chaguo-msingi inayohamisha njia yote ya kutoka. Kisha ambatisha jedwali la njia kwenye subnet ya mzigo wa kazi. Subnet ya lango ina mahitaji yake, na kuambatisha jedwali lako hapo huvunja lango badala ya kuelekeza mzigo.

Unda njia, kisha funga jedwali kwenye subnet inayoshikilia mzigo wa kazi:

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

Uenezi pia ni muhimu. Ukiwa umewezeshwa uenezi wa BGP kwenye jedwali hilo, viambishi vilivyojifunzwa huonekana kando ya vile ulivyoandika, na kiambishi maalum zaidi kilichojifunzwa kinaweza kushinda UDR pana. Zima uenezi tu unapotaka seti ya UDR iwe na mamlaka kwa subnet hiyo.

Maliza nusu ya ndani la sivyo mtiririko unakufa hapo

Lango la ndani lazima likubali chanzo cha Azure, lilipitishe kwenye lengo na liruhusu programu. Njia yake inayofuata inaweza kuwa njia ya kutoka ya intaneti au hatua nyingine ya faragha, lakini uamuzi huo upo kwenye mpango, si kwenye jedwali la njia la Azure. Kushindwa kwa kawaida ni kurudi. Lengo la intaneti halitaelekeza chanzo cha faragha cha Azure kurudi kwako, kwa hivyo jibu huenda kwenye lango lake la chaguo-msingi na kufa, au halitoki kabisa.

Miundo miwili hutatua hili na haibadilishani. Tafsiri chanzo kwenye njia ya kutoka, ili lengo lijibu anwani ya umma inayomilikiwa na mtandao wa ndani. Au hifadhi chanzo na jenga uhusiano wa kurudi ulioelekezwa ili majibu yarudi kupitia handaki. Chagua kimoja na uandike ni anwani gani programu itaona.

Vichaguzi na orodha za idhini zimetengana na haya yote. Kuchagua hatua inayofuata ya Azure hakupanui vichaguzi vya trafiki vya VPN, na hakubadilishi orodha ya vyanzo vilivyoruhusiwa ya huduma ya nje.

Thibitisha kwa chanzo ambacho lengo huliona

Tuma ombi kutoka kwenye mzigo halisi wa kazi badala ya kutoka kwa mwenyeji wa kuruka kwenye subnet nyingine, kisha soma anwani ya chanzo ambayo lengo iliona. Thamani hiyo moja inakuambia ni muundo gani kati ya miwili ya kurudi ulio hai. Kisha angalia njia ya jibu, na uthibitisha kwamba trafiki ya kawaida ya usimamizi kwa VM bado inafanya kazi, kwa sababu njia ya chaguo-msingi iliyoongezwa kwa bahati mbaya huonekana kama kikao cha SSH kilichovunjika muda mrefu kabla ya kuonekana kama programu iliyovunjika.

Upitishaji kupitia kiambishi kilichochaguliwa ni mabadiliko membamba sana kuliko handaki la kulazimishwa. Iiweke membamba na kurudi nyuma ni kufuta njia moja.