Statikus IP az Azure P2S VPN-ben: miért változik az ügyfél címe

Minden Azure point-to-site ügyfél kap egy címet a készletből, amikor hitelesíti magát, és csak addig tartja meg, amíg az a kapcsolat tart. Nincs foglalási tábla, nincs felhasználónkénti leképezés, és nincs olyan átjáró-beállítás, amely azt jelentené: „mindig adj ennek a személynek 172.16.0.10-et”. Ez az egyetlen mechanizmus magyarázza mindkét tünetet, amellyel az emberek később találkoznak: egy NSG-szabályt, amely már nem illik ahhoz a felhasználóhoz, akihez korábban illett, és egy engedélyezési listát, amely csendben beenged egy gépet, amelyet senki sem tett hozzá szándékosan. A szabály okosabb IP-szabállyal való helyettesítése egyiket sem javítja, mert azt, amit a szabály megnevez, olyan ütemezés szerint osztják ki újra, amelyet nem Ön irányít.

A készlet kapacitás, nem identitás. Azért létezik, hogy az egyidejű alagutak egyedi címeket kapjanak, és a bérlet végének pillanatában újrahasznosítja őket. Ha ez világos, a hasznos kérdés megszűnik „hogyan rögzítsem ehhez az ügyfélhez” lenni, és ez lesz: „mi ellen írhatok olyan szabályt, amelyet az átjáró nem hasznosít újra”.

Mit tesz valójában az átjáró, amikor egy ügyfél csatlakozik

Az átjáró a beállított ügyfélcímtartomány-készletet bérlettáblaként kezeli. Csatlakozáskor elveszi a következő szabad címet, a gyakorlatban a legkisebb elérhetőt, és hozzárendeli az alagút-adapterhez, amíg az ügyfél le nem kapcsolódik, vagy a bérlet le nem jár. A sorrend dönt, nem az identitás: aki egy nyugodt időszak után elsőként csatlakozik újra, az kapja a legkisebb címet, amely abban a pillanatban véletlenül szabad.

A készlet mérete elrejti a viselkedést. Egy laboratóriumi készlet, amely egy-két címmel nagyobb a tesztelők számánál, determinisztikusnak tűnik, mert ugyanaz a laptop minden reggel ugyanabban a sorrendben csatlakozik újra. Adjon hozzá egy harmadik gépet, módosítsa a készlet méretét, vagy hagyjon egy munkamenetet csatlakozva ebéd alatt, és a minta megbomlik. A cím soha nem volt stabil; a sor volt az.

A point-to-site konfiguráció bármilyen változása a bérlettér újraindítását is jelenti. Más hitelesítési típus, átméretezett készlet, új készlettartomány, vagy lebontott és újraépített átjáró mind visszaküldi az ügyfeleket egy készletbe, amely már nem felel meg a régi címeiknek. A változás semmije nem érinti az NSG-t, ezért tűnik a hiba spontánnak.

Ez körülbelül egy perc alatt megfigyelhető. Csatlakozzon, jegyezze fel az alagút címét az ügyfél kapcsolati adataiban, kapcsolódjon le, csatlakoztasson egy második gépet, majd csatlakoztassa újra az elsőt. A visszakapott cím attól függ, mit tart a második gép, és semmilyen portálbeállítás nem állítja vissza a korábbit kérésre.

Az ügyfél IP-jére épülő NSG valójában a csatlakozási sorrendről szóló szabály

Az a szabály, amelyet az emberek először írnak, a kézenfekvő: bejövő szabály a felügyeleti virtuális gép NIC-jén vagy annak alhálózatán, forrásként a VPN-ügyfél belső címével. Rövid, átmegy a teszten azon a napon, amikor megírják, és meghiúsul, amint a készletben több mint egy szabad cím van.

Ebből két meghibásodási mód következik, és csak az egyik tűnik hibának. Egy jogos felhasználót elutasítanak, mert a szabály által megnevezett címet épp valaki más tartja, és ez bosszantó támogatási jegy formájában érkezik. Vagy egy nem szándékolt felhasználót beengednek, mert örökölt egy címet, amelyben a szabály még bízik, és ez semmiként érkezik, amíg valaki nem auditálja a hozzáférést.

Mivel a szabály a bérletet követi, a tényleges szabályzat így hangzik: „aki elsőként csatlakozik, az kap felügyeleti hozzáférést”. Ez a csatlakozási sorrend leírása szándékként álcázva, és semmilyen szabályhigiénia nem teszi szándéknyilvánítássá.

Az ügyfélbérlet és az átjáró címe különböző objektumok

A zavar legnagyobb része egyetlen szóból ered. Az átjárónak viszonylag stabil nyilvános IP-je van; az ügyfeleknek a készletből származó privát címei vannak, amelyek nem stabilak. A nem zónaredundáns VPN-átjáró nyilvános IP-je dinamikusan kerül kiosztásra, de túléli az átméretezést, az újraindítást és a rutinkarbantartást — akkor változik, amikor magát az átjárót törlik és újra létrehozzák. A zónaredundáns és zónás átjáró-SKU-k Standard SKU-s nyilvános IP-t használnak, és ennek a kiosztásnak statikusnak kell lennie.

Ez a stabilitás az, amire egy helyszíni partnernek szüksége van a konfigurációjában, és semmit sem mond az egyes ügyfelek azonosításáról. Amikor egy partner azt kérdezi, milyen címet fog látni, a válasz az átjáró nyilvános IP-je site-to-site esetén, vagy egy megosztott NAT-tartomány — soha nem egy laptop alagútbérlete.

A csoportkészletek olyan tartományt adnak, amely ellen érdemes szabályokat írni

A Virtual WAN point-to-site támogatja a felhasználói csoportokat, és minden csoporthoz saját ügyfélcímtartomány-készlet rendelhető. A tagságot az identitás dönti el, így a tartomány, ahová az ügyfél kerül, kiszámíthatóvá válik: az üzemeltetés az egyik tartományban, a szerződő felek a másikban, és a tartomány olyasmi, amit egy tűzfal- vagy NSG-szabály találgatás nélkül meg tud nevezni.

Az így létrejövő szabálykészletnek olyan alakja van, amelyet át lehet vizsgálni:

• egy készlet közönségenként, a csúcs egyidejű munkamenetekre méretezve, nem a létszámra;
• a csoporttagságot identitás kezeli, nem a szabályok szerkesztése valahányszor valaki csatlakozik;
• az NSG- vagy Azure Firewall-szabályok készlettartományok ellen íródnak, soha nem egyedi bérletek ellen;
• külön központ vagy átjáró azoknak a közönségeknek, amelyeknek soha nem szabad tartományt megosztaniuk.

Egy egész készlet felvétel az engedélyezési listára őszinte, de durva: a tartomány minden csatlakozott ügyfele ugyanazt a hozzáférést kapja. Ez olyan szabályzati döntés, amelyet érdemes hangosan kimondani, ahelyett hogy egy felülvizsgálat során derülne ki. Minden, ami még személyenkénti választ igényel, az erőforráshoz tartozik szerepkör-hozzárendeléseken keresztül, nem a csomagszűrőhöz.

Amikor a telepítés nem tud Virtual WAN-ra váltani

Sok átjáró marad egyszerű VPN-átjáró, és a Virtual WAN-ra váltás nem mellékes változás. A gyakorlati válasz az, hogy a felhasználónkénti döntést a csomagszűrőről valami olyasmire helyezzük, ami már tudja, ki a felhasználó.

Az erőforrás szintű identitás a legolcsóbb változat. A Storage, az SQL és a Key Vault mind támogatja az Entra ID-hitelesítést felhasználónkénti vagy csoportonkénti szerepkör-hozzárendelésekkel, így a VPN-nek csak a hálózati elérhetőséget kell bizonyítania. A megnevezett fiókokkal rendelkező ugrógép ugyanezt teszi az adminisztratív munkánál, mert a gép rögzíti az embert, az alagút pedig csak csomagokat szállít. Az ügyfelek DNS-be történő regisztrálása és a név engedélyezése a szám helyett egy szinttel feljebb viszi a szabályt. Az alkalmazásszintű identitás — tanúsítvány tárgya, token állítás, csoporttagság — akkor működik, amikor nem a hálózatot, hanem az alkalmazást kérik döntésre.

Egy partnernek, aki ragaszkodik a rögzített forráscímhez, a válasz a site-to-site vagy az ExpressRoute meghatározott partnerelőtaggal. Ők engedélyezik a partnerelőtagot, az oldalukon megjelenő cím az átjáróhoz tartozik, és nem változik, amikor valaki újraindít egy laptopot.

Ellenőrizze a készletet, mielőtt újabb engedélyezési listát szerkeszt

A készlet két tulajdonsága okozza a viselkedés legnagyobb részét, amelyet az emberek az ügyfélre fognak. A túl kicsi készlet gyorsan újrahasznosítja a bérleteket, így a címek folyton mozogni látszanak, és minden címalapú szabály eleve megbízhatatlannak tűnik. Az a készlet, amely átfed a helyszíni tartományokkal vagy a virtuális hálózat címterével, olyan útválasztási kétértelműséget okoz, amelyet semmilyen tűzfalszabály nem javít meg.

Tegyen három dolgot egy oldalra, mielőtt egy szabályhoz nyúl: a point-to-site készletet, a virtuális hálózat címterét és a helyszíni tartományokat. Nem fedhetik át egymást, és a készletnek helyet kell adnia minden egyidejű ügyfélnek, plusz tartalékot az újracsatlakozásokhoz.

Ezután zárja be a hurkot ebben a sorrendben:

• Csatlakozzon két gépről mindkét sorrendben, és hasonlítsa össze a címeket; ha fel tudnak cserélődni, egyetlen címalapú szabály sem biztonságos.
• Ellenőrizze, hogy az átjáró Virtual WAN-e; ha igen, használjon csoportkészleteket a cím szerinti szabályok helyett.
• Kérdezze meg, mi történik, ha egy szabály a rossz személyre illik; ha a válasz hozzáférési incidens, helyezze át az ellenőrzést identitásra.
• Jegyezze fel, melyik tartomány melyik csoporthoz tartozik, ugyanabban a tárolóban, ahol az NSG-definíciók vannak.
• Tesztelje újra a készlet, a hitelesítés vagy az átjáró minden változása után, mert ezek a változások bejelentés nélkül írják át a leképezést.