Trafiki ya kurudi ya Azure P2S VPN inafanya kazi upande mmoja tu

Aikoni ya tuneli ni ya kijani, NSG inaonekana inaruhusu, njia zenye ufanisi zinaonekana sahihi, na bado VM haiwezi kufungua muunganisho kurudi kwa mteja aliyeunganishwa. Dhana ya kawaida ni kwamba tuneli ya point-to-site inayofanya kazi ni ya ulinganifu: ikiwa mteja anafikia VM, VM inafikia mteja. Dhana hiyo ndiyo kosa katika kufikiri, si katika usanidi. Tuneli inaweza kubeba mwelekeo mmoja wa mtiririko usioombwa na kuacha mwingine, na marekebisho yanategemea tabaka gani linaiacha.

Hadithi potofu: tuneli iliyounganishwa ni tuneli ya pande mbili

Tuneli ya VPN ni njia ya sera, si waya. Kila mwelekeo hulinganishwa na wateule, njia na vichujio, na yoyote kati yao inaweza kuruhusu mwelekeo mmoja huku ikizuia mwingine.

Kwa vitendo kutofanana ni kawaida kiasi kwamba mwelekeo unapaswa kuwa katika jaribio la kwanza, si la mwisho. Mteja huanzisha, lango hufuata mtiririko, na jibu hufuata hali iliyoundwa. VM inayoanza mtiririko mpya haina hali kama hiyo, kwa hiyo inategemea njia ya kurudi kuwa rahisi kuelekezwa na kuruhusiwa kwa uwazi. Njia hiyo inapokosekana, jaribio la muunganisho hufa kabla ya programu yoyote kuiona.

Jaribu mwelekeo kabla ya kujaribu ufikikaji

Chagua anwani moja ya mteja, anwani moja ya VM na itifaki moja. Unganisha kutoka kwa mteja na uandike matokeo; kisha anza jaribio hilo hilo kutoka kwa VM na uandike pia. Ikiwa la kwanza linafanikiwa na la pili likashindwa, bwawa la wateja, muunganisho wa lango na njia ya mteja hadi VNet zote zinafanya kazi.

Hatua inayofuata ni ushahidi, si sheria zaidi. Angalia NSG kwenye subnet ya VM pande zote mbili, soma njia zenye ufanisi kwenye NIC ya VM, na nasa pakiti kwenye VM wakati mteja anatuma trafiki. Ombi linalofika bila jibu ni tatizo la kichujio au njia ya kurudi; ombi lisilofika kamwe ni tatizo la njia. Usichukue ping iliyoshindwa kama ushahidi kwamba VM haifikiki, kwa sababu sera ya ICMP inaweza kuacha jibu wakati TCP inafanya kazi.

Njia ya kurudi ya IKEv2 point-to-site ndiye mtuhumiwa wa kawaida

Katika ripoti ya Azure iliyo nyuma ya makala hii, mteja aliweza kufikia VM kwa njia ya IKEv2, lakini ICMP inayoingia kutoka VM kwenda kwa mteja ilishindwa hadi aina ya tuneli ya lango ilipobadilishwa kuwa OpenVPN. Mwandishi wa ripoti anasema Microsoft ilithibitisha ukomo katika njia ya IKEv2 point-to-site, ambapo trafiki ya kurudi kutoka VM kwenda kwa mteja haielekezwi kwa ulinganifu isipokuwa mteja alianza kipindi. IKEv2 inategemea wateule wa trafiki, na lango halikuheshimu mwelekeo wa kurudi katika kesi hiyo.

Hilo halifanyi OpenVPN kuwa aina bora ya tuneli kwa ujumla. Linafanya aina ya tuneli kuwa kigeugeu katika matriki ya majaribio kwa mzigo huu wa kazi.

Kubadilisha aina ya tuneli ni mabadiliko ya huduma, si swichi. Kila mteja anahitaji wasifu unaoendana, na lango linaweza kuhitaji cheti au usanidi wa uthibitishaji tofauti. Zalisha upya tabia ya upande mmoja na mteja mmoja wa majaribio na VM moja ya majaribio, badilisha aina kwa ratiba iliyoidhinishwa, kisha rudia majaribio yale yale ya mwelekeo. Ikiwa tabia itaendelea baada ya mabadiliko, aina ya tuneli haikuwa sababu na umepunguza tatizo bila kugusa uzalishaji.

Hadithi potofu: ugunduzi wa broadcast huvuka ukingo wa VNet

Dhana ya pili inashindwa kwa sababu isiyohusiana. Mtandao pepe wa Azure haubebi trafiki ya broadcast, kwa hiyo VM haiwezi kupokea fremu za broadcast kutoka mtandao wa ndani kupitia muunganisho wa site-to-site au point-to-site. Programu zinazopata wenza kwa njia ya broadcast, kama kuvinjari faili za zamani au baadhi ya itifaki za kugundua kifaa, hazitawahi kuona upande wa mbali, bila kujali njia zimeandikwa vipi.

Badilisha ugunduzi wa broadcast na majina ya DNS, huduma ya saraka au orodha wazi ya wenza. Ikiwa programu haina mbadala wa unicast, muundo unahitaji utaratibu mwingine wa ugunduzi, si tuneli pana zaidi.

Nini cha kubadilisha, na jinsi ya kuthibitisha

Ikiwa jaribio la mwelekeo linashindwa tu kwenye IKEv2, andika aina ya tuneli ya lango, bwawa la anwani za wateja na jaribio kamili la ICMP au TCP, kisha tathmini wasifu wa OpenVPN ulioidhinishwa kwa wateja walioathirika. Ikiwa linashindwa kwa kila aina ya tuneli, fanya kazi kwenye njia ya kurudi: anwani ya mteja lazima iweze kuelekezwa kutoka subnet ya VM, njia yoyote iliyobainishwa na mtumiaji lazima ielekeze kwenye hop inayofuata halali, na firewall ya mteja lazima ikubali mtiririko unaoingia. Ambatisha ushahidi wa NSG na njia kwenye tiketi.

Thibitisha kwa programu, si kwa ping. Ubadilishanaji wa ICMP uliofanikiwa baada ya mabadiliko hausemi chochote kuhusu bandari ya huduma, uthibitishaji wake au utatuzi wa majina. Rudia jaribio baada ya kuunganisha upya, kwa sababu mteja anayepokea anwani tofauti kutoka bwawa anaweza kubadilisha matokeo. Kisha rudia mara moja zaidi baada ya mteja kulala na kuamka, kwa sababu ni katika kipindi kilichoendelea ambapo tabia ya upande mmoja mara nyingi hujitokeza tena.