IP estàtica a Azure P2S VPN: per què canvia l'adreça del client
Azure point-to-site lliura la següent adreça lliure del pool a cada connexió, així que no existeix una IP fixa del client. Basa l'accés en rangs o en la identitat.
Cada client d'Azure point-to-site rep una adreça del pool quan s'autentica, i la conserva només mentre dura aquella connexió. No hi ha taula de reserves, ni mapatge per usuari, ni cap paràmetre del gateway que signifiqui «dona sempre 172.16.0.10 a aquesta persona». Aquest únic mecanisme explica els dos símptomes amb què la gent es troba més endavant: una regla NSG que deixa de coincidir amb un usuari amb qui abans coincidia, i una llista d'autoritzacions que admet en silenci una màquina que ningú no hi va afegir a propòsit. Substituir la regla per una regla IP més enginyosa no arregla cap de les dues coses, perquè allò que la regla anomena es reassigna segons un calendari que no controles.
El pool és capacitat, no identitat. Existeix perquè els túnels concurrents obtinguin adreces úniques, i les recicla en el moment que acaba un arrendament. Un cop això és clar, la pregunta útil deixa de ser «com fixo aquest client» i passa a ser «contra què puc escriure una regla que el gateway no reciclarà».
Què fa realment el gateway quan un client es connecta
El gateway conserva el pool d'adreces de client configurat i el tracta com una taula d'arrendaments. En connectar-se, agafa la següent adreça lliure, a la pràctica la més baixa disponible, i l'assigna a l'adaptador del túnel fins que el client es desconnecta o l'arrendament venç. Decideix l'ordre, no la identitat: qui es reconnecta primer després d'un període de calma obté l'adreça més baixa que en aquell moment resulta lliure.
La mida del pool amaga el comportament. Un pool de laboratori una o dues adreces més gran que el nombre de provadors sembla determinista, perquè el mateix portàtil tendeix a reconnectar-se en el mateix ordre cada matí. Afegeix una tercera màquina, canvia la mida del pool o deixa una sessió connectada durant el dinar, i el patró es trenca. L'adreça mai no va ser estable; la cua sí.
Qualsevol canvi en la configuració point-to-site també reinicia l'espai d'arrendaments. Un tipus d'autenticació diferent, un pool redimensionat, un nou rang de pool o un gateway que es desmunta i es torna a construir envien els clients a un pool que ja no es correspon amb les seves adreces antigues. Res d'aquell canvi no toca la teva NSG, i per això l'avaria sembla espontània.
Ho pots veure en cosa d'un minut. Connecta't, anota l'adreça del túnel als detalls de connexió del client, desconnecta't, connecta una segona màquina i torna a connectar la primera. L'adreça que recuperes depèn del que tingui la segona màquina, i cap paràmetre del portal no restaurarà l'anterior a demanda.
Una NSG basada en la IP del client és en realitat una regla sobre l'ordre de connexió
La regla que la gent escriu primer és l'obvia: una regla d'entrada a la NIC de la VM de gestió o a la seva subxarxa, amb l'adreça interna del client VPN com a origen. És curta, passa la prova el dia que s'escriu i falla tan bon punt el pool té més d'una adreça lliure.
Se'n deriven dues maneres de fallar, i només una sembla un error. Un usuari legítim és denegat perquè algú altre té en aquell moment l'adreça que la regla anomena, cosa que arriba com una molesta incidència de suport. O un usuari no previst és admès perquè ha heretat una adreça en què la regla encara confia, cosa que no arriba com res fins que algú audita l'accés.
Com que la regla segueix l'arrendament, la política efectiva diu «la primera persona que es connecta obté accés de gestió». Això és una descripció de l'ordre de connexió disfressada d'intenció, i cap higiene de regles no la fa expressar intenció.
L'arrendament del client i l'adreça del gateway són objectes diferents
La major part de la confusió ve d'una paraula. El gateway té una IP pública comparativament estable; els clients tenen adreces privades del pool que no ho són. Per a un gateway VPN no redundant per zones, la IP pública s'assigna dinàmicament, però sobreviu a un canvi de mida, a un reinici i al manteniment rutinari — canvia quan el gateway mateix s'elimina i es torna a crear. Les SKU de gateway redundants per zones i zonals fan servir una IP pública de SKU Standard, i aquesta assignació ha de ser estàtica.
Aquesta estabilitat és el que un peer local necessita a la seva configuració, i no diu res sobre identificar un client individual. Quan un soci pregunta quina adreça veurà, la resposta és la IP pública del gateway en site-to-site, o un rang NAT compartit — mai l'arrendament del túnel d'un portàtil.
Els pools de grup et donen un rang contra el qual val la pena escriure regles
Virtual WAN point-to-site admet grups d'usuaris, i a cada grup se li pot assignar el seu propi pool d'adreces de client. La pertinença es decideix per identitat, així que el rang on cau un client es torna predictible: operacions en un rang, contractistes en un altre, i el rang és una cosa que una regla de firewall o NSG pot anomenar sense endevinar.
El conjunt de regles resultant té una forma que pots revisar:
- un pool per audiència, dimensionat per a pics de sessions concurrents i no pel nombre de persones;
- la pertinença al grup es gestiona per identitat, no editant regles cada vegada que algú s'hi uneix;
- regles NSG o d'Azure Firewall escrites contra rangs de pool, mai contra arrendaments individuals;
- un hub o gateway separat per a audiències que no han de compartir mai un rang.
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
Posar un pool sencer a la llista d'autoritzacions és honest però groller: cada client connectat en aquell rang obté el mateix accés. És una decisió de política que val la pena dir en veu alta en comptes de descobrir durant una revisió. Tot allò que encara necessiti una resposta per persona pertany al recurs, mitjançant assignacions de rol, no al filtre de paquets.
Quan el desplegament no pot passar a Virtual WAN
Molts gateways es queden com a gateways VPN simples, i passar a Virtual WAN no és un canvi trivial. La resposta pràctica és moure la decisió per usuari del filtre de paquets a una cosa que ja sàpiga qui és l'usuari.
La identitat a nivell de recurs és la versió més barata. Storage, SQL i Key Vault admeten tots autenticació d'Entra ID amb assignacions de rol per usuari o per grup, així que la VPN només ha de demostrar abast de xarxa. Un jump host amb comptes nominals fa la mateixa feina per a tasques administratives, perquè l'host enregistra la persona i el túnel només transporta paquets. Registrar els clients al DNS i posar el nom en lloc del número a la llista d'autoritzacions puja la regla un nivell. La identitat de capa d'aplicació — un subjecte de certificat, una declaració de testimoni, una pertinença a grup — funciona quan allò a qui es demana decidir és l'aplicació, no la xarxa.
Per a un soci que insisteix en una adreça d'origen fixa, la resposta és site-to-site o ExpressRoute amb un prefix de peer definit. Ells posen el prefix de peer a la llista d'autoritzacions, l'adreça que apareix al seu costat pertany al gateway i no canvia quan algú reinicia un portàtil.
Comprova el pool abans d'editar una altra llista d'autoritzacions
Dues propietats del pool causen la major part del comportament que la gent atribueix al client. Un pool massa petit recicla arrendaments de pressa, així que les adreces semblen moure's constantment i qualsevol regla basada en adreça sembla inestable per disseny. Un pool que se superposa amb els rangs locals o amb l'espai de la xarxa virtual crea una ambigüitat d'encaminament que cap regla de firewall no arregla.
Posa tres coses en una pàgina abans de tocar cap regla: el pool point-to-site, l'espai d'adreces de la xarxa virtual i els rangs locals. No s'han de superposar, i el pool necessita lloc per a cada client simultani més un marge per a reconnexions.
Després tanca el bucle en aquest ordre:
- Connecta't des de dues màquines en tots dos ordres i compara les adreces; si es poden intercanviar, cap regla basada en adreça no és segura.
- Comprova si el gateway és de Virtual WAN; si ho és, fes servir pools de grup en lloc de regles per adreça.
- Pregunta què passa quan una regla encerta la persona equivocada; si la resposta és un incident d'accés, mou el control a la identitat.
- Enregistra quin rang pertany a quin grup al mateix repositori que les definicions de NSG.
- Torna a provar després de qualsevol canvi de pool, autenticació o gateway, perquè aquests canvis reescriuen el mapatge sense anunciar-ho.