Statická IP v Azure P2S VPN: proč se adresa klienta mění

Každý klient Azure point-to-site dostane při autentizaci adresu z poolu a podrží si ji jen po dobu trvání toho spojení. Neexistuje rezervační tabulka, mapování na uživatele ani nastavení brány, které by znamenalo „tomuto člověku vždy dej 172.16.0.10“. Právě tento jediný mechanismus vysvětluje oba příznaky, na které lidé později narazí: pravidlo NSG, které přestane odpovídat uživateli, kterému dřív odpovídalo, a seznam povolených, který potichu pustí stroj, jejž nikdo záměrně nepřidal. Nahrazení pravidla chytřejším IP pravidlem nespraví ani jedno, protože to, co pravidlo pojmenovává, se přiděluje podle plánu, který neřídíte.

Pool je kapacita, ne identita. Existuje proto, aby souběžné tunely dostaly jedinečné adresy, a recykluje je v okamžiku, kdy skončí lease. Jakmile je to jasné, užitečná otázka přestává být „jak tohoto klienta připoutám“ a stává se „proti čemu můžu napsat pravidlo, které brána nerecykluje“.

Co brána skutečně dělá, když se klient připojí

Brána drží nakonfigurovaný pool adres klientů a zachází s ním jako s tabulkou lease. Při připojení vezme další volnou adresu, v praxi nejnižší dostupnou, a přiřadí ji adaptéru tunelu, dokud se klient neodpojí nebo dokud lease nevyprší. Rozhoduje pořadí, ne identita: kdo se po klidovém období připojí první, dostane nejnižší adresu, která je v tu chvíli náhodou volná.

Velikost poolu chování skrývá. Laboratorní pool o jednu nebo dvě adresy větší než počet testerů vypadá deterministicky, protože stejný notebook se obvykle každé ráno připojuje ve stejném pořadí. Přidejte třetí stroj, změňte velikost poolu nebo nechte relaci připojenou přes oběd a vzorec se rozpadne. Adresa nikdy nebyla stabilní; stabilní byla fronta.

Každá změna konfigurace point-to-site také resetuje prostor lease. Jiný typ autentizace, změněná velikost poolu, nový rozsah poolu nebo brána, která se zbourá a postaví znovu, pošlou klienty zpět do poolu, který už neodpovídá jejich starým adresám. Nic z té změny se nedotkne vašeho NSG, a proto porucha vypadá samovolně.

Můžete to sledovat zhruba za minutu. Připojte se, poznamenejte adresu tunelu v podrobnostech připojení klienta, odpojte se, připojte druhý stroj a pak znovu připojte první. Adresa, kterou dostanete zpět, závisí na tom, co drží druhý stroj, a žádné nastavení portálu nevrátí tu předchozí na požádání.

NSG vázané na IP klienta je ve skutečnosti pravidlo o pořadí připojování

Pravidlo, které lidé píšou první, je to zřejmé: příchozí pravidlo na NIC správcovského VM nebo na jeho podsíť, se zdrojem v podobě interní adresy klienta VPN. Je krátké, v den napsání projde testem a selže, jakmile má pool víc než jednu volnou adresu.

Z toho plynou dva režimy selhání a jen jeden vypadá jako chyba. Legitimní uživatel je odmítnut, protože adresu, kterou pravidlo pojmenovává, právě drží někdo jiný, což dorazí jako otravný tiket na podporu. Nebo je nechtěný uživatel vpuštěn, protože zdědil adresu, které pravidlo stále věří, a to nedorazí nijak, dokud někdo neprovede audit přístupu.

Protože pravidlo sleduje lease, efektivní politika zní „první, kdo se připojí, dostane správcovský přístup“. To je popis pořadí připojování převlečený za záměr a žádná hygiena pravidel z něj záměr neudělá.

Lease klienta a adresa brány jsou různé objekty

Většina zmatku pochází z jednoho slova. Brána má veřejnou IP, která je poměrně stabilní; klienti mají privátní adresy z poolu, které stabilní nejsou. U brány VPN, která není zónově redundantní, se veřejná IP přiděluje dynamicky, ale přežije změnu velikosti, reset i rutinní údržbu — změní se, když se sama brána smaže a znovu vytvoří. Zónově redundantní a zonální SKU brány používají veřejnou IP Standard SKU a toto přidělení musí být statické.

Právě tato stabilita je to, co místní protějšek potřebuje ve své konfiguraci, a o identifikaci jednotlivého klienta neříká nic. Když se partner zeptá, kterou adresu uvidí, odpovědí je veřejná IP brány u site-to-site nebo sdílený rozsah NAT — nikdy lease tunelu notebooku.

Skupinové pooly vám dají rozsah, proti kterému má smysl psát pravidla

Virtual WAN point-to-site podporuje uživatelské skupiny a každé skupině lze přiřadit vlastní pool adres klientů. Členství se rozhoduje identitou, takže rozsah, do kterého klient spadne, je předvídatelný: provoz v jednom rozsahu, dodavatelé v jiném, a rozsah je něco, co pravidlo firewallu nebo NSG dokáže pojmenovat bez hádání.

Výsledná sada pravidel má tvar, který můžete zkontrolovat:

• jeden pool na publikum, dimenzovaný na špičkové souběžné relace, ne na počet lidí;
• členství ve skupině se řídí identitou, ne úpravou pravidel při každém přidání člověka;
• pravidla NSG nebo Azure Firewall psaná proti rozsahům poolu, nikdy proti jednotlivým lease;
• samostatný hub nebo brána pro publika, která nikdy nesmějí sdílet rozsah.

Povolit celý pool je poctivé, ale hrubé: každý připojený klient v tom rozsahu dostane stejný přístup. Je to politické rozhodnutí, které stojí za to říct nahlas, místo aby se objevilo při revizi. Vše, co ještě potřebuje odpověď na jednotlivou osobu, patří k prostředku přes přiřazení rolí, ne k paketovému filtru.

Když se nasazení nemůže přesunout na Virtual WAN

Hodně bran zůstává obyčejnými branami VPN a přechod na Virtual WAN není drobná změna. Praktickou odpovědí je přesunout rozhodnutí na uživatele z paketového filtru na něco, co už ví, kdo uživatel je.

Identita na úrovni prostředku je nejlevnější verze. Storage, SQL i Key Vault podporují autentizaci Entra ID s přiřazením rolí na uživatele nebo skupinu, takže VPN musí jen prokázat síťovou dosažitelnost. Skokový hostitel s pojmenovanými účty dělá stejnou práci pro administrativu, protože hostitel zaznamenává člověka a tunel jen přenáší pakety. Registrace klientů v DNS a povolení jména místo čísla posouvá pravidlo o vrstvu výš. Identita na aplikační vrstvě — subjekt certifikátu, tvrzení tokenu, členství ve skupině — funguje, když má rozhodnout aplikace, ne síť.

Pro partnera, který trvá na pevné zdrojové adrese, je odpovědí site-to-site nebo ExpressRoute s definovaným prefixem protějšku. Ten prefix si dají do seznamu povolených, adresa, která se objeví na jejich straně, patří bráně a nezmění se, když někdo restartuje notebook.

Než upravíte další seznam povolených, zkontrolujte pool

Dvě vlastnosti poolu způsobují většinu chování, které lidé svalují na klienta. Příliš malý pool recykluje lease rychle, takže adresy vypadají jako neustále se pohybující a každé pravidlo založené na adrese vypadá od základu nespolehlivě. Pool, který se překrývá s místními rozsahy nebo s adresním prostorem virtuální sítě, vytváří nejednoznačnost směrování, kterou žádné pravidlo firewallu nespraví.

Než se dotknete pravidla, dejte na jednu stránku tři věci: pool point-to-site, adresní prostor virtuální sítě a místní rozsahy. Nesmějí se překrývat a pool potřebuje místo pro každého souběžného klienta plus rezervu na opětovná připojení.

Pak uzavřete smyčku v tomto pořadí:

• Připojte se ze dvou strojů v obou pořadích a porovnejte adresy; pokud se mohou prohodit, žádné pravidlo založené na adrese není bezpečné.
• Zkontrolujte, zda je brána Virtual WAN; pokud ano, použijte skupinové pooly místo pravidel na jednotlivé adresy.
• Zeptejte se, co se stane, když pravidlo zasáhne špatného člověka; pokud je odpovědí bezpečnostní incident, přesuňte řízení na identitu.
• Zaznamenejte, který rozsah patří které skupině, do stejného repozitáře jako definice NSG.
• Po každé změně poolu, autentizace nebo brány znovu otestujte, protože tyto změny přepisují mapování, aniž by to oznámily.