NAT ya Azure VPN haitatui anwani za VNet zinazopishana
VNet mbili zenye safu moja ya kibinafsi hazitaunganishwa kwa sababu tu NAT ipo. Angalia kwanza aina ya muunganisho, kisha panga upya nambari au umiliki jina la utani la tafsiri.
VNet zote mbili zinatumia 10.40.1.0/24, vichuguu vinapanda, na hakuna kinachofanya kazi. Kuongeza lango la pili la VPN hakubadilishi hilo, na wala kipimo cha njia cha chini, kwa sababu tatizo si uchaguzi wa njia. Mizigo miwili ya kazi inayojibu anwani moja ya kibinafsi huacha kila pakiti na lengo lisilo wazi na njia ya kurudi isiyoweza kuthibitishwa. Kabla ya kupanga tafsiri yoyote, tambua ni aina gani ya muunganisho uliunda kwa kweli, kwa sababu uchaguzi huo mmoja huamua ikiwa kipengele cha NAT cha Azure kinapatikana kabisa.
Dalili hii inakuambia nini kwa kweli
Wakati mwenyeji katika VNet A anatuma kwa 10.40.1.10, jedwali la njia linaweza tu kuelekeza mahali fulani. Ikiwa VNet B pia ina 10.40.1.10, anwani hiyo si lengo ambalo njia inaweza kutofautisha; ni anwani moja yenye wamiliki wawili.
Lango la pili ambalo watu huwa wanaweka halisaidii. Linakupa kichuguu kingine, si anwani nyingine, na safu iliyorudiwa husafiri ndani ya kichuguu bila kubadilika. Pia huongeza mara mbili usanidi ambao lazima uendelee kuwa sawa. Kinachoshindwa ni kufanya anwani moja imaanishe wenyeji wawili.
Kubadilisha anwani za umma za wenza wa VPN pia hakufanyi kitu. Anwani hizo hutambua ncha za kichuguu, wakati mgongano uko katika safu ya kibinafsi inayobebwa ndani yake.
Aina ya muunganisho huamua ikiwa NAT inapatikana
Azure VPN Gateway ina uwezo wa NAT kwa kweli, na umeandikwa kwa miunganisho ya IPsec kati ya maeneo inayotegemea njia kwenye SKU maalum za lango. Nyaraka hizo hizo zinaondoa miunganisho ya VNet-to-VNet na point-to-site, kwa hiyo kipengele si kisanduku cha kuteua kinachoonekana kwenye kila uhusiano wa lango.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
VNet-to-VNet asilia pia inahitaji safu za VNet na mtandao wa ndani zisipishane kuanzia mwanzo, jambo linaloendana na kuondolewa huko. Ushirikiano wa VNet pia si suluhisho la kupishana kwa sababu hiyo hiyo.
Kuna mbadala unaotumika ambao watu huuchanganya na aina asilia: fanya VNet nyingine kuwa mtandao wa ndani na uiunganishe kama muunganisho wa tovuti-kwa-tovuti. Hiyo ni rasilimali nyingine na muundo mwingine, kwa hiyo chukulia muunganisho uliobadilishwa jina kama mabadiliko yanayohitaji kuthibitishwa, si kama kubadilisha jina tu.
Panga upya nambari, au tafsiri kwa kitu kinachomiliki jina la utani
Ikiwa VNet zote mbili ni zako, linganisha upangaji upya wa nambari uliopangwa na gharama endelevu ya tafsiri. Upangaji upya wa nambari hugusa usanidi wa programu, rekodi za DNS, kanuni za usalama na kila muunganisho uliopo, lakini huacha mtandao unaosomwa kawaida baadaye. Fanya subnet moja kwa wakati, na mabadiliko ya DNS ya mwisho. Safu iliyopangwa upya nusu ni mbaya kuliko chaguo lolote, kwa sababu wakati huo viambishi viwili vinaonekana kuwa na mamlaka kwa yeyote atakayesoma jedwali baadaye.
Ambapo upangaji upya wa nambari si wa vitendo, tumia muundo uliotafsiriwa wenye mmiliki halisi wa jina la utani. Wapigaji katika VNet A wanaweza kufikia 10.40.1.10 ya VNet B kama 10.140.1.10, lakini jina la utani hilo linahitaji kifaa kinachotafsiri, njia kuelekea kwake na tabia inayolingana kwa jibu. Anwani iliyoongezwa kwenye DNS pekee si tafsiri.
Rekodi safu zote mbili katika pande zote mbili: mpigaji anapiga nini, lengo linaona nini kama chanzo, na upande gani unaweza kuanzisha. Kanuni za NAT za Azure zenyewe zinajumuisha tafsiri ya kinyume kwa ramani zao za SNAT, kwa hiyo hauandiki kanuni ya DNAT inayolingana kwa mkono, lakini urahisi huo huishia kwenye aina za muunganisho ambazo kipengele kinaunga mkono.
Nini hakitafanya kazi
Njia iliyofafanuliwa na mtumiaji au kipimo cha njia haviwezi kuunda tofauti ya anwani inayokosekana. Zote mbili hufanya kazi kwenye lengo ambalo bado haliko wazi, na pakiti hufika kwenye hatua inayofuata ambayo jedwali linapendelea.
Kuongeza safu iliyorudiwa kwenye jedwali la njia kama kiambishi maalum zaidi huhamisha utata hatua moja tu. Pia huelekea kuvunja upande wa pili, ambapo jibu sasa lina vyanzo viwili vinavyowezekana.
Kubali muundo na trafiki katika pande zote mbili
Thibitisha muundo kwa operesheni mpya inayoruhusiwa kutoka kila upande, si kwa hali ya kichuguu. Kichuguu cha IPsec kilichounganishwa kinasema wenza wanakubali kuhusu usimbaji fiche; hakisemi chochote kuhusu ikiwa malengo yameweza kutofautishwa.
Kisha endesha njia zilizokataliwa: anwani inayopaswa kubaki isiyofikiwa, na huduma ambayo sera inapaswa kuizuia. Ikiwa zote mbili bado zinafanikiwa, tafsiri ni pana kuliko muundo ulivyokusudia.
Maliza na ukweli unaoeleza usanidi baadaye: safu ya awali, safu iliyowasilishwa, kifaa kinachotafsiri, na mwelekeo ambao kila upande unaweza kuanzisha. Ikiwa moja ya haya hayapo, mhandisi anayefuata anarithi mtandao ambapo wenyeji wawili wanashiriki jina moja na hakuna anayekumbuka kwa nini mmoja wao anajibu.