Azure P2S: mteja mmoja wa Windows hupoteza njia baada ya mabadiliko ya VNet
Mteja mmoja wa Windows P2S asipofikia VNet mpya, linganisha njia zilizochaguliwa na uunde upya kifurushi cha lango kabla ya kugusa mipangilio ya TTL.
Kompyuta mpakato mbili huthibitisha kwenye lango moja la Azure point-to-site, na moja tu hufikia VNet mpya iliyounganishwa. Zote mbili zinaonyesha Connected, kwa hiyo uthibitishaji si tofauti; njia za lengwa wanazoshikilia ndizo tofauti. Anza na mteja anayeshindwa, linganisha lengo moja, na baada ya hapo tu amua kama pengo linamilikiwa na kifurushi cha lango au jedwali la njia la ndani.
Anza na mteja anayeshindwa, si lango
Thibitisha topolojia kabla ya kulaumu kompyuta mpakato. Angalia ni VNet zipi zimeunganishwa na VNet ya lango na kama mtandao mpya umefanywa peer moja kwa moja au unafikiwa kupitia handaki tofauti la site-to-site. Ikiwa VNet mpya haijaunganishwa kabisa na VNet ya lango, hakuna kifurushi cha mteja kinachoweza kuelekeza huko, na kompyuta mpakato inayofanya kazi ndiyo hali isiyo ya kawaida inayopaswa kuelezwa. Andika jibu, kwa sababu ndilo linaamua kama unatengeneza mteja au lango.
Topolojia ikiwa sahihi, weka kompyuta mpakato mbili kando kando. Lango moja, bwawa la anwani moja, itifaki moja na toleo la mteja moja ndiyo ulinganisho unaotaka; kitu kingine chochote ni kigezo cha pili utakacholazimika kuondoa baadaye.
Linganisha lengo moja kwa route print
Chagua IP ya rasilimali inayoruhusiwa na linganisha kompyuta mpakato zote mbili mara mbili: zikiwa zimetenganishwa, kisha zimeunganishwa. Kwenye Windows, route print -4 huorodhesha njia za IPv4 pamoja na kiambishi cha lengo, kiolesura, hop inayofuata na kipimo. Rekodi mstari ambao kwa kweli utashinda kwa lengo hilo badala ya kuhesabu maingizo yaliyo na neno VPN.
Uteuzi hufanyika kwanza kwa kiambishi kirefu zaidi, kisha kipimo, kwa hiyo njia ya ndani mahususi zaidi inaweza kushinda njia ya handaki bila kuonekana vibaya. Ikiwa lengo lililokusudiwa liko ndani ya 10.24.0.0/16, mteja mzuri huonyesha njia inayolingana kwenye kiolesura cha VPN, wakati mteja anayeshindwa hutuma anwani hiyo hiyo kwa lango lake chaguo-msingi.
Kiambishi cha ndani kinachogongana kinaweza kutoa dalili hiyo hiyo. Kabla ya kuongeza kitu chochote, amua ni ipi kati ya hali mbili unayo: hakuna njia ya handaki kabisa, au njia ya handaki inayoshindwa na mahususi zaidi.
TTL expired si hitilafu ya usambazaji wa njia
Ping inayorudisha TTL expired in transit inasema kifurushi kilitumia kikomo chake cha hop, ambayo kwa kawaida inamaanisha mzunguko wa upelekaji na si dereva wa VPN mbovu. Ping ya Windows inakubali TTL hadi 255, na kuongeza thamani hakurekebishi mzunguko; inachelewesha kosa lile lile tu. Chukulia ujumbe kama dalili ya njia, si kama ushahidi kuhusu usambazaji wa njia.
Tumia tracert -4 10.24.1.10 kuona mahali njia inarudia. Ikiwa hop mbili zile zile zinaonekana mara kwa mara, tafuta njia inayorudisha trafiki inayoelekea handaki ndani ya handaki au kwa kipanga njia cha ndani kinachoirudisha.
Unde upya kifurushi kwenye lango linalolimiliki
Microsoft inaeleza kwamba vifurushi vya mteja wa Windows lazima vipakuliwe na kusakinishwa upya baada ya mabadiliko muhimu ya topolojia. Chukua kifurushi cha sasa kutoka lango la Azure linalohudumia wasifu huu, kisha litumie kwa mchakato unaotumika kwa mteja huyo. Kubadilisha faili tekelezwa ya programu ya VPN isiyohusiana si operesheni sawa na kuunda upya mipangilio mahususi ya lango. Kupakua kifurushi tena ni rahisi; kukisia njia za ndani si rahisi.
Unganisha tena na usome tena njia ya lengo la awali. Hifadhi mistari ya kabla na baada pamoja na rekodi ya mabadiliko ili matokeo yawe sahihi zaidi kuliko nilisakinisha upya mteja.
Hali za uelekezaji za Azure P2S hutenganisha VNet zilizofanywa peer moja kwa moja na mitandao inayofikiwa kupitia handaki nyingine, na kifurushi kipya hakiwezi kufanya peer kuwa ya kupitisha. Baadhi ya hali za Windows site-to-site au BGP pia zinahitaji njia za mbali zilizowekwa kwa mkono, kwa hiyo kuhuisha kifurushi si utaratibu wa jumla wa usambazaji wa njia.
Acha njia ya muda iwe ya muda
Njia ya mkono inaweza kutenga njia ya mteja inayokosekana, lakini ijenge kutoka muundo halisi: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, bila bendera ya kudumu, ili itoweke wakati wa kuwasha upya. Chagua faharasa ya kiolesura na hop inayofuata kutoka adapta ya VPN iliyounganishwa, si kutoka kwa kukisia.
Usiache njia ya majaribio kama mmiliki shindani wa kudumu. Masasisho ya wasifu ya baadaye yanaweza kuongeza kiambishi kile kile kwa kipimo tofauti, na hapo ingizo la mkono huamua kwa utulivu njia ipi itashinda. Rekodi hatua ya kuondoa katika mabadiliko.
Njia sahihi ikiwa hai, jaribu programu lengwa badala ya ping. Ikiwa vifurushi vinafika Azure lakini huduma bado inashindwa, angalia kikundi cha usalama cha mtandao na njia ya kurudi, kwa sababu hivyo ni tofauti na kama kompyuta mpakato ilijifunza kiambishi.