IP estática en Azure P2S VPN: por que cambia o enderezo do cliente

Cada cliente de Azure point-to-site recibe un enderezo do grupo cando se autentica, e consérvao só mentres dura esa conexión. Non hai táboa de reservas, nin asignación por usuario, nin axuste de pasarela que signifique «dálle sempre 172.16.0.10 a esta persoa». Ese único mecanismo explica os dous síntomas cos que a xente se atopa máis adiante: unha regra de NSG que deixa de coincidir cun usuario co que antes coincidía, e unha lista de permitidos que admite en silencio unha máquina que ninguén engadiu a propósito. Substituír a regra por unha regra IP máis enxeñosa non arranxa ningunha das dúas cousas, porque o que a regra nomea reasignase segundo un calendario que vostede non controla.

O grupo é capacidade, non identidade. Existe para que os túneles simultáneos obtivesen enderezos únicos, e recíclaos no momento en que remata un arrendamento. Cando iso queda claro, a pregunta útil deixa de ser «como fixo este cliente» e pasa a ser «contra que podo escribir unha regra que a pasarela non recicle».

Que fai realmente a pasarela cando un cliente se conecta

A pasarela mantén o grupo de enderezos de cliente configurado e trátao como unha táboa de arrendamentos. Ao conectar toma o seguinte enderezo libre, na práctica o máis baixo dispoñible, e asígnao ao adaptador do túnel ata que o cliente se desconecta ou o arrendamento caduca. Decide a orde, non a identidade: quen se reconecta primeiro tras un período de calma leva o enderezo máis baixo que resulte libre nese momento.

O tamaño do grupo oculta o comportamento. Un grupo de laboratorio un ou dous enderezos maior que o número de probadores parece determinista, porque o mesmo portátil tende a reconectarse na mesma orde cada mañá. Engada unha terceira máquina, cambie o tamaño do grupo ou deixe unha sesión conectada durante a comida, e o patrón rompe. O enderezo nunca foi estable; a cola si.

Calquera cambio na configuración point-to-site tamén reinicia o espazo de arrendamentos. Un tipo de autenticación distinto, un grupo redimensionado, un novo rango de grupo ou unha pasarela que se derruba e se reconstrúe envían os clientes a un grupo que xa non se corresponde cos seus enderezos antigos. Nada dese cambio toca o seu NSG, e por iso a avaría parece espontánea.

Pode velo ocorrer en aproximadamente un minuto. Conéctese, anote o enderezo do túnel nos detalles de conexión do cliente, desconéctese, conecte unha segunda máquina e volva conectar a primeira. O enderezo que recupera depende do que teña a segunda máquina, e ningún axuste do portal restaurará o anterior a demanda.

Un NSG baseado na IP do cliente é en realidade unha regra sobre a orde de conexión

A regra que a xente escribe primeiro é a obvia: unha regra de entrada na NIC da VM de administración ou na súa subrede, co enderezo interno do cliente VPN como orixe. É curta, pasa a proba o día que se escribe e falla en canto o grupo ten máis dun enderezo libre.

De aí xorden dous modos de fallo, e só un parece un erro. A un usuario lexítimo denegóuselle porque outra persoa ten nese momento o enderezo que a regra nomea, o que chega como unha incidencia de soporte molesta. Ou a un usuario non previsto permítese porque herdou un enderezo no que a regra aínda confía, o que non chega como nada ata que alguén audita o acceso.

Como a regra segue o arrendamento, a política efectiva di «a primeira persoa que se conecta obtén acceso de administración». Iso é unha descrición da orde de conexión disfrazada de intención, e ningunha hixiene de regras a fai expresar intención.

O arrendamento do cliente e o enderezo da pasarela son obxectos distintos

A maior parte da confusión vén dunha palabra. A pasarela ten unha IP pública comparativamente estable; os clientes teñen enderezos privados do grupo que non o son. Para unha pasarela VPN non redundante por zonas, a IP pública asígnase dinamicamente, pero sobrevive a un cambio de tamaño, a un reinicio e ao mantemento rutineiro: cambia cando a propia pasarela se elimina e se volve crear. As SKU de pasarela redundantes por zonas e zonais usan unha IP pública de SKU Standard, e esa asignación ten que ser estática.

