Prečo pridanie prefixu Azure VPN odpojí pripojenie

Prefix pridaný k nesprávnemu objektu Azure vytvorí pripojenie, ktoré hlási Connected a nič nepreposiela, a to je najdrahší druh chyby v tomto zásobníku. Zapojené sú tri prostriedky a len jeden z nich vlastní vzdialený adresný priestor: brána virtuálnej siete, brána miestnej siete, ktorá opisuje vzdialenú stranu, a pripojenie, ktoré ich spája. Prefix patrí bráne miestnej siete, pripojenie sa musí znova vytvoriť, aby zmena nadobudla účinnosť, a samotná brána zvyčajne zostáva nedotknutá. Poradie nie je predmetom rokovania a portál zobrazuje len časť z neho.

Tri objekty, z ktorých jeden drží prefix

Adresný priestor virtuálnej siete odpovedá na inú otázku: čo žije vnútri Azure. Pridanie vzdialeného prefixu tam nevedie prevádzku k nemu, len rozširuje priestor, o ktorom si platforma myslí, že ho vlastní, čo sa môže zraziť so skutočným vzdialeným rozsahom. Brána miestnej siete je objekt, ktorý drží vzdialené prefixy, a pripojenie odkazuje na obe brány plus vopred zdieľaný kľúč.

Je tu ešte tretia výhrada, ktorú treba mať na pamäti. GatewaySubnet hostuje spravované inštancie brány, musí mať presne tento názov a pri iných ako Basic SKU sa očakáva, že bude aspoň /27.

Nič iné do tej podsiete nepatrí a zmena prefixu nemá dôvod sa jej dotýkať. Prefix, ktorý v bráne miestnej siete chýba, je nedostupný bez ohľadu na to, čo hovorí stav pripojenia, pretože brána ponúka len tie prefixy, o ktorých bola informovaná pri vyjednávaní tunela. Preto je príznak asymetrický: tunel je hore, pridruženie zabezpečenia je v poriadku a jedna podsiete sa nikdy neobjaví v selektoroch prevádzky. Ak jeden vzdialený rozsah chýba, kým susedné fungujú, prestaňte sa pozerať na tunel a prečítajte si bránu miestnej siete.

Prečo sa odstraňuje práve pripojenie

Objekt pripojenia fixuje vyjednanú konfiguráciu na celú dobu svojej životnosti. Preto dokumentovaný postup najprv odstráni pripojenie, aktualizuje bránu miestnej siete a potom pripojenie znova vytvorí s tým istým zdieľaným kľúčom. Inštancie brány sa neprestavujú pri zmene len prefixu, čo obmedzuje výpadok na rozobratie pripojenia namiesto nového nasadenia brány.

To vymazanie je výpadok, tak k nemu pristupujte ako k plánovanej zmene so začiatkom a očakávaným koncom, nie ako k rýchlej úprave. V PowerShelli je sled krátky: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, potom Set-AzLocalNetworkGateway s novým -AddressPrefix poľom, potom New-AzVirtualNetworkGatewayConnection s tým istým -SharedKey a tými istými bránami. Opätovné použitie kľúča je dôležité, pretože vzdialená strana sa neprekonfiguruje a nový kľúč znamená koordináciu s tým, kto vlastní vzdialené zariadenie. Ak toto zariadenie prevádzkuje iný tím, dohodnite s ním okno, skôr než čokoľvek odstránite.

Kedy treba prestavať samotnú bránu

Druhá odpoveď, ktorá koluje okolo tohto problému, hovorí, že bránu treba znova vytvoriť a kľúč znova vymeniť. To platí pre inú sadu operácií: zmenu typu brány alebo SKU, prechod medzi point-to-site a site-to-site alebo opravu brány, ktorej vlastná konfigurácia je nesprávna. Také zmeny skutočne menia prostriedok brány, takže prestavba je naozaj potrebná.

Bráne vytvorenej pre point-to-site nemožno jednoducho prideliť pripojenie site-to-site. Konfigurácia point-to-site sa musí odstrániť a brána znova vytvoriť, čo tiež vytvorí nový zdieľaný kľúč a nový klientsky balík.

Balík point-to-site si zaslúži vlastnú poznámku, pretože vyprší. Portál generuje súbor s krátkou životnosťou, takže praktický prístup je stiahnuť ho raz a distribuovať spolu s klientskym certifikátom, namiesto posielania odkazu na portál používateľom, ktorý bude mŕtvy, keď naň kliknú. Pre otázku prefixu nič z toho neplatí. Držať oba postupy oddelene je celá disciplína: prefixy sú zmena na úrovni pripojenia a vlastnosti brány sú zmena na úrovni brány.

Čítajte stav, nie odznak portálu

Čítajte stav z prostriedku, nie z odznaku na portáli. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 vracia ConnectionStatus spolu s počítadlami prichádzajúcich a odchádzajúcich bajtov, a práve počítadlá oddeľujú tunel, ktorý je pripojený a nič nenesie, od toho, ktorý sa nikdy neustavil.

Počítadlá, ktoré prestanú rásť uprostred prenosu, ukazujú na cestu, nie na overovanie. Počítadlá, ktoré sa vôbec nehýbu, ukazujú na sadu prefixov alebo zdieľaný kľúč.

Časovače vysvetľujú triedu odpojení, ktoré sa mylne pripisujú VPN. Nástroj na vyrovnávanie zaťaženia Azure zatvára neaktívne toky po nastavenom časovom limite, v predvolenom nastavení štyri minúty, keď sa písali tieto poznámky, a dá sa zvyšovať, takže server OpenVPN na VM bez keepalive môže padať každých niekoľko minút, kým všetko ostatné vyzerá zdravo. Brána, ktorú platforma cyklicky reštartuje, tiež môže prerušiť pripojenie VNet k Web App, a táto porucha je na strane platformy, nie v konfigurácii klienta. Vodidlom je, či odpojenie sleduje pevný interval alebo zmenu, ktorú ste urobili.

Držte tri objekty a ich hodnoty v jednom zázname: adresný priestor virtuálnej siete, zoznam prefixov brány miestnej siete a odkaz na zdieľaný kľúč pripojenia. článok o PowerShelli pre site-to-site dokumentuje príkazy brány miestnej siete a poradie, do ktorého patria. Porovnávanie zmeny prefixu s pamäťou je spôsob, akým sa fungujúci tunel dvakrát prestaví.

Potom overte v poradí, v akom ste menili: brána miestnej siete zobrazuje nový zoznam prefixov, pripojenie je znova Connected a počítadlá sa hýbu, keď odošlete prevádzku na hostiteľa v novom rozsahu. Ak tretí krok zlyhá, kým prvé dva prejdú, vzdialená strana neprijala nový selektor prevádzky a vzdialené zariadenie potrebuje zodpovedajúcu položku fázy 2. To je rozhovor s druhým koncom tunela, nie ďalšia zmena v Azure.