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

Розв'яжіть ім'я, яке не відкривається, потім дивіться в таблицю маршрутизації, а не в браузер.

Порівнюйте адресу, а не ім'я сайту

Знайдіть адресу, яку клієнт справді пробував, потім перевірте, який маршрут їй відповідає. Призначення всередині 45.61.20.10 потрапляє під 45.0.0.0/8, якщо цей префікс присутній, навіть якщо сам сайт ніяк не пов'язаний з тунелем. Порівняння проблемної адреси зі встановленими префіксами — це задача на віднімання, а не здогад.

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

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Читайте найконкретніший відповідний префікс, а не перший знайомий рядок. Маршрут у таблиці не доводить, що він виграв пошук; це робить найдовший збіг. Два префікси можуть відповідати одній адресі, і лише один із них отримує пакет. Той, хто програв, залишається в таблиці й у списку виглядає так само реально.

Запишіть префікс, його інтерфейс і розв'язану адресу. Ці три значення — увесь діагноз.

З'ясуйте, хто встановив маршрут

Маршрути надходять із чотирьох місць: із власного профілю VPN, із політики керування, зі скрипта підключення або з зовсім іншого клієнта. Видалення активної таблиці може підтвердити її значущість, але наступне підключення створить її заново зі збереженої конфігурації, тому змінювати треба джерело.

Спершу перевірте список маршрутів профілю, потім політику керування, потім будь-який скрипт, що виконується під час підключення. Цей порядок відповідає тому, як часто кожен із них виявляється винним. Він також утримує зміну в одному шарі замість трьох.

Уважно прочитайте власну поведінку на основі класів

Власні профілі Windows мають задокументований параметр NativeProfile/DisableClassBasedDefaultRoute, який керує автоматичним маршрутом, виведеним з адреси інтерфейсу. Адреса профілю, що починається з 45, за такої поведінки може створити запис 45.0.0.0/8, і так одна публічна адреса захоплює весь діапазон класу A.

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

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

Виправте джерело, потім знову перевірте обидва шляхи

Після зміни підключіться знову й повторіть пошук для проблемного публічного сайту та для ресурсу, який має використовувати тунель. Перший тепер має розв'язуватися на фізичний інтерфейс, а другий має й далі вибирати VPN. Не зупиняйтеся на першому успіху; виправлення, яке ламає й приватний доступ, обміняло одну несправність на іншу.

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

Підвищення MTU або очищення DNS не виправить префікс, який досі спрямовує цю адресу в тунель. Спершу перевірте вибір, потім шлях.

Схожі статті