Esa estabilidade é o que un par local necesita na súa configuración, e non di nada sobre identificar un cliente individual. Cando un socio pregunta que enderezo verá, a resposta é a IP pública da pasarela en site-to-site, ou un rango NAT compartido: nunca o arrendamento do túnel dun portátil.

Os grupos de pool danlle un rango contra o que paga a pena escribir regras

Virtual WAN point-to-site admite grupos de usuarios, e a cada grupo pódeselle asignar o seu propio grupo de enderezos de cliente. A pertenza decídese por identidade, así que o rango no que cae un cliente vólvese previsible: operacións nun rango, contratistas noutro, e o rango é algo que unha regra de firewall ou de NSG pode nomear sen adiviñar.

O conxunto de regras resultante ten unha forma que pode revisar:

• un grupo por audiencia, dimensionado para picos de sesións simultáneas e non por número de persoas;
• a pertenza ao grupo xestiónase por identidade, non editando regras cada vez que alguén se incorpora;
• regras de NSG ou de Azure Firewall escritas contra rangos de grupo, nunca contra arrendamentos individuais;
• un concentrador ou unha pasarela separados para audiencias que nunca deben compartir un rango.

Pór un grupo enteiro na lista de permitidos é honesto pero groso: cada cliente conectado nese rango obtén o mesmo acceso. É unha decisión de política que merece dicirse en voz alta en lugar de descubrirse durante unha revisión. Todo o que aínda necesite unha resposta por persoa pertence ao recurso, mediante asignacións de rol, non ao filtro de paquetes.

Cando o despregamento non pode pasar a Virtual WAN

Moitas pasarelas seguen sendo pasarelas VPN simples, e pasar a Virtual WAN non é un cambio trivial. A resposta práctica é mover a decisión por usuario do filtro de paquetes a algo que xa saiba quen é o usuario.

A identidade a nivel de recurso é a versión máis barata. Storage, SQL e Key Vault admiten todos autenticación de Entra ID con asignacións de rol por usuario ou por grupo, así que a VPN só ten que demostrar alcance de rede. Un host de salto con contas nominais fai o mesmo traballo para tarefas administrativas, porque o host rexistra a persoa e o túnel só transporta paquetes. Rexistrar os clientes en DNS e permitir o nome en lugar do número sobe a regra un nivel. A identidade de capa de aplicación — un suxeito de certificado, unha declaración de token, unha pertenza a grupo — funciona cando o que debe decidir é a aplicación, non a rede.

Para un socio que insiste nun enderezo de orixe fixo, a resposta é site-to-site ou ExpressRoute cun prefixo de par definido. Eles permiten o prefixo de par, o enderezo que aparece no seu lado pertence á pasarela e non cambia cando alguén reinicia un portátil.

Revise o grupo antes de editar outra lista de permitidos

Dúas propiedades do grupo causan a maior parte do comportamento que a xente achaca ao cliente. Un grupo demasiado pequeno recicla arrendamentos con rapidez, así que os enderezos parecen moverse constantemente e calquera regra baseada en enderezo parece inestable por deseño. Un grupo que se solapa cos rangos locais ou co espazo da rede virtual crea unha ambigüidade de encamiñamento que ningunha regra de firewall repara.

Poña tres cousas nunha páxina antes de tocar unha regra: o grupo point-to-site, o espazo de enderezos da rede virtual e os rangos locais. Non deben solaparse, e o grupo necesita sitio para cada cliente simultáneo máis un marxe para reconexións.

Despois peche o ciclo nesta orde:

• Conéctese desde dúas máquinas en ambas as ordes e compare os enderezos; se poden intercambiarse, ningunha regra baseada en enderezo é segura.
• Comprobe se a pasarela é de Virtual WAN; se o é, use grupos de pool en lugar de regras por enderezo.
• Pergunte que ocorre cando unha regra acerta a persoa equivocada; se a resposta é un incidente de acceso, mova o control á identidade.
• Rexistre que rango pertence a que grupo no mesmo repositorio que as definicións de NSG.
• Volva probar tras calquera cambio de grupo, autenticación ou pasarela, porque eses cambios reescriben a asignación sen anunciarlo.