Statická IP v Azure P2S VPN: prečo sa adresa klienta mení

Každý klient Azure point-to-site dostane pri autentifikácii adresu z fondu a ponechá si ju len na čas trvania tohto pripojenia. Neexistuje rezervačná tabuľka, mapovanie na používateľa ani nastavenie brány, ktoré by znamenalo „tomuto človeku vždy daj 172.16.0.10“. Práve tento jediný mechanizmus vysvetľuje oba príznaky, na ktoré ľudia neskôr narazia: pravidlo NSG, ktoré prestane zodpovedať používateľovi, ktorému predtým zodpovedalo, a zoznam povolených, ktorý potichu pustí stroj, ktorý nikto zámerne nepridal. Nahradenie pravidla dômyselnejším IP pravidlom neopraví ani jedno, pretože to, čo pravidlo pomenúva, sa preraďuje podľa rozvrhu, ktorý nekontrolujete.

Fond je kapacita, nie identita. Existuje preto, aby súbežné tunely dostali jedinečné adresy, a recykluje ich v okamihu, keď sa skončí prenájom. Keď je to jasné, užitočná otázka prestáva byť „ako tohto klienta pripnem“ a stáva sa „voči čomu môžem napísať pravidlo, ktoré brána nerecykluje“.

Čo brána skutočne robí, keď sa klient pripojí

Brána drží nastavený fond adries klientov a zaobchádza s ním ako s tabuľkou prenájmov. Pri pripojení vezme ďalšiu voľnú adresu, v praxi najnižšiu dostupnú, a pridelí ju adaptéru tunela, kým sa klient neodpojí alebo kým prenájom nevyprší. Rozhoduje poradie, nie identita: kto sa po pokojnom období pripojí prvý, dostane najnižšiu adresu, ktorá je v tej chvíli náhodou voľná.

Veľkosť fondu skrýva správanie. Laboratórny fond o jednu alebo dve adresy väčší ako počet testerov vyzerá deterministicky, pretože ten istý notebook sa zvyčajne každé ráno pripája v rovnakom poradí. Pridajte tretí stroj, zmeňte veľkosť fondu alebo nechajte reláciu pripojenú cez obed a vzor sa rozpadne. Adresa nikdy nebola stabilná; stabilný bol rad.

Každá zmena konfigurácie point-to-site tiež resetuje priestor prenájmov. Iný typ autentifikácie, fond s inou veľkosťou, nový rozsah fondu alebo brána, ktorá sa zbúra a postaví odznova, pošlú všetkých klientov späť do fondu, ktorý už nezodpovedá ich starým adresám. Nič z tej zmeny sa nedotkne vášho NSG, a preto porucha vyzerá samovoľne.

Môžete to vidieť približne za minútu. Pripojte sa, poznamenajte adresu tunela v podrobnostiach pripojenia klienta, odpojte sa, pripojte druhý stroj a potom znova pripojte prvý. Adresa, ktorú dostanete späť, závisí od toho, čo drží druhý stroj, a žiadne nastavenie portálu neobnoví tú predchádzajúcu na požiadanie.

NSG viazaný na IP klienta je v skutočnosti pravidlo o poradí pripájania

Pravidlo, ktoré ľudia píšu ako prvé, je to zrejmé: prichádzajúce pravidlo na NIC správcovského VM alebo na jeho podsieti, so zdrojom v podobe internej adresy klienta VPN. Je krátke, v deň napísania prejde testom a zlyhá, hneď ako má fond viac než jednu voľnú adresu.

Z toho vyplývajú dva režimy zlyhania a iba jeden vyzerá ako chyba. Legitímny používateľ je odmietnutý, pretože adresu, ktorú pravidlo pomenúva, práve teraz drží niekto iný, a prichádza to ako otravný lístok na podporu. Alebo je nechcený používateľ vpustený, pretože zdedil adresu, ktorej pravidlo stále dôveruje, a to neprichádza ako nič, kým niekto nevykoná audit prístupu.

Keďže pravidlo sleduje prenájom, efektívna politika znie „prvý, kto sa pripojí, dostane správcovský prístup“. To je opis poradia pripájania prezlečený za úmysel a žiadna hygiena pravidiel z neho neurobí vyjadrenie úmyslu.

Prenájom klienta a adresa brány sú rôzne objekty

Väčšina zmätku pochádza z jedného slova. Brána má verejnú IP, ktorá je pomerne stabilná; klienti majú súkromné adresy z fondu, ktoré stabilné nie sú. Pri bráne VPN bez zónovej redundancie sa verejná IP prideľuje dynamicky, ale prežije zmenu veľkosti, reset aj rutinnú údržbu — zmení sa, keď sa sama brána zmaže a znova vytvorí. Zónovo redundantné a zonálne SKU brány používajú verejnú IP SKU Standard a toto pridelenie musí byť statické.

