Bakit kailangan ng point-to-site ang ruta-based na Azure VPN gateway

Ang policy-based na gateway ay gumagawa ng IPsec tunnel na pinipili ng mga traffic selector, at wala itong interface na pagbibigyan ng mga ruta ng kliyente. Ang point-to-site ay isang tampok ng routing: nagmamay-ari ang gateway ng pool ng mga address ng kliyente at nag-i-install ng mga ruta patungo sa mga kliyenteng iyon sa virtual network. Ang mismatch na iyon ang dahilan kung bakit walang opsyon na ipinapakita ang portal para idagdag ito. Wala sa umiiral na gateway ang maaaring i-toggle upang mabuo ang interface, kaya ang pagbabago ay isang pagpapalit at hindi isang pag-edit ng configuration.

Mas mahalaga ang pagkakasunod-sunod kaysa sa mga indibidwal na hakbang. Kapag nagkamali ang sequence, lalampas sa maintenance window ang pagkaantala sa pagitan ng mga site.

Ano ang talagang ginagawa ng policy-based na gateway

Itinatapat ng policy-based na gateway ang mga packet sa mga traffic selector na naka-configure sa koneksyon at ipinapadala ang mga tugma sa isang tunnel. Walang tunnel interface na may address, at walang rutang bawat kliyente na lumilitaw kahit saan sa virtual network. Ang route table ay tumatanggap lamang ng mga lokal na prefix na tumuturo sa gateway. Sapat ang modelong iyon para sa koneksyon sa pagitan ng mga site sa pagitan ng dalawang fixed address space.

Ang ruta-based na gateway ay gumagana nang kabaligtaran: nagpapakita ito ng tunnel interface, at ang mga ruta ang nagpapasya kung ano ang papasok dito. Ang point-to-site, at anumang disenyo na nagbabago ang set ng mga peer, ay nakadepende sa pagkakaroon ng interface na iyon.

Bakit kailangan ng pool ng kliyente ang interface na iyon

Kapag kumonekta ang laptop, binibigyan ito ng gateway ng address mula sa point-to-site pool. Kailangan noon ng virtual network ang isang ruta na nagsasabing maaabot ang address na ito sa pamamagitan ng gateway. Kung walang tunnel interface, wala nang kakabitan ng rutang iyon.

Ang pool ay nagmumula sa isang saklaw na iyong itinatakda, at doon naglalaan ang gateway. Kung ang saklaw na iyon ay nagsasapawan sa lokal na network o sa isang peer na virtual network, lilitaw lamang ang salungatan pagkatapos kumonekta ng kliyente, na isang masamang sandali upang matuklasan ito. Ireserba ang pool bago magsimula ang migration.

Ang uri ay hindi rin setting para sa bawat koneksyon. Isang uri lang ang mayroon ang isang gateway, at bawat koneksyon na hawak nito ay kumikilos ayon doon, kaya ang magkahalong disenyo ay nangangailangan ng pangalawang gateway at hindi pangalawang koneksyon.

Ang uri ay nakatakda sa paglikha

Sinabi ng Microsoft na ang gateway ng virtual network ay hindi maaaring baguhin sa pagitan ng policy-based at ruta-based pagkatapos ng deployment. Walang command ng conversion at walang toggle sa portal. Ang paglikha ng pangalawang gateway sa parehong subnet ay hindi rin solusyon, dahil pinapayagan ng Azure ang isang gateway bawat virtual network. Kaya ang migration ay alisin, itayong muli, at kumonekta muli.

Isinasama rin nito ang desisyon sa SKU sa parehong pagtatayo. Ang paglipat sa mas malaking SKU mamaya ay isa pang pagpapalit ng gateway na may isa pang pagkaantala.

Isang gateway, isang GatewaySubnet

Nakatira ang gateway sa isang subnet na tinatawag na GatewaySubnet, at isang gateway lang ang sumasakop dito. Bahagi ng paghahanda ang pagtatakda ng laki ng subnet na iyon, dahil kailangan ng mas malaking SKU ng mas maraming address at hindi na maaaring bawasan ang subnet pagkatapos. Itala ang kasalukuyang setting sa pagitan ng mga site, ang shared key, ang local network gateway at ang mga epektibong ruta bago hawakan ang anuman. Pagkatapos ay ituring ang window bilang pagkaantala, dahil mananatiling down ang tunnel sa pagitan ng mga site hanggang ma-configure ang bagong koneksyon.

Isang pagkakasunod-sunod ng muling pagtatayo na naglilimita sa pagkaantala: gawin ang ruta-based na gateway, muling gawin ang koneksyon sa pagitan ng mga site sa parehong local network gateway, kumpirmahin ang tunnel at isang kahilingang host-to-host, at saka lamang idagdag ang point-to-site at gumawa ng bagong client package.

Ano ang hindi inaayos ng pagpapalit

Ang pangalawang limitasyon ay pag-aari ng peer at hindi ng Azure. Ang policy-based na lokal na device ay maaabot lamang ang virtual network na kinokonektahan nito, at hindi makakalampas patungo sa iba pang lokal na network o iba pang virtual network sa parehong gateway. Ang pagpapalit sa panig ng Azure ay hindi nagbabago sa kung ano ang maaaring piliin ng peer.

Kung ang pangangailangan ay talagang pagpasa sa pagitan ng mga site, ang sagot ay isang peer device na ruta-based o isang topolohiya kung saan nagtatapos nang hiwalay ang bawat destinasyon. Pagpasyahan iyon bago mangako ng petsa, dahil ang pagpapalit ng gateway lamang ay hindi magbibigay niyon.

Pagkakasunod-sunod ng mga operasyon at pagsusuri

I-verify ang bawat kakayahan nang hiwalay. Una ang status ng tunnel sa pagitan ng mga site at isang kahilingang host-to-host, pagkatapos ang koneksyong point-to-site at isang pribadong resource, pagkatapos ang anumang rutang pagpasa na inaangkin ng disenyo. Ang berdeng status ng gateway ay nagpapatunay lamang na bumangon ang security association, at wala nang iba. Panatilihin ang mga pagsusuri sa pagkakasunod-sunod na iyon upang ang pagkabigo ay tumuro sa yugtong nagpakilala nito.

Muling gumawa ng mga client package pagkatapos ng anumang pagbabago sa topolohiya, at ilayo ang pool sa bawat lokal at peer na saklaw. Ang mga limitasyon at pagkakaiba ng SKU ay nakalap sa reference ng mga setting ng Azure VPN Gateway.