Dlaczego dodanie prefiksu Azure VPN zrywa połączenie

Prefiks dodany do niewłaściwego obiektu Azure daje połączenie, które zgłasza Connected i nic nie przekazuje, a to najdroższy rodzaj błędu w tym stosie. Zaangażowane są trzy zasoby i tylko jeden z nich posiada zdalną przestrzeń adresową: brama sieci wirtualnej, lokalna brama sieciowa opisująca drugą stronę oraz połączenie, które je łączy. Prefiks należy do lokalnej bramy sieciowej, połączenie trzeba odtworzyć, aby zmiana weszła w życie, a sama brama zwykle pozostaje nietknięta. Kolejność nie podlega negocjacjom, a portal pokazuje tylko jej część.

Trzy obiekty, z których jeden przechowuje prefiks

Przestrzeń adresowa sieci wirtualnej odpowiada na inne pytanie: co żyje wewnątrz Azure. Dodanie tam zdalnego prefiksu nie kieruje ruchu do niego, tylko poszerza przestrzeń, którą platforma uważa za swoją, co może kolidować z rzeczywistym zdalnym zakresem. Lokalna brama sieciowa to obiekt, który przechowuje zdalne prefiksy, a połączenie odwołuje się do obu bram oraz wstępnie współdzielonego klucza.

Jest jeszcze trzecie zastrzeżenie, o którym warto pamiętać. GatewaySubnet hostuje zarządzane wystąpienia bramy, musi nosić dokładnie tę nazwę, a w przypadku SKU innych niż Basic oczekuje się, że będzie to co najmniej /27.

Nic innego nie należy do tej podsieci, a zmiana prefiksu nie ma powodu jej dotykać. Prefiks, którego brakuje w lokalnej bramie sieciowej, jest nieosiągalny niezależnie od tego, co mówi stan połączenia, ponieważ brama oferuje tylko te prefiksy, o których została poinformowana podczas negocjowania tunelu. Dlatego objaw jest asymetryczny: tunel jest podniesiony, skojarzenie zabezpieczeń jest w porządku, a jedna podsieć nigdy nie pojawia się w selektorach ruchu. Jeśli brakuje jednego zdalnego zakresu, podczas gdy sąsiednie działają, przestań patrzeć na tunel i przeczytaj lokalną bramę sieciową.

Dlaczego usuwa się właśnie połączenie

Obiekt połączenia utrwala wynegocjowaną konfigurację na cały okres swojego istnienia. Dlatego udokumentowana procedura najpierw usuwa połączenie, aktualizuje lokalną bramę sieciową, a następnie odtwarza połączenie z tym samym współdzielonym kluczem. Wystąpienia bramy nie są odbudowywane przy zmianie dotyczącej tylko prefiksu, co ogranicza przerwę do rozbiórki połączenia zamiast ponownego wdrożenia bramy.

To usunięcie jest właśnie przerwą, więc traktuj je jak zaplanowaną zmianę z początkiem i oczekiwanym końcem, a nie szybką edycję. W PowerShell kolejność jest krótka: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, następnie Set-AzLocalNetworkGateway z nową -AddressPrefix tablicą, następnie New-AzVirtualNetworkGatewayConnection z tym samym -SharedKey i tymi samymi bramami. Ponowne użycie klucza ma znaczenie, ponieważ druga strona nie jest rekonfigurowana, a nowy klucz oznacza koordynację z właścicielem zdalnego urządzenia. Jeśli to urządzenie obsługuje inny zespół, uzgodnij z nim okno czasowe, zanim cokolwiek usuniesz.

Kiedy samą bramę trzeba odbudować

Druga odpowiedź krążąca wokół tego problemu mówi, że bramę trzeba odtworzyć, a klucz ponownie wymienić. To prawda dla innego zestawu operacji: zmiany typu bramy lub SKU, przejścia między punktem a lokacją i lokacją a lokacją, albo naprawy bramy, której własna konfiguracja jest błędna. Takie zmiany rzeczywiście modyfikują zasób bramy, więc odbudowa jest naprawdę konieczna.

Bramie utworzonej dla punktu do lokacji nie można po prostu przypisać połączenia lokacja do lokacji. Konfigurację punktu do lokacji trzeba usunąć, a bramę odtworzyć, co daje też nowy współdzielony klucz i nowy pakiet klienta.

Pakiet punktu do lokacji zasługuje na osobną uwagę, ponieważ wygasa. Portal generuje plik o krótkim czasie życia, więc praktyczne podejście to pobrać go raz i rozdać razem z certyfikatem klienta, zamiast wysyłać użytkownikom link do portalu, który będzie martwy, gdy klikną. W kwestii prefiksu nic z tego nie ma zastosowania. Trzymanie obu procedur osobno to cała dyscyplina: prefiksy to zmiana na poziomie połączenia, a właściwości bramy to zmiana na poziomie bramy.

Czytaj stan, nie odznakę portalu

Czytaj stan z zasobu, a nie z odznaki w portalu. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 zwraca ConnectionStatus wraz z licznikami bajtów przychodzących i wychodzących, i to liczniki odróżniają tunel podłączony, który nic nie przenosi, od tego, który nigdy się nie ustanowił.

Liczniki, które przestają rosnąć w połowie transferu, wskazują na ścieżkę, a nie na uwierzytelnianie. Liczniki, które w ogóle się nie ruszają, wskazują na zestaw prefiksów lub współdzielony klucz.

Timery wyjaśniają klasę rozłączeń przypisywanych błędnie VPN-owi. Moduł równoważenia obciążenia Azure zamyka bezczynne przepływy po skonfigurowanym limicie czasu, domyślnie cztery minuty, gdy pisano te notatki, i można go zwiększyć, więc serwer OpenVPN na VM bez keepalive może padać co kilka minut, podczas gdy wszystko inne wygląda zdrowo. Brama, którą platforma cyklicznie restartuje, też może przerwać połączenie VNet z Web App, a ta awaria jest po stronie platformy, a nie w konfiguracji klienta. Wskazówką jest to, czy rozłączenie następuje w stałym odstępie, czy po zmianie, którą wprowadziłeś.

Trzymaj trzy obiekty i ich wartości w jednym zapisie: przestrzeń adresową sieci wirtualnej, listę prefiksów lokalnej bramy sieciowej i odwołanie do współdzielonego klucza połączenia. artykuł PowerShell o połączeniu lokacja do lokacji dokumentuje polecenia lokalnej bramy sieciowej i kolejność, do której należą. Porównywanie zmiany prefiksu z pamięcią to sposób, w jaki działający tunel jest odbudowywany dwa razy.

Następnie sprawdź w kolejności, w jakiej zmieniałeś: lokalna brama sieciowa pokazuje nową listę prefiksów, połączenie znów jest Connected, a liczniki się ruszają, gdy wysyłasz ruch do hosta w nowym zakresie. Jeśli trzeci krok zawiedzie, a pierwsze dwa przejdą, druga strona nie zaakceptowała nowego selektora ruchu i zdalne urządzenie potrzebuje odpowiedniego wpisu fazy 2. To rozmowa z drugim końcem tunelu, a nie kolejna zmiana w Azure.