VPN S2S ya Azure imeunganishwa lakini hakuna trafiki: soma kumbukumbu ya IKE
Azure inaweza kuonyesha muunganisho wa site-to-site kama Connected wakati kila pakiti inakufa. Kwanza soma kumbukumbu ya IKE iliyohamishwa kwa hitilafu za AH na nafasi ya anwani.
Tovuti inasema Connected, handaki ina kihesabu cha muda wa kufanya kazi, na trace kutoka mashine yako pepe inakufa kwenye hop ya pili. Hali ya muunganisho inaeleza mazungumzo ya IKE na IPsec, si kama pakiti moja inaokoka safu ya sera upande wowote. Hitilafu mbili zinaeleza tiketi nyingi kati ya hizi, na hakuna hata moja inayorekebishwa kwa kubadilisha njia ya Azure. Zote mbili tayari zimeandikwa kwenye kumbukumbu iliyotengenezwa na lango, ndiyo sababu naanza hapo na si kwenye jedwali la njia.
Connected inathibitisha nini kwa kweli
Muunganisho wa site-to-site uliounganishwa unamaanisha kuwa awamu 1 na awamu 2 zimekamilika na vyama vya usalama vinafanya kazi. Hilo ni tamko kuhusu mazungumzo: pande zote mbili zilikubaliana juu ya pendekezo, zikabadilishana funguo na kusakinisha jozi ya SA. Haisemi chochote kuhusu kama wateuzi wa trafiki wanalingana na subnet unazodhani zinalindwa, na pia haisemi kama upande wa mbali utaelekeza pakiti mahali fulani baada ya kuifungua. Handaki linaweza kudumu kwa wiki likitupa kila mtiririko wa kuvutia, na hiyo ndiyo mfumo unaowafanya watu kujenga upya lango lenye afya.
Hitilafu mbili zinazofaa kukaguliwa kwanza ni peer inayopendekeza AH badala ya ESP, na mtandao pepe uliohesabiwa katika nafasi ambayo lango halitaitambua kama ya ndani.
Fungua kumbukumbu iliyohamishwa kabla ya kugusa njia
Kwenye tovuti, fungua lango la mtandao pepe na uendeshe operesheni ya VPN troubleshoot kwenye muunganisho, kisha pakua kifurushi inachotengeneza na ukifungue. Ndani kuna kumbukumbu ya IKE yenye mabadilishano ya awamu 1 na awamu 2, ikiwa na alama za muda na inayosomeka kama maandishi ya kawaida. Tafuta ndani yake mstari wa transform badala ya kusoma kutoka juu hadi chini, kwa sababu ingizo la kuvutia huwa mistari mia kadhaa ndani. Ikiwa huna ufikiaji wa tovuti, utambuzi huo huo unaonekana kwenye lengwa la kumbukumbu ya lango wakati mipangilio ya utambuzi imewashwa.
Ingizo mbili hubeba sehemu kubwa ya thamani. La kwanza linasomeka takriban expected ESP with combined authentication and cipher, received AH. La pili ni hitilafu ya payload isiyo sahihi wakati wa mabadilishano ya IKE, ambayo kwa kawaida inamaanisha sehemu ya pendekezo iliyoundwa vibaya au isiyotumika.
Zote mbili zinaeleza kile kifaa cha ndani kilichopendekeza, kwa hivyo zote ni mipangilio ya upande wa peer. Kuzalisha upya upande wa Azure wa muunganisho hakubadilishi pendekezo linalotumwa na firewall yako, na kufanya hivyo hata hivyo ni saa inayopotea zaidi katika kazi hii. Kwenye peer, weka awamu 2 kwa ESP pamoja na uthibitishaji na sifa zilizochanganywa na uiruhusu kujadili algoriti, kisha angalia kama kisanduku cha kuteua cha muuzaji chenye jina kama combined mode kinachagua kimya kimya pendekezo la AH chini yake.
Thibitisha nafasi ya anwani ya mtandao pepe
Lango linatarajia mtandao pepe uwe katika safu za faragha. Mtandao uliohesabiwa katika kizuizi cha umma, kwa mfano unaoanza na 111.x, unaweza kuinua handaki wakati Azure inakataa kuichukua nafasi hiyo kama ya ndani, kwa hivyo muunganisho unaonekana mzuri na hakuna mtiririko unaokubaliwa. Thibitisha nafasi ya anwani kabla ya kutumia mchana mzima kwenye wateuzi. Ikiwa uhesabuji ni sharti gumu kutoka ugawaji wa zamani, suluhisho ni mabadiliko ya mpango wa anwani na si lango lingine.
Andika mwingiliano na safu za ndani ukiwa kwenye blade ya nafasi ya anwani, kwa sababu viambishi vinavyogiliana hutengeneza hitilafu tofauti ambayo kutoka kwa mteja inaonekana kama ile ile.
Thibitisha viambishi katika pande zote mbili
Rasilimali ya lango la mtandao wa ndani inashikilia viambishi vya ndani, na lazima vilingane na subnet ambazo kifaa cha mbali kinalinda kwa kweli. Muhtasari unaojumuisha anwani ambazo kifaa kinatupa utaruhusu baadhi ya mitiririko kupita na utashindwa kwa mingine, jambo linalosomeka kama hitilafu ya uelekezaji ya mara kwa mara na si kama kutokubaliana kwa usanidi. Angalia pia upande wa mbali: upande mmoja ukiorodhesha /16 wakati mwingine ukiorodhesha /24 tatu ndani yake — hiyo ni kushindwa kwa sehemu ya kawaida. Hakuna orodha inayokuwa na mamlaka yenyewe, kwa hivyo zilinganishe bega kwa bega badala ya kuamini ile unayoweza kuiona.
Mabadiliko ya kiambishi hayakamatwi kila wakati yenyewe, kwa hivyo panga kuhifadhi au kutengeneza upya kipengee cha muunganisho kisha uthibitishe kuwa viambishi vipya vinaonekana pande zote mbili.
Jaribu njia, si ping
Trace inayotenganisha handaki linalofanya kazi na njia inayofanya kazi inaonekana hivi: hop ya kwanza ni lango la ndani, kisha hop kadhaa zisizojibu, kisha mwenyeji wa mbali anajibu. Ikiwa trace haifikii mwenyeji kamwe, jaribu bandari ya TCP ambayo programu inatumia kwa kweli, kwa sababu ICMP huchujwa mara nyingi vya kutosha kwamba ping iliyoshindwa inathibitisha kidogo sana. Endesha trace hiyo hiyo kutoka kwa mwenyeji wa mbali kuelekea mashine pepe ya Azure. Utengano kati ya matokeo mawili ndiyo njia ya haraka zaidi ya kupata njia ya kurudi inayokosekana au kanuni inayoruhusu mwelekeo mmoja tu.
Andika pendekezo la peer, nafasi zote mbili za anwani na muda wa kuundwa kwa muunganisho kwenye tiketi, ili mhandisi anayefuata ajue ni thamani zipi zilijengwa upya na zipi hazikuguswa kamwe.
Ikiwa kumbukumbu inarudi tupu, lango linaweza kuwa halimalizi muunganisho wako kabisa. Thibitisha kuwa anwani ya peer kwenye lango la mtandao wa ndani inalingana na kifaa unachosomea kumbukumbu, kwa sababu malango mawili katika usajili mmoja huchanganywa kwa urahisi wakati wa ujenzi upya. Hitilafu hiyo hugharimu siku moja na haiache alama kwenye kumbukumbu yoyote.