Немає інтернету в Windows VPN? Підозрюваний — пул адрес

Windows показує тунель як підключений і позначає його Немає доступу до інтернету, що люди сприймають як особливість Windows. Це твердження про те, що отримав клієнт: немає придатного шлюзу за замовчуванням, немає робочого розв'язувача або немає зворотного шляху для адрес усередині тунелю. Коли сервер — це Windows Incoming Connection, одне налаштування пояснює більшість таких звітів. Мітка не діагноз, але вона звужує пошук до трьох місць.

Прочитайте оренду, перш ніж її змінити

Запустіть ipconfig /all на клієнті й знайдіть адаптер VPN серед записів. Зазначені в ньому адреса, шлюз за замовчуванням і DNS-сервер — це потрібні вам факти, і вони часто відрізняються від того, що адміністратор вважає виданим.

Три шаблони відповідають трьом несправностям. Адреса в 169.254.0.0/16 означає, що клієнт не отримав нічого й сам призначив собі link-local адресу. Правдоподібна адреса без шлюзу означає, що пул було видано без параметра, який дає клієнту маршрут за замовчуванням. Повна оренда, яка все одно нікуди не потрапляє, вказує на пересилання або трансляцію на боці сервера.

Запишіть значення, перш ніж торкатися сервера. Наступний крок порівнює їх із діапазоном, який сервер вважає видаваним, а пам'ять — погана заміна оренді.

Чому автоматичне призначення може залишити без шлюзу

Запис Incoming Connections має власні властивості IPv4, окремі від фізичного адаптера. Налаштування за замовчуванням там пропонує призначати адреси автоматично, що покладається на вбудований розподілювач з'єднання для видачі адреси, маски, шлюзу й DNS.

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

Тому перехід на заданий діапазон виправляє так багато таких звітів. Ви перестаєте просити службу, яка, можливо, не працює, вигадати оренду й починаєте вказувати оренду самі.

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

Задайте явний діапазон, який сервер може маршрутизувати

Виберіть невеликий блок усередині підмережі, доступної серверу, поза діапазоном, який роздає LAN-маршрутизатор, і поза будь-яким іншим пулом у мережі. Якщо сервер перебуває на 172.20.10.0/24, а маршрутизатор тримає 172.20.10.1, короткий блок біля верхнього краю цієї підмережі, скажімо з 172.20.10.201 по 172.20.10.209, тримає оренди тунелю подалі від роздачі, якою маршрутизатор уже керує.

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

Ці команди друкують отриману конфігурацію й маршрути, які клієнт тепер має:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Шлюз в оренді має бути адресою, якою володіє сервер, а маршрут за замовчуванням клієнта має вказувати на неї. Якщо оренда повна, але маршруту немає, сервер призначив, не проштовхнувши шлюз, і налаштування пулу все ще те місце, де варто дивитися.

Адреса — це не шлях в інтернет

Отримання оренди лише переміщує пакети від клієнта до сервера. Для доступу в інтернет сервер має пересилати ці пакети й транслювати їх у бік свого аплінку, і це окрема конфігурація з власними режимами відмови.

Internet Connection Sharing — короткий шлях. Він перетворює адаптер, спрямований в інтернет, на спільний шлюз і веде власну адресацію, що може переписати адресу цього адаптера й залишити наявне правило NAT, яке вказує на значення, якого більше немає. Запишіть початкові налаштування перед увімкненням.

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

Спершу виключіть зовнішній шлях

Жоден пул не допоможе, якщо тунель не формується. Протокол вирішує, що має нести шлях: PPTP хоче TCP 1723 і GRE, а GRE — це IP-протокол 47, а не порт; L2TP/IPsec хоче UDP 1701 плюс 500 і 4500; SSTP хоче TCP 443.

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

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