Static na IP sa Azure P2S VPN: bakit nagbabago ang address ng client

Ang bawat client ng Azure point-to-site ay tumatanggap ng address mula sa pool kapag nag-authenticate, at pinapanatili lamang ito habang tumatagal ang koneksyong iyon. Walang talahanayan ng reserbasyon, walang mapping kada user, at walang setting ng gateway na nangangahulugang „bigyan lagi ang taong ito ng 172.16.0.10“. Ang nag-iisang mekanismong ito ang nagpapaliwanag sa dalawang sintomas na nararanasan ng mga tao mamaya: isang tuntunin ng NSG na hindi na tumutugma sa isang user na dati nitong tinutugma, at isang listahan ng pinapayagan na tahimik na tumatanggap ng makina na walang sadyang nagdagdag. Ang pagpapalit ng tuntunin ng mas matalinong tuntunin sa IP ay hindi nag-aayos ng alinman, dahil ang tinutukoy ng tuntunin ay muling itinatalaga ayon sa iskedyul na hindi mo kontrolado.

Ang pool ay kapasidad, hindi pagkakakilanlan. Umiiral ito upang ang mga sabay-sabay na tunnel ay makakuha ng natatanging address, at ginagamit muli ang mga ito sa sandaling matapos ang isang lease. Kapag malinaw na iyon, ang kapaki-pakinabang na tanong ay hindi na „paano ko ipi-pin ang client na ito“ at nagiging „laban sa ano ako makakasulat ng tuntuning hindi gagamitin muli ng gateway“.

Ano ang aktwal na ginagawa ng gateway kapag kumonekta ang client

Hinihawak ng gateway ang naka-configure na pool ng address ng client at tinatrato ito bilang talahanayan ng lease. Sa pagkonekta, kinukuha nito ang susunod na libreng address, sa pagsasagawa ang pinakamababang available, at itinatalaga ito sa tunnel adapter hanggang madiskonekta ang client o matapos ang lease. Ang pagkakasunod-sunod ang nagpapasya, hindi ang pagkakakilanlan: sinumang unang muling kumonekta pagkatapos ng tahimik na panahon ay makakakuha ng pinakamababang address na nagkataong libre sa sandaling iyon.

Itinatago ng laki ng pool ang pag-uugali. Ang pool ng laboratoryo na isa o dalawang address na mas malaki kaysa bilang ng mga tester ay mukhang deterministiko, dahil ang parehong laptop ay may tendensiyang muling kumonekta sa parehong pagkakasunod-sunod tuwing umaga. Magdagdag ng ikatlong makina, baguhin ang laki ng pool, o hayaang nakakonekta ang isang session sa tanghalian, at nasisira ang pattern. Ang address ay hindi kailanman naging matatag; ang pila ang matatag.

Anumang pagbabago sa configuration ng point-to-site ay nagre-reset din ng espasyo ng lease. Ibang uri ng authentication, pool na binago ang laki, bagong range ng pool, o gateway na giniba at itinayong muli — lahat sila ay nagpapabalik sa mga client sa pool na hindi na tumutugma sa dati nilang address. Wala sa pagbabagong iyon ang humahawak sa NSG mo, kaya ang sira ay mukhang kusang nangyari.

Makikita mo itong mangyari sa mga isang minuto. Kumonekta, itala ang address ng tunnel sa mga detalye ng koneksyon ng client, dumiskonekta, ikonekta ang pangalawang makina, at muling ikonekta ang una. Ang address na makukuha mo pabalik ay depende sa hawak ng pangalawang makina, at walang setting ng portal ang magbabalik ng nauna kapag hiniling.

Ang NSG na nakabatay sa IP ng client ay talagang isang tuntunin tungkol sa pagkakasunod-sunod ng koneksyon

Ang tuntuning unang isinusulat ng mga tao ay ang halata: isang inbound na tuntunin sa NIC ng management VM o sa subnet nito, na may panloob na address ng VPN client bilang pinagmulan. Maikli ito, pumapasa sa pagsubok sa araw na isinulat, at nabibigo sa sandaling may higit sa isang libreng address ang pool.

Dalawang paraan ng pagpalya ang nagmumula roon, at isa lamang ang mukhang bug. Ang isang lehitimong user ay tinatanggihan dahil may ibang humahawak sa address na tinutukoy ng tuntunin sa sandaling iyon, at dumarating iyon bilang nakakainis na support ticket. O ang isang hindi sinasadyang user ay pinapasok dahil namana niya ang address na pinagkakatiwalaan pa ng tuntunin, at hindi iyon dumarating bilang anuman hanggang may mag-audit ng access.

Dahil sinusundan ng tuntunin ang lease, ang epektibong patakaran ay mababasa na „ang unang taong kumonekta ay makakakuha ng access sa management“. Iyon ay paglalarawan ng pagkakasunod-sunod ng koneksyon na nakadamit bilang intensyon, at walang kalinisan ng tuntunin ang gumagawa nitong pagpapahayag ng intensyon.

Ang lease ng client at ang address ng gateway ay magkaibang bagay

Karamihan ng pagkalito ay nagmumula sa isang salita. Ang gateway ay may pampublikong IP na medyo matatag; ang mga client ay may pribadong address mula sa pool na hindi matatag. Para sa gateway ng VPN na hindi zone-redundant, ang pampublikong IP ay inilalaan nang dinamiko, ngunit nakakaligtas ito sa pagbabago ng laki, reset, at regular na maintenance — nagbabago ito kapag ang gateway mismo ay tinanggal at muling ginawa. Ang zone-redundant at zonal na SKU ng gateway ay gumagamit ng pampublikong IP ng Standard SKU, at ang paglalaang iyon ay dapat static.

