Bakit pinutol ng pagdaragdag ng Azure VPN prefix ang koneksyon

Ang prefix na idinagdag sa maling Azure object ay gumagawa ng koneksyon na nag-uulat ng Connected at walang ipinapasa, at ito ang pinakamahal na uri ng pagkakamali sa stack na ito. Tatlong resource ang sangkot at isa lamang sa kanila ang nagmamay-ari ng malayong address space: ang virtual network gateway, ang lokal na network gateway na naglalarawan sa malayong panig, at ang koneksyon na nag-uugnay sa kanila. Ang prefix ay pag-aari ng lokal na network gateway, kailangang muling itayo ang koneksyon para magkabisa ang pagbabago, at ang gateway mismo ay karaniwang hinahayaang hindi ginalaw. Ang pagkakasunod-sunod ay hindi mapag-uusapan, at ang portal ay nagpapakita lamang ng bahagi nito.

Tatlong object, isa sa kanila ang humahawak ng prefix

Ang address space ng virtual network ay sumasagot sa ibang tanong: ano ang nakatira sa loob ng Azure. Ang pagdaragdag ng malayong prefix doon ay hindi nagruruta ng trapiko doon, pinapalawak lamang nito ang espasyong inaakala ng platform na pag-aari nito, na maaaring bumangga sa tunay na malayong saklaw. Ang lokal na network gateway ang object na humahawak ng malalayong prefix, at ang koneksyon ay tumutukoy sa dalawang gateway at sa key na ibinahagi nang maaga.

May ikatlong kondisyon na dapat tandaan. GatewaySubnet ay nagho-host ng mga managed gateway instance, dapat nitong dalhin ang eksaktong pangalang iyon, at para sa mga SKU na hindi Basic inaasahang hindi bababa sa /27.

Wala nang ibang kabilang sa subnet na iyon, at ang pagbabago ng prefix ay walang dahilan para galawin ito. Ang prefix na nawawala sa lokal na network gateway ay hindi maabot anuman ang sabihin ng estado ng koneksyon, dahil ang gateway ay nag-aalok lamang ng mga prefix na ipinaalam dito noong nakikipag-usap ito sa tunnel. Iyon ang dahilan kung bakit asimetriko ang sintomas: nakataas ang tunnel, maayos ang security association, at isang subnet ang hindi kailanman lumalabas sa mga tagapili ng trapiko. Kung isang malayong saklaw ang nawawala habang gumagana ang mga kapitbahay, tigilan ang pagtingin sa tunnel at basahin ang lokal na network gateway.

Bakit ang koneksyon ang inaalis

Ang object ng koneksyon ay nagpi-pin ng napag-usapang configuration sa buong buhay nito. Kaya't inaalis muna ng dokumentadong pamamaraan ang koneksyon, ina-update ang lokal na network gateway, at pagkatapos ay muling ginagawa ang koneksyon gamit ang parehong shared key. Ang mga gateway instance ay hindi muling itinayo para sa pagbabagong prefix lamang, na naglilimita sa pagkaantala sa pagbuwag ng koneksyon kaysa sa muling pag-deploy ng gateway.

Ang pag-alis na iyon ang pagkaantala, kaya ituring itong nakaplanong pagbabago na may simula at inaasahang wakas kaysa sa mabilis na pag-edit. Sa PowerShell ang pagkakasunod-sunod ay maikli: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, pagkatapos Set-AzLocalNetworkGateway gamit ang bagong -AddressPrefix array, pagkatapos New-AzVirtualNetworkGatewayConnection gamit ang parehong -SharedKey at parehong mga gateway. Mahalaga ang muling paggamit ng key, dahil hindi muling kino-configure ang malayong panig at ang bagong key ay nangangahulugan ng koordinasyon sa may-ari ng malayong device. Kung ibang team ang nagpapatakbo ng device na iyon, pagkasunduan ang window sa kanila bago ka mag-alis ng anuman.

Kailan kailangang muling itayo ang gateway mismo

Ang ikalawang sagot na umiikot sa problemang ito ay nagsasabing kailangang muling gawin ang gateway at muling ipagpalit ang key. Tama iyon para sa ibang hanay ng mga operasyon: pagbabago ng uri ng gateway o SKU, paglipat sa pagitan ng point-to-site at site-to-site, o pagkukumpuni ng gateway na mali ang sariling configuration. Binabago nga ng mga pagbabagong iyon ang gateway resource, kaya't tunay na kailangan ang muling pagtatayo.

Ang gateway na ginawa para sa point-to-site ay hindi basta mabibigyan ng site-to-site na koneksyon. Kailangang alisin ang point-to-site configuration at muling gawin ang gateway, na gumagawa rin ng bagong shared key at bagong client package.

Ang point-to-site package ay karapat-dapat sa sariling tala dahil nag-expire ito. Ang portal ay gumagawa ng file na may maikling buhay, kaya ang praktikal na paraan ay i-download ito nang isang beses at ipamahagi kasama ng client certificate kaysa magpadala sa mga user ng portal link na patay na sa oras na i-click nila. Para sa tanong ng prefix, wala sa mga ito ang naaangkop. Ang paghihiwalay ng dalawang pamamaraan ang buong disiplina: ang mga prefix ay pagbabago sa antas ng koneksyon, at ang mga katangian ng gateway ay pagbabago sa antas ng gateway.

Basahin ang estado, hindi ang badge ng portal

Basahin ang estado mula sa resource kaysa sa badge sa portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 ay nagbabalik ng ConnectionStatus kasama ang mga counter ng byte na pumapasok at lumalabas, at ang mga counter ang naghihiwalay ng tunnel na konektado at walang dinadala mula sa isa na hindi kailanman naitatag.

Ang mga counter na humihinto sa pagtaas sa gitna ng paglilipat ay tumuturo sa landas at hindi sa authentication. Ang mga counter na hindi gumagalaw ay tumuturo sa set ng prefix o sa shared key.

Ang mga timer ay nagpapaliwanag ng isang uri ng paghihiwalay na mali ang ibinabintang sa VPN. Isinasara ng load balancer ng Azure ang mga idle flow pagkatapos ng naka-configure na timeout, apat na minuto bilang default noong isinulat ang mga talang ito at maaaring itaas, kaya ang isang OpenVPN server sa VM na walang keepalive ay maaaring bumagsak tuwing ilang minuto habang ang lahat ng iba ay mukhang malusog. Ang gateway na pinaikot ng platform ay maaari ring makagambala sa koneksyon ng VNet sa isang Web App, at ang kabiguan ay nasa panig ng platform at hindi sa configuration ng client. Ang palatandaan ay kung ang paghihiwalay ay sumusunod sa isang takdang agwat o sa isang pagbabagong ginawa mo.

Itago ang tatlong object at ang kanilang mga halaga sa isang talaan: ang address space ng virtual network, ang listahan ng prefix ng lokal na network gateway, at ang reference sa shared key ng koneksyon. artikulong PowerShell para sa site-to-site ay nagdodokumento ng mga utos ng lokal na network gateway at ng pagkakasunod-sunod na dapat nilang sundin. Ang paghahambing ng pagbabago ng prefix sa memorya ang paraan kung paano muling itinatayo nang dalawang beses ang isang gumaganang tunnel.

Pagkatapos ay i-verify sa pagkakasunod-sunod na iyong binago: ipinapakita ng lokal na network gateway ang bagong listahan ng prefix, bumalik sa Connected ang koneksyon, at gumagalaw ang mga counter kapag nagpadala ka ng trapiko sa isang host sa bagong saklaw. Kung nabigo ang ikatlong hakbang habang pumasa ang unang dalawa, hindi pa tinatanggap ng malayong panig ang bagong tagapili ng trapiko at kailangan ng malayong device ang tugmang entry sa phase 2. Iyon ay pakikipag-usap sa kabilang dulo ng tunnel, hindi isa pang pagbabago sa Azure.