Azure P2S: в одного клієнта Windows зникли маршрути після зміни VNet

Два ноутбуки проходять автентифікацію на одному й тому самому шлюзі Azure point-to-site, і лише один досягає щойно підключеної VNet. Обидва показують Connected, отже автентифікація не є відмінністю; відмінність — це маршрути до призначення, які вони тримають. Почніть із клієнта, що зазнає невдачі, порівняйте одне призначення й лише потім вирішуйте, кому належить прогалина — пакету шлюзу чи локальній таблиці маршрутів.

Почніть із клієнта, що зазнає невдачі, а не зі шлюзу

Підтвердьте топологію, перш ніж звинувачувати ноутбук. Перевірте, які VNet підключені до VNet шлюзу і чи нова мережа доступна напряму через піринг, чи через окремий тунель site-to-site. Якщо нова VNet узагалі не підключена до VNet шлюзу, жоден клієнтський пакет не може туди маршрутизувати, і робочий ноутбук — це аномалія, яку треба пояснити. Запишіть відповідь, бо вона визначає, чи ви налагоджуєте клієнт, чи шлюз.

Коли топологія правильна, поставте два ноутбуки поруч. Той самий шлюз, той самий пул адрес, той самий протокол і та сама збірка клієнта — це порівняння, яке вам потрібне; усе інше буде другою змінною, яку доведеться виключити пізніше.

Порівняйте одне призначення за допомогою route print

Виберіть дозволену IP-адресу ресурсу й порівняйте обидва ноутбуки двічі: у відключеному стані, потім у підключеному. У Windows route print -4 виводить маршрути IPv4 з префіксом призначення, інтерфейсом, наступним вузлом і метрикою. Запишіть рядок, який справді переміг би для цього призначення, замість того щоб рахувати записи зі словом VPN.

Вибір відбувається спершу за найдовшим префіксом, потім за метрикою, тому конкретніший локальний маршрут може перемогти тунельний, не виглядаючи помилковим. Якщо цільове призначення всередині 10.24.0.0/16, здоровий клієнт показує відповідний маршрут на інтерфейсі VPN, а клієнт, що зазнає невдачі, надсилає ту саму адресу на свій шлюз за замовчуванням.

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

TTL expired — це не помилка розповсюдження маршрутів

Ping, що повертає TTL expired in transit, каже, що пакет вичерпав ліміт переходів, а це зазвичай означає петлю пересилання, а не зламаний драйвер VPN. Ping у Windows приймає TTL до 255, і збільшення значення не виправляє петлю; воно лише відкладає ту саму помилку. Ставтеся до повідомлення як до симптому шляху, а не як до доказу щодо розповсюдження маршрутів.

Скористайтеся tracert -4 10.24.1.10, щоб побачити, де шлях повторюється. Якщо ті самі два переходи з'являються знову й знову, шукайте маршрут, який повертає трафік, спрямований у тунель, назад у тунель або в локальний маршрутизатор, що відсилає його назад.

Пересворіть пакет на шлюзі, якому він належить

Microsoft документує, що клієнтські пакети Windows потрібно повторно завантажити й установити після значущих змін топології. Візьміть поточний пакет зі шлюзу Azure, що обслуговує цей профіль, а потім застосуйте його підтримуваною процедурою для цього клієнта. Заміна виконуваного файлу стороннього VPN-застосунку — не та сама операція, що пересворення налаштувань, специфічних для шлюзу. Завантажити пакет знову дешево; вгадувати локальні маршрути — ні.

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

Сценарії маршрутизації Azure P2S відокремлюють напряму пірінгові VNet від мереж, доступних через інші тунелі, і новий пакет не може зробити піринг транзитивним. Деякі сценарії Windows site-to-site або BGP також потребують вручну налаштованих віддалених маршрутів, тож оновлення пакета не є універсальним механізмом розповсюдження маршрутів.

Тримайте тимчасовий маршрут тимчасовим

Ручний маршрут може ізолювати відсутній маршрут клієнта, але будуйте його з реального проєкту: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, без прапорця постійності, щоб він зник під час перезавантаження. Індекс інтерфейсу й наступний вузол вибирайте за підключеним адаптером VPN, а не навмання.

Не залишайте експериментальний маршрут постійним конкуруючим власником. Майбутні оновлення профілю можуть додати той самий префікс з іншою метрикою, і тоді ручний запис мовчки вирішить, який шлях переможе. Запишіть крок видалення у зміні.

Коли правильний маршрут активний, перевіряйте цільовий застосунок, а не ping. Якщо пакети доходять до Azure, але служба все ще не працює, перевірте групу безпеки мережі та зворотний шлях, бо вони не залежать від того, чи ноутбук вивчив префікс.