IP estatikoa Azure P2S VPN-n: zergatik aldatzen den bezeroaren helbidea
Azure point-to-site-ek hurrengo pool helbide librea ematen du konexio bakoitzean, beraz ez dago bezeroaren IP finkorik. Oinarritu sarbidea barrutietan edo identitatean.
Azure point-to-site bezero bakoitzak pool-etik helbide bat jasotzen du autentifikatzen denean, eta konexio horren iraupenaren artean baino ez du gordetzen. Ez dago erreserba-taularik, ez dago erabiltzaileko mapaketarik, eta ez dago “eman beti pertsona honi 172.16.0.10” esan nahi duen gateway ezarpenik. Mekanismo bakar horrek azaltzen ditu geroago jendeak aurkitzen dituen bi sintomak: aurretik bat zetorren erabiltzaile batekin bat ez datorren NSG araua, eta inork nahita gehitu ez zuen makina bat isilka onartzen duen baimen-zerrenda. Araua IP arau argiago batekin ordezkatzeak ez du bat ere konpontzen, arauak izendatzen duen gauza kontrolatzen ez duzun egutegi baten arabera esleitzen delako.
Poola ahalmena da, ez identitatea. Tunel aldi berekoek helbide bakarrak izan ditzaten existitzen da, eta alokairua amaitzen den unean birziklatzen ditu. Hori argi dagoenean, galdera erabilgarria ez da “nola finkatu bezero hau” izateari uzten eta “zeren aurka idatz dezaket gateway-ak birziklatuko ez duen arau bat” bihurtzen da.
Zer egiten duen gateway-ak bezero bat konektatzen denean
Gateway-ak konfiguratutako bezero helbide pool-a gordetzen du eta alokairu-taulatzat hartzen du. Konektatzean hurrengo helbide librea hartzen du, praktikan eskuragarri dagoen baxuena, eta tunel egokitzaileari esleitzen dio bezeroa deskonektatu edo alokairua iraungi arte. Ordenak erabakitzen du, ez identitateak: isilaldia ondoren lehenengo berriz konektatzen denak une horretan kasualitatez libre dagoen helbide baxuena hartzen du.
Poolaren tamainak jokabidea ezkutatzen du. Probatzaileen kopurua baino helbide bat edo bi handiagoa den laborategiko pool-a deterministatzat jotzen da, ordenagailu eramangarri berak goizero ordena berean berriz konektatzeko joera duelako. Gehitu hirugarren makina bat, aldatu poolaren tamaina edo utzi saio bat bazkalorduan zehar konektatuta, eta eredua apurtu egiten da. Helbidea ez zen inoiz egonkorra izan; ilara zen.
Point-to-site konfigurazioko edozein aldaketak alokairu-espazioa ere berrezartzen du. Autentifikazio mota ezberdina, pool tamaina aldatua, pool barruti berria edo eraitsi eta berreraikitako gateway bat: guztiek bezeroak beren helbide zaharrekin bat ez datorren pool batera bidaltzen dituzte. Aldaketa horretan ezerk ez dio zure NSG-ari ukitzen, horregatik haustura espontaneoa dirudi.
Minutu batean ikus dezakezu. Konektatu, idatzi tunelaren helbidea bezeroaren konexio-xehetasunetan, deskonektatu, konektatu bigarren makina bat, eta gero berriz konektatu lehenengoa. Itzultzen zaizun helbidea bigarren makinak zer duen araberakoa da, eta portaleko ezarpen batek ere ez du aurrekoa eskaeran berrezarriko.
Bezeroaren IP-n oinarritutako NSG bat konexio-ordenari buruzko araua da, funtsean
Jendeak lehenengo idazten duen araua begi-bistakoa da: sarrera-arau bat kudeaketa VM-aren NIC-ean edo haren azpisarearean, iturri gisa VPN bezeroaren barne helbidea hartuta. Laburra da, idazten den egunean proba gainditzen du, eta poolak helbide libre bat baino gehiago dituenean huts egiten du.
Hortik bi hutsegite modu datoz, eta horietako batek bakarrik dirudi errore. Erabiltzaile legitimo bat ukatzen zaio arauak izendatzen duen helbidea une horretan beste norbaitek duelako, eta hori laguntza-txartel gogaikarri gisa iristen da. Edo nahi gabeko erabiltzaile bat onartzen da arauak oraindik fidatzen duen helbide bat heredatu duelako, eta hori ez da ezer gisa iristen norbaitek sarbidea auditatu arte.
Arauak alokairua jarraitzen duenez, politika eraginkorrak hau dio: “lehenengo konektatzen denak kudeaketa-sarbidea lortzen du”. Hori konexio-ordenaren deskribapena da, asmo gisa mozorrotuta, eta arauen higieneak ere ez du asmoa adierazten uzten.
Bezeroaren alokairua eta gateway-aren helbidea objektu ezberdinak dira
Nahasmendu gehiena hitz batetik dator. Gateway-ak IP publiko nahiko egonkorra du; bezeroek pool-etik datozen helbide pribatuak dituzte, eta horiek ez dira egonkorrak. Zona-erredundantea ez den VPN gateway baterako IP publikoa modu dinamikoan esleitzen da, baina tamaina-aldaketa, berrezarpena eta ohiko mantentze-lanak gainditzen ditu: gateway-a bera ezabatu eta berreraikitzean aldatzen da. Zona-erredundanteak eta zonalak diren gateway SKU-ek Standard SKU-ko IP publikoa erabiltzen dute, eta esleipen horrek estatikoa izan behar du.
Egonkortasun hori da tokiko pare batek bere konfigurazioan behar duena, eta ez du ezer esaten bezero indibidual bat identifikatzeaz. Bazkide batek zein helbide ikusiko duen galdetzen duenean, erantzuna gateway-aren IP publikoa da site-to-site pean, edo NAT barruti partekatu bat: inoiz ez ordenagailu eramangarri baten tunel-alokairua.
Talde-pool-ek arauak idazteko balio duen barruti bat ematen dizute
Virtual WAN point-to-site-k erabiltzaile-taldeak onartzen ditu, eta talde bakoitzari bere bezero helbide pool-a eslei dakioke. Parte-hartzea identitatearen arabera erabakitzen da, beraz bezeroa erortzen den barrutia aurreikusteko modukoa bihurtzen da: eragiketak barruti batean, kontratistak bestean, eta barrutia suebaki edo NSG arau batek asmatu gabe izenda dezakeen zerbait da.
Emaitzazko arau-multzoak berrikus dezakezun forma du:
- publiko bakoitzeko pool bat, aldi bereko saioen gailurrerako dimentsionatua, eta ez buru-kopuruaren arabera;
- taldeko partaidetza identitatearen bidez kudeatzen da, eta ez norbait sartzen den bakoitzean arauak editatuz;
- NSG edo Azure Firewall arauak pool barrutien aurka idatzita, inoiz ez alokairu indibidualen aurka;
- inoiz barruti bat partekatu behar ez duten publikoentzako hub edo gateway bereizi bat.
| 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 |
Pool oso bat baimen-zerrendan jartzea zintzoa da baina zakarra: barruti horretako konektatutako bezero bakoitzak sarbide bera lortzen du. Berrikuspen batean aurkitu beharrean ozen esateko moduko politika-erabakia da. Pertsonako erantzun bat oraindik behar duen edozer baliabidera dagokio, rol-esleipenen bidez, ez pakete-iragazkira.
Inplementazioa Virtual WAN-era pasa ezin denean
Gateway asko VPN gateway hutsak izaten jarraitzen dute, eta Virtual WAN-era pasatzea ez da aldaketa hutsala. Erantzun praktikoa erabiltzaileko erabakia pakete-iragazkitik erabiltzailea nor den badakien zerbaitetara mugitzea da.
Baliabide-mailako identitatea bertsiorik merkeena da. Storage, SQL eta Key Vault guztiek Entra ID autentifikazioa onartzen dute erabiltzaileko edo taldeko rol-esleipenekin, beraz VPN-ak sare-albideak baino ez ditu frogatu behar. Kontu izendatuak dituen jauzi-hosts batek lan bera egiten du administrazio-lanetarako, hosts-ak pertsona erregistratzen duelako eta tunelak paketeak baino ez dituelako garraiatzen. Bezeroak DNS-n erregistratzea eta zenbakia beharrean izena baimentzea araua maila bat gorago eramaten du. Aplikazio-geruzako identitatea — ziurtagiri-subjektua, token-aldarrikapena, taldeko partaidetza — aplikazioari eskatzen zaionean erabakitzea funtzionatzen du, ez sareari.
Iturburu-helbide finkoa eskatzen duen bazkide batentzat, erantzuna site-to-site edo ExpressRoute da, pare aurrizki zehaztu batekin. Pare aurrizkia baimentzen dute, beren aldean agertzen den helbidea gateway-arena da, eta ez da aldatzen norbaitek ordenagailu eramangarri bat berrabiarazten duenean.
Egiaztatu pool-a beste baimen-zerrenda bat editatu aurretik
Poolaren bi ezaugarrik eragiten dute jendeak bezeroari egozten dion jokabidearen zatirik handiena. Pool txiki batek alokairuak azkar birziklatzen ditu, beraz helbideak etengabe mugitzen ari direla dirudi eta helbidean oinarritutako edozein arau diseinuz ezegonkorra dirudi. Tokiko barrutiekin edo sare birtualaren espazioarekin gainjartzen den pool batek bideratze-anbiguotasuna sortzen du, eta hori ez du suebaki-arau batek konponduko.
Jarri hiru gauza orrialde batean arauari ukitzen hasi aurretik: point-to-site pool-a, sare birtualaren helbide-espazioa eta tokiko barrutiak. Ez dira gainjarri behar, eta pool-ak aldi bereko bezero bakoitzarentzako lekua behar du, eta berriz konektatzeko marjina bat.
Ondoren itxi begizta ordena honetan:
- Konektatu bi makinatik bi ordenetan eta alderatu helbideak; truka badaitezke, ez da helbidean oinarritutako araurik segurua.
- Egiaztatu gateway-a Virtual WAN den; bada, erabili talde-pool-ak helbideko arauen ordez.
- Galdetu zer gertatzen den arau batek pertsona okerra jotzen duenean; erantzuna sarbide-istripu bat bada, eraman kontrola identitatera.
- Erregistratu zein barruti dagokion zein talderi NSG definizioen biltegian bertan.
- Probatu berriro pool, autentifikazio edo gateway aldaketaren ondoren, aldaketa horiek mapaketa berridazten dutelako iragarri gabe.