Ang katatagang iyon ang kailangan ng on-premises na peer sa configuration nito, at wala itong sinasabi tungkol sa pagkilala sa isang indibidwal na client. Kapag nagtanong ang partner kung anong address ang makikita nila, ang sagot ay ang pampublikong IP ng gateway sa site-to-site, o isang shared NAT range — hindi kailanman ang tunnel lease ng laptop.

Ang mga pool ng grupo ay nagbibigay sa iyo ng range na sulit pagsulatan ng tuntunin

Sinusuportahan ng Virtual WAN point-to-site ang mga grupo ng user, at ang bawat grupo ay maaaring bigyan ng sarili nitong pool ng address ng client. Ang pagiging miyembro ay pinagpapasyahan ng pagkakakilanlan, kaya ang range na hinuhulugan ng client ay nagiging mahulaan: operations sa isang range, contractors sa isa pa, at ang range ay isang bagay na maaaring pangalanan ng firewall o NSG na tuntunin nang walang hinala.

Ang resultang set ng tuntunin ay may hugis na maaari mong suriin:

• isang pool bawat audience, sinukat sa pinakamataas na sabay-sabay na session at hindi sa bilang ng tao;
• ang pagiging miyembro ng grupo ay pinangangasiwaan sa pamamagitan ng pagkakakilanlan, hindi sa pag-edit ng tuntunin tuwing may sasali;
• ang mga tuntunin ng NSG o Azure Firewall ay isinusulat laban sa mga range ng pool, hindi kailanman laban sa indibidwal na lease;
• hiwalay na hub o gateway para sa mga audience na hindi dapat kailanman maghati ng range.

Ang paglalagay ng buong pool sa listahan ng pinapayagan ay tapat ngunit magaspang: bawat nakakonektang client sa range na iyon ay makakakuha ng parehong access. Iyon ay desisyon sa patakaran na dapat sabihin nang malakas sa halip na matuklasan sa isang review. Anumang bagay na kailangan pa ng sagot kada tao ay pag-aari ng resource sa pamamagitan ng role assignments, hindi ng packet filter.

Kapag hindi makalipat ang deployment sa Virtual WAN

Maraming gateway ay nananatiling ordinaryong gateway ng VPN, at ang paglipat sa Virtual WAN ay hindi basta-bastang pagbabago. Ang praktikal na sagot ay ilipat ang desisyon kada user mula sa packet filter patungo sa isang bagay na alam na kung sino ang user.

Ang pagkakakilanlan sa antas ng resource ang pinakamurang bersyon. Storage, SQL, at Key Vault ay sinusuportahan ang authentication ng Entra ID na may role assignments kada user o kada grupo, kaya kailangan lamang patunayan ng VPN ang maabot ng network. Ang jump host na may mga nakapangalan na account ay gumagawa ng parehong trabaho para sa administratibong gawain, dahil itinatala ng host ang tao at ang tunnel ay nagdadala lamang ng packet. Ang pagrerehistro ng client sa DNS at pagpayag sa pangalan sa halip na numero ay nagtataas ng tuntunin ng isang antas. Ang pagkakakilanlan sa antas ng application — subject ng certificate, claim ng token, pagiging miyembro ng grupo — ay gumagana kapag ang aplikasyon, hindi ang network, ang hinihiling na magpasya.

Para sa partner na nagpipilit ng fixed na source address, ang sagot ay site-to-site o ExpressRoute na may tinukoy na peer prefix. Pinapayagan nila ang peer prefix, ang address na lumalabas sa kanilang panig ay pag-aari ng gateway, at hindi ito nagbabago kapag may nag-restart ng laptop.

Suriin ang pool bago mag-edit ng isa pang listahan ng pinapayagan

Dalawang katangian ng pool ang nagdudulot ng karamihan ng pag-uugaling ibinabaling ng mga tao sa client. Ang pool na masyadong maliit ay mabilis na gumagamit muli ng lease, kaya ang mga address ay tila laging gumagalaw at ang anumang tuntuning nakabatay sa address ay mukhang hindi matatag mula sa disenyo. Ang pool na nagsasapawan sa mga on-premises na range o sa espasyo ng address ng virtual network ay lumilikha ng kalabuan sa routing na hindi naaayos ng anumang tuntunin ng firewall.

Maglagay ng tatlong bagay sa isang pahina bago hawakan ang tuntunin: ang pool ng point-to-site, ang espasyo ng address ng virtual network, at ang mga on-premises na range. Hindi sila dapat magsapawan, at ang pool ay kailangan ng espasyo para sa bawat sabay-sabay na client at ng margin para sa muling pagkonekta.

Pagkatapos, isara ang loop sa ganitong pagkakasunod-sunod:

• Kumonekta mula sa dalawang makina sa parehong pagkakasunod-sunod at ihambing ang mga address; kung maaari silang magpalitan, walang tuntuning nakabatay sa address ang ligtas.
• Suriin kung ang gateway ay Virtual WAN; kung oo, gumamit ng mga pool ng grupo sa halip na tuntunin kada address.
• Itanong kung ano ang nangyayari kapag ang isang tuntunin ay tumama sa maling tao; kung ang sagot ay insidente sa access, ilipat ang kontrol sa pagkakakilanlan.
• Itala kung aling range ang pag-aari ng aling grupo sa parehong repository tulad ng mga depinisyon ng NSG.
• Muling subukan pagkatapos ng anumang pagbabago sa pool, authentication, o gateway, dahil ang mga pagbabagong iyon ay muling nagsusulat ng mapping nang hindi nagpapahayag.