Práve túto stabilitu potrebuje miestny partner vo svojej konfigurácii a o identifikácii jednotlivého klienta nehovorí nič. Keď sa partner opýta, ktorú adresu uvidí, odpoveďou je verejná IP brány v site-to-site alebo spoločný rozsah NAT — nikdy prenájom tunela notebooku.

Skupinové fondy vám dajú rozsah, voči ktorému má zmysel písať pravidlá

Virtual WAN point-to-site podporuje používateľské skupiny a každej skupine možno prideliť vlastný fond adries klientov. Členstvo sa rozhoduje identitou, takže rozsah, do ktorého klient spadne, sa stáva predvídateľným: prevádzka v jednom rozsahu, dodávatelia v inom, a rozsah je niečo, čo pravidlo firewallu alebo NSG dokáže pomenovať bez hádania.

Výsledná sada pravidiel má tvar, ktorý si môžete pozrieť:

• jeden fond na publikum, dimenzovaný na špičku súbežných relácií, nie na počet ľudí;
• členstvo v skupine sa riadi identitou, nie úpravou pravidiel pri každom pridaní človeka;
• pravidlá NSG alebo Azure Firewall písané voči rozsahom fondu, nikdy voči jednotlivým prenájmom;
• samostatný hub alebo brána pre publiká, ktoré nikdy nesmú zdieľať rozsah.

Povolenie celého fondu je poctivé, ale hrubé: každý pripojený klient v tom rozsahu dostane rovnaký prístup. Je to politické rozhodnutie, ktoré stojí za to povedať nahlas, namiesto toho, aby sa objavilo pri revízii. Všetko, čo ešte potrebuje odpoveď na jednotlivú osobu, patrí k prostriedku cez priradenia rolí, nie k paketovému filtru.

Keď sa nasadenie nemôže presunúť na Virtual WAN

Mnohé brány zostávajú obyčajnými bránami VPN a prechod na Virtual WAN nie je drobná zmena. Praktickou odpoveďou je presunúť rozhodnutie na používateľa z paketového filtra na niečo, čo už vie, kto je používateľ.

Identita na úrovni prostriedku je najlacnejšia verzia. Storage, SQL aj Key Vault podporujú autentifikáciu Entra ID s priradením rolí na používateľa alebo skupinu, takže VPN musí len preukázať sieťovú dostupnosť. Skokový hostiteľ s pomenovanými účtami robí to isté pre administratívu, pretože hostiteľ zaznamenáva človeka a tunel len prenáša pakety. Registrácia klientov v DNS a povolenie mena namiesto čísla posúva pravidlo o vrstvu vyššie. Identita na aplikačnej vrstve — subjekt certifikátu, tvrdenie tokenu, členstvo v skupine — funguje, keď má rozhodnúť aplikácia, nie sieť.

Pre partnera, ktorý trvá na pevnej zdrojovej adrese, je odpoveďou site-to-site alebo ExpressRoute s definovaným prefixom protistrany. Ten prefix si dajú do zoznamu povolených, adresa, ktorá sa objaví na ich strane, patrí bráne a nezmení sa, keď niekto reštartuje notebook.

Skôr než upravíte ďalší zoznam povolených, skontrolujte fond

Dve vlastnosti fondu spôsobujú väčšinu správania, ktoré ľudia zvaľujú na klienta. Príliš malý fond recykluje prenájmy rýchlo, takže adresy vyzerajú ako neustále sa pohybujúce a každé pravidlo založené na adrese vyzerá od základu nespoľahlivo. Fond, ktorý sa prekrýva s miestnymi rozsahmi alebo s adresným priestorom virtuálnej siete, vytvára nejednoznačnosť smerovania, ktorú žiadne pravidlo firewallu neopraví.

Skôr než sa dotknete pravidla, dajte na jednu stránku tri veci: fond point-to-site, adresný priestor virtuálnej siete a miestne rozsahy. Nesmú sa prekrývať a fond potrebuje miesto pre každého súbežného klienta plus rezervu na opätovné pripojenia.

Potom uzavrite slučku v tomto poradí:

• Pripojte sa z dvoch strojov v oboch poradiach a porovnajte adresy; ak sa môžu vymeniť, žiadne pravidlo založené na adrese nie je bezpečné.
• Skontrolujte, či je brána Virtual WAN; ak áno, použite skupinové fondy namiesto pravidiel na jednotlivé adresy.
• Opýtajte sa, čo sa stane, keď pravidlo zasiahne nesprávneho človeka; ak je odpoveďou bezpečnostný incident, presuňte kontrolu na identitu.
• Zaznamenajte, ktorý rozsah patrí ktorej skupine, do toho istého repozitára ako definície NSG.
• Po každej zmene fondu, autentifikácie alebo brány otestujte znova, pretože tie zmeny prepisujú mapovanie bez ohlásenia.