Statysk IP yn Azure P2S VPN: wêrom't it adres fan de klant feroaret

Elke Azure point-to-site-klant krijt in adres út de pool as er autentisearret, en hâldt it allinnich sa lang as dy ferbining duorret. Der is gjin reservearringstabel, gjin mapning per brûker, en gjin gateway-ynstelling dy't betsjuttet “jou dizze persoan altyd 172.16.0.10”. Krekt dat iene meganisme ferklearret beide symptomen dy't minsken letter tsjinkomme: in NSG-regel dy't net mear past by in brûker dêr't er earder by paste, en in tastiene list dy't stil in masine talitten lit dy't nimmen mei opsetsin tafoege hat. It ferfangen fan de regel troch in tûker IP-regel ferhelpt gjin fan beide, om't wat de regel neamt opnij tawiisd wurdt neffens in skema datst net behearst.

De pool is kapasiteit, net identiteit. Hy bestiet sadat tagelyk tunnels unike adressen krije, en hy recyclaget se op it stuit dat in hier einiget. As dat dúdlik is, hâldt de nuttige fraach op om “hoe fêstigje ik dizze klant” te wêzen en wurdt it “dêr't kin ik in regel tsjin skriuwe dy't de gateway net recyclaget”.

Wat de gateway eins docht as in klant ferbynt

De gateway hâldt de konfigurearre klantadrespool en behannelet dy as in hiertabel. By it ferbinen nimt er it folgjende frije adres, yn 'e praktyk it leechste beskikbere, en jout dat oan de tunneladapter oant de klant ferbrekt of de hier ferrint. De oarder beslút, net de identiteit: wa't nei in rêstige perioade as earste wer ferbynt, krijt it leechste adres dat op dat stuit tafallich frij is.

De grutte fan 'e pool ferberget it gedrach. In laboratoariumpool ien of twa adressen grutter as it oantal testers liket deterministysk, om't deselde laptop eltse moarn yn deselde oarder wer ferbynt. Foegje in tredde masine ta, feroarje de grutte fan 'e pool, of lit in sesje oer de middei ferbûn, en it patroan brekt. It adres wie nea stabyl; de rige wie it.

Elke feroaring oan 'e point-to-site-konfiguraasje set ek de hierromte werom. In oar type autentikaasje, in oars grutte pool, in nij poolberik, of in gateway dy't ôfbrutsen en wer opboud wurdt, stjoere klanten allegear werom yn in pool dy't net mear by har âlde adressen past. Neat oan dy feroaring rekket dyn NSG, dêrom liket de brek spontaan.

Do kinst it yn sawat in minút sjen barre. Ferbyn, skriuw it tunneladres op yn 'e ferbiningsdetails fan 'e klant, ferbrek, ferbyn in twadde masine, en ferbyn dan wer de earste. It adres datst weromkrijest hinget ôf fan wat de twadde masine hâldt, en gjin portalinynstelling sil it eardere op oanfraach weromsette.

In NSG basearre op it klant-IP is eins in regel oer ferbiningsorder

De regel dy't minsken earst skriuwe is de foar de hân lizzende: in yngeande regel op 'e NIC fan 'e behear-VM of op syn subnet, mei it ynterne adres fan 'e VPN-klant as boarne. Hy is koart, hy slagget foar de test op 'e dei dat er skreaun wurdt, en hy mislearret sa gau as de pool mear as ien frij adres hat.

Dêrút folgje twa mislearringsmodi, en mar ien fan beide liket in bug. In legitime brûker wurdt wegere om't immen oars op dat stuit it adres hat dat de regel neamt, wat as in ferfelend stipekaartsje binnenkomt. Of in net-bedoelde brûker wurdt talitten om't er in adres erfd hat dêr't de regel noch op fertrout, wat hielendal net binnenkomt oant immen de tagong auditet.

Om't de regel de hier folget, seit it effektive belied “de earste persoan dy't ferbynt krijt behearstegong”. Dat is in beskriuwing fan ferbiningsorder ferklaaid as bedoeling, en gjin regelhygiêne makket dêr in útdrukking fan bedoeling fan.

De hier fan 'e klant en it gateway-adres binne ferskillende objekten

It measte betizing komt fan ien wurd. De gateway hat in iepenbier IP dat relatyf stabyl is; klanten hawwe partikuliere adressen út 'e pool dy't dat net binne. Foar in VPN-gateway sûnder sône-redundânsje wurdt it iepenbiere IP dynamysk tawiisd, mar it oerlibbet in grutteferoaring, in reset en routineûnderhâld — it feroaret as de gateway sels fuortsmiten en opnij makke wurdt. Sône-redundante en sonale gateway-SKU's brûke in iepenbier IP fan Standard SKU, en dy tawizing moat statysk wêze.

Dy stabiliteit is wat in pleatslike peer yn syn konfiguraasje nedich hat, en it seit neat oer it identifisearjen fan in yndividuele klant. As in partner freget hokker adres er sjocht, is it antwurd it iepenbiere IP fan 'e gateway ûnder site-to-site, of in dield NAT-berik — nea de tunnelhier fan in laptop.

Groepspools jouwe dy in berik dêr't it de muoite wurdich is regels tsjin te skriuwen

Virtual WAN point-to-site stipet brûkersgroepen, en elke groep kin syn eigen klantadrespool krije. Lidmaatskip wurdt troch identiteit besletten, dus it berik dêr't in klant yn lânet wurdt foarsisber: operaasjes yn ien berik, oannimmers yn in oar, en it berik is iets dat in firewall- of NSG-regel neame kin sûnder te rieden.

De regelset dy't dêrút komt hat in foarm dy'tst neisjen kinst:

• ien pool per publyk, grutte foar pyk tagelyk sesjes yn stee fan koptealling;
• groepslidmaatskip regele fia identiteit, net troch regels te bewurkjen eltse kear as immen derby komt;
• NSG- of Azure Firewall-regels skreaun tsjin poolberikken, nea tsjin yndividuele hieren;
• in aparte hub of gateway foar publyk dat nea in berik diele mei.

In hiele pool op 'e tastiene list sette is earlik mar grof: elke ferbûne klant yn dat berik krijt deselde tagong. Dat is in beliedsbeslút dat it wurdich is hurdop te sizzen ynstee fan by in neisjen te ûntdekken. Alles dat noch in antwurd per persoan nedich hat, heart by de boarne, fia roltaawizings, net by it pakketfilter.

As de útrulling net nei Virtual WAN ferhúzje kin

In protte gateways bliuwe gewoane VPN-gateways, en nei Virtual WAN ferhúzje is gjin tafallige feroaring. It praktykse antwurd is it beslút per brûker fan it pakketfilter ôf te ferpleatsen nei iets dat al wit wa't de brûker is.

Identiteit op boarnenivo is de goedkoopste ferzje. Storage, SQL en Key Vault stypje allegear Entra ID-autentikaasje mei roltaawizings per brûker of per groep, dus de VPN hoecht allinnich netwurkberikberens te bewizen. In springhost mei neamde akkounts docht itselde wurk foar behearstaken, om't de host de persoan registrearret en de tunnel allinnich pakketten ferfiert. Klanten yn DNS registrearje en de namme ynstee fan it nûmer tastean ferpleatst de regel ien laach omheech. Identiteit op applikaasjelaach — in sertifikaatûnderwerp, in tokenbewearing, in groepslidmaatskip — wurket as it de applikaasje is, net it netwurk, dy't frege wurdt te besluten.

Foar in partner dy't op in fêst boarne-adres stiet, is it antwurd site-to-site of ExpressRoute mei in definiearre peer-prefiks. Se tastean it peer-prefiks, it adres dat oan har kant ferskynt heart by de gateway, en it feroaret net as immen in laptop wer opstartet.

Kontrolearje de pool foar'tst in oare tastiene list bewurkest

Twa eigenskippen fan 'e pool feroarsaakje it measte fan it gedrach dat minsken de klant ferwite. In te lytse pool recyclaget hieren fluch, dus adressen lykje hieltyd te ferpleatsen en elke adresbasearre regel liket fan 'e grûn ôf ûnbetrouber. In pool dy't de pleatslike berikken of de adresromte fan it firtuele netwurk oerlaapet, skept dûbelsinnigens yn 'e rûteleiding dy't gjin firewall-regel reparearret.

Set trije dingen op ien side foar'tst in regel oanrekest: de point-to-site-pool, de adresromte fan it firtuele netwurk en de pleatslike berikken. Se meie net oerlaapje, en de pool hat romte nedich foar elke tagelyk klant plus in marzje foar werferbiningen.

Slút dan de sirkel yn dizze oarder:

• Ferbyn fan twa masines yn beide oarders en fergelykje de adressen; as se wikselje kinne, is gjin adresbasearre regel feilich.
• Kontrolearje oft de gateway Virtual WAN is; as dat sa is, brûk groepspools ynstee fan regels per adres.
• Freegje wat der bart as in regel de ferkearde persoan rekket; as it antwurd in tagongsynsidint is, ferpleats de kontrôle nei identiteit.
• Skriuw op hokker berik by hokker groep heart, yn itselde bewarplak as de NSG-definysjes.
• Test opnij nei elke feroaring fan pool, autentikaasje of gateway, om't dy feroarings de mapning wer oanskriuwe sûnder it oan te kundigjen.