Чому додавання префікса Azure VPN розриває з'єднання

Префікс, доданий до неправильного об'єкта Azure, дає з'єднання, яке повідомляє Connected і нічого не передає, і це найдорожчий вид помилки в цьому стеку. Задіяні три ресурси, і лише один із них володіє віддаленим адресним простором: шлюз віртуальної мережі, локальний мережевий шлюз, що описує віддалений бік, і з'єднання, яке їх поєднує. Префікс належить локальному мережевому шлюзу, з'єднання потрібно перебудувати, щоб зміна набула чинності, а сам шлюз зазвичай залишається недоторканим. Порядок не обговорюється, і портал показує лише частину його.

Три об'єкти, один з яких зберігає префікс

Адресний простір віртуальної мережі відповідає на інше питання: що живе всередині Azure. Додавання віддаленого префікса там не спрямовує трафік туди, воно лише розширює простір, який платформа вважає своїм, а це може конфліктувати з реальним віддаленим діапазоном. Локальний мережевий шлюз — це об'єкт, який зберігає віддалені префікси, а з'єднання посилається на обидва шлюзи плюс заздалегідь спільний ключ.

Є й третє застереження, яке варто пам'ятати. GatewaySubnet розміщує керовані екземпляри шлюзу, має носити саме це ім'я, і для SKU, що не є Basic, очікується, що він буде щонайменше /27.

Ніщо інше не належить до цієї підмережі, і зміна префікса не має причин її торкатися. Префікс, якого немає в локальному мережевому шлюзі, недосяжний, хоч би що казав стан з'єднання, бо шлюз пропонує лише ті префікси, про які його повідомили під час узгодження тунелю. Тому симптом асиметричний: тунель піднято, асоціація безпеки в порядку, і одна підмережа ніколи не з'являється в селекторах трафіку. Якщо одного віддаленого діапазону бракує, поки сусідні працюють, перестаньте дивитися на тунель і прочитайте локальний мережевий шлюз.

Чому видаляється саме з'єднання

Об'єкт з'єднання фіксує узгоджену конфігурацію на весь термін свого життя. Тому документована процедура спершу видаляє з'єднання, оновлює локальний мережевий шлюз, а потім створює з'єднання заново з тим самим спільним ключем. Екземпляри шлюзу не перебудовуються заради зміни лише префікса, що обмежує простій розбиранням з'єднання, а не повторним розгортанням шлюзу.

Це видалення і є простій, тому ставтеся до нього як до планової зміни з початком і очікуваним кінцем, а не як до швидкої правки. У PowerShell послідовність коротка: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, потім Set-AzLocalNetworkGateway з новим -AddressPrefix масивом, потім New-AzVirtualNetworkGatewayConnection з тим самим -SharedKey і тими самими шлюзами. Повторне використання ключа важливе, бо віддалений бік не переналаштовується, і новий ключ означає узгодження з тим, хто володіє віддаленим пристроєм. Якщо цей пристрій обслуговує інша команда, узгодьте з нею вікно, перш ніж щось видаляти.

Коли треба перебудовувати сам шлюз

Друга відповідь, що ходить навколо цієї проблеми, каже, що шлюз треба створити заново й ключ знову обміняти. Це правильно для іншого набору операцій: зміни типу шлюзу або SKU, переходу між «точка — сайт» і «сайт — сайт» або ремонту шлюзу, чия власна конфігурація хибна. Такі зміни справді змінюють ресурс шлюзу, тому перебудова справді потрібна.

Шлюзу, створеному для «точка — сайт», не можна просто призначити з'єднання «сайт — сайт». Конфігурацію «точка — сайт» треба видалити, а шлюз створити заново, що також дає новий спільний ключ і новий клієнтський пакет.

Пакет «точка — сайт» заслуговує на окрему примітку, бо він спливає. Портал створює файл із коротким терміном життя, тому практичний підхід — завантажити його один раз і розповсюдити разом із клієнтським сертифікатом, а не надсилати користувачам посилання на портал, яке буде мертвим на момент кліку. Щодо питання префікса, ніщо з цього не застосовується. Тримати дві процедури окремо — уся дисципліна: префікси — це зміна на рівні з'єднання, а властивості шлюзу — зміна на рівні шлюзу.

Читайте стан, а не значок порталу

Читайте стан із ресурсу, а не зі значка на порталі. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 повертає ConnectionStatus разом із лічильниками вхідних і вихідних байтів, і саме лічильники відрізняють підключений тунель, який нічого не несе, від того, що так і не встановився.

Лічильники, які перестають зростати посеред передавання, вказують на шлях, а не на автентифікацію. Лічильники, які взагалі не рухаються, вказують на набір префіксів або спільний ключ.

Таймери пояснюють клас відключень, які помилково приписують VPN. Балансувальник навантаження Azure закриває неактивні потоки після налаштованого тайм-ауту, за замовчуванням чотири хвилини на момент написання цих нотаток, і його можна збільшити, тож сервер OpenVPN на віртуальній машині без keepalive може падати кожні кілька хвилин, поки все інше виглядає здоровим. Шлюз, який платформа перезапускає циклічно, також може перервати з'єднання VNet із Web App, і ця невдача на боці платформи, а не в клієнтській конфігурації. Ознака — чи відключення йде через фіксований інтервал, чи через зміну, яку зробили ви.

Тримайте три об'єкти та їхні значення в одному записі: адресний простір віртуальної мережі, список префіксів локального мережевого шлюзу та посилання на спільний ключ з'єднання. стаття PowerShell про «сайт — сайт» документує команди локального мережевого шлюзу та порядок, до якого вони належать. Порівняння зміни префікса з пам'яттю — це спосіб двічі перебудувати робочий тунель.

Потім перевірте в тому порядку, у якому змінювали: локальний мережевий шлюз показує новий список префіксів, з'єднання знову Connected, а лічильники рухаються, коли ви надсилаєте трафік на хост у новому діапазоні. Якщо третій крок не вдається, поки перші два проходять, віддалений бік не прийняв новий селектор трафіку, і віддаленому пристрою потрібен відповідний запис фази 2. Це розмова з іншим кінцем тунелю, а не ще одна зміна в Azure.