Azure P2S VPN statiese IP: waarom die kliëntadres verander
Azure point-to-site gee by elke verbinding die volgende vry poeladres uit, so 'n vaste kliënt-IP bestaan nie. Sleutel toegang op reekse of identiteit eerder.
Elke Azure point-to-site-kliënt ontvang 'n adres uit die poel wanneer hy authentiseer, en hou dit net vir die duur van daardie verbinding. Daar is geen reserveringstabel nie, geen per-gebruiker-toewysing nie, en geen gateway-instelling wat beteken “gee altyd hierdie persoon 172.16.0.10” nie. Daardie enkele meganisme verklaar albei simptome wat mense later teëkom: 'n NSG-reël wat ophou om 'n gebruiker te pas wat dit vantevore gepas het, en 'n toelaatlys wat stilweg 'n masjien toelaat wat niemand opsetlik bygevoeg het nie. Om die reël met 'n slimmer IP-reël te vervang, regstel nie een van die twee nie, want die ding wat die reël noem, word op 'n skedule wat jy nie beheer nie, hertoegewys.
Die poel is kapasiteit, nie identiteit nie. Dit bestaan sodat gelyktydige tonnels unieke adresse kry, en dit herwin hulle die oomblik wanneer 'n huur eindig. Sodra dit duidelik is, hou die nuttige vraag op om “hoe pen ek hierdie kliënt vas” te wees en word dit “waarteen kan ek 'n reël skryf wat die gateway nie sal herwin nie”.
Wat die gateway werklik doen wanneer 'n kliënt verbind
Die gateway hou die gekonfigureerde kliëntadrespoel en behandel dit as 'n huurtabel. By verbinding neem dit die volgende vry adres, in die praktyk die laagste beskikbare, en ken dit aan die tonneladapter toe totdat die kliënt ontkoppel of die huur verstryk. Orde besluit, nie identiteit nie: wie ook al eerste weer verbind ná 'n stil tydperk, kry die laagste adres wat op daardie oomblik toevallig vry is.
Poelgrootte verberg die gedrag. 'n Laboratoriumpoel een of twee adresse groter as die aantal testers lyk deterministies, want dieselfde skootrekenaar is geneig om elke oggend in dieselfde orde weer te verbind. Voeg 'n derde masjien by, verander die poelgrootte, of laat 'n sessie oor middagete aangesluit bly, en die patroon breek. Die adres was nooit stabiel nie; die tou was.
Enige verandering aan die point-to-site-konfigurasie stel ook die huurruimte terug. 'n Ander tipe verifikasie, 'n herskalte poel, 'n nuwe poelreeks, of 'n gateway wat afgebreek en herbou word, stuur kliënte almal terug in 'n poel wat nie meer aan hul ou adresse koppel nie. Niks aan daardie verandering raak jou NSG nie, en daarom lyk die onderbreking spontaan.
Jy kan dit in omtrent 'n minuut sien gebeur. Verbind, let op die tonneladres in die kliënt se verbindingsbesonderhede, ontkoppel, verbind 'n tweede masjien, en verbind dan weer die eerste. Die adres wat jy terugkry, hang af van wat die tweede masjien vashet, en geen portaalinstelling sal die vorige een op aanvraag herstel nie.
NSG op die kliënt se IP is eintlik 'n reël oor verbindingsorde
Die reël wat mense eerste skryf, is die ooglopende een: 'n inkomende reël op die bestuurs-VM se NIC of op sy subnet, met die VPN-kliënt se interne adres as bron. Dit is kort, dit slaag die toets op die dag dat dit geskryf word, en dit faal sodra die poel meer as een vry adres het.
Twee faalmodusse volg, en net een van hulle lyk soos 'n fout. 'n Wettige gebruiker word geweier omdat iemand anders tans die adres hou wat die reël noem, wat as 'n irriterende ondersteuningskaartjie opduik. Of 'n onbedoelde gebruiker word toegelaat omdat hulle 'n adres geërf het wat die reël steeds vertrou, wat as niks opduik totdat iemand toegang oudit.
Omdat die reël die huur volg, lui die effektiewe beleid “die eerste persoon wat verbind, kry bestuurstoegang”. Dit is 'n beskrywing van verbindingsorde wat as bedoeling vermom is, en geen mate van reëlhigiëne laat dit bedoeling uitdruk nie.
Die kliënthuur en die gateway-adres is verskillende objekte
Die meeste verwarring kom van een woord. Die gateway het 'n openbare IP wat betreklik stabiel is; kliënte het private adresse uit die poel wat nie is nie. Vir 'n nie-sone-redundante VPN-gateway word die openbare IP dinamies toegeken, maar dit oorleef 'n herskaling, 'n herstel en roetine-instandhouding — dit verander wanneer die gateway self uitgevee en herbou word. Sone-redundante en sonale gateway-SKU's gebruik 'n openbare IP van die Standard-SKU, en daardie toekenning moet staties wees.
Daardie stabiliteit is wat 'n plaaslike eweknie in sy konfigurasie nodig het, en dit sê niks oor die identifisering van 'n individuele kliënt nie. Wanneer 'n vennoot vra watter adres hulle sal sien, is die antwoord die gateway se openbare IP onder site-to-site, of 'n gedeelde NAT-reeks — nooit 'n skootrekenaar se tonnelhuur nie.
Groepspoole gee jou 'n reeks wat die moeite werd is om reëls teen te skryf
Virtual WAN point-to-site ondersteun gebruikersgroepe, en elke groep kan sy eie kliëntadrespoel kry. Lidmaatskap word deur identiteit bepaal, so die reeks waarin 'n kliënt beland, word voorspelbaar: bedrywighede in een reeks, kontrakteurs in 'n ander, en die reeks is iets wat 'n firewall- of NSG-reël kan noem sonder om te raai.
Die resulterende reëlstel het 'n vorm wat jy kan hersien:
- een poel per gehoor, gegrootte vir piek gelyktydige sessies eerder as koppetelling;
- groepslidmaatskap deur identiteit hanteer, nie deur reëls te wysig elke keer as iemand aansluit nie;
- NSG- of Azure Firewall-reëls geskryf teen poelreekse, nooit teen individuele hure nie;
- 'n aparte hub of gateway vir gehore wat nooit 'n reeks mag deel nie.
| 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 |
Om 'n hele poel op die toelaatlys te sit, is eerlik maar grof: elke gekoppelde kliënt in daardie reeks kry dieselfde toegang. Dit is 'n beleidsbesluit wat die moeite werd is om hardop te sê eerder as om dit tydens 'n hersiening te ontdek. Enigiets wat steeds 'n antwoord per persoon nodig het, hoort by die hulpbron, deur roltoekennings, nie by die pakkietfilter nie.
Wanneer die ontplooiing nie na Virtual WAN kan skuif nie
Baie gateways bly gewone VPN-gateways, en om na Virtual WAN te skuif is nie 'n ligte verandering nie. Die praktiese antwoord is om die per-gebruiker-besluit van die pakkietfilter af te skuif na iets wat reeds weet wie die gebruiker is.
Identiteit op hulpbronvlak is die goedkoopste weergawe. Storage, SQL en Key Vault ondersteun almal Entra ID-verifikasie met roltoekennings per gebruiker of per groep, so die VPN hoef net netwerkbereikbaarheid te bewys. 'n Springgasheer met benoemde rekeninge doen dieselfde werk vir administratiewe werk, want die gasheer teken die mens aan en die tonnel dra net pakkies. Om kliënte in DNS te registreer en die naam eerder as die nommer op die toelaatlys te sit, skuif die reël een laag op. Identiteit op toepassingsvlak — 'n sertifikaatonderwerp, 'n token-eis, 'n groepslidmaatskap — werk wanneer die toepassing, nie die netwerk nie, die ding is wat gevra word om te besluit.
Vir 'n vennoot wat daarop aandring om 'n vaste bronadres, is die antwoord site-to-site of ExpressRoute met 'n bepaalde eweknie-voorvoegsel. Hulle sit die eweknie-voorvoegsel op die toelaatlys, die adres wat aan hul kant verskyn, behoort aan die gateway, en dit verander nie wanneer iemand 'n skootrekenaar herlaai nie.
Kontroleer die poel voordat jy nog 'n toelaatlys wysig
Twee poeleienskappe veroorsaak die meeste van die gedrag wat mense aan die kliënt toeskryf. 'n Poel wat te klein is, herwin huur vinnig, so adresse lyk of hulle voortdurend beweeg en enige adresgebaseerde reël lyk per ontwerp wankelrig. 'n Poel wat die plaaslike reekse of die virtuele netwerkruimte oorvleuel, skep roete-onsekerheid wat geen firewall-reël herstel nie.
Sit drie dinge op een bladsy voordat jy aan 'n reël raak: die point-to-site-poel, die virtuele netwerkadresruimte en die plaaslike reekse. Hulle mag nie oorvleuel nie, en die poel het ruimte nodig vir elke gelyktydige kliënt plus 'n marge vir herverbindings.
Sluit dan die lus in hierdie volgorde:
- Verbind van twee masjiene in albei ordes en vergelyk die adresse; as hulle kan omruil, is geen adresgebaseerde reël veilig nie.
- Kyk of die gateway Virtual WAN is; as dit is, gebruik groepspoole eerder as reëls per adres.
- Vra wat gebeur wanneer 'n reël die verkeerde persoon pas; as die antwoord 'n toegangsinsident is, skuif die beheer na identiteit.
- Teken aan watter reeks aan watter groep behoort, in dieselfde bewaarplek as die NSG-definisies.
- Her-toets ná enige poel-, verifikasie- of gateway-verandering, want daardie veranderinge herskryf die kartering sonder om dit aan te kondig.