Няма интернет при Windows VPN? Заподозреният е пулът с адреси

Windows показва тунела като свързан и го обозначава като Без достъп до интернет, което хората приемат за прищявка на Windows. Това е твърдение за това какво е получил клиентът: няма използваем шлюз по подразбиране, няма работещ резолвер и няма път обратно за адресите вътре в тунела. Когато сървърът е Windows Incoming Connection, една настройка обяснява повечето такива сигнали. Етикетът не е диагноза, но стеснява търсенето до три места.

Прочетете лизинга, преди да го промените

Изпълнете ipconfig /all на клиента и намерете VPN адаптера сред записите. Адресът, шлюзът по подразбиране и DNS сървърът, които той изброява, са фактите, които ви трябват, и те често се различават от това, което администраторът предполага, че е било раздадено.

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

Запишете стойностите, преди да пипате сървъра. Следващата стъпка ги сравнява с обхвата, който сървърът смята, че раздава, а паметта е лош заместител на лизинга.

Защо автоматичното назначаване може да остави без шлюз

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

На самостоятелна работна станция този разпределител няма обхват, от който да черпи, освен ако нещо друго на машината не предоставя такъв, така че клиентът може да остане с локален адрес за връзка или с адрес, но без шлюз. Връзката изглежда установена, защото връзката се е вдигнала, докато конфигурацията зад нея е непълна.

Ето защо преминаването към зададен обхват поправя толкова много от тези сигнали. Спирате да искате от услуга, която може да не работи, да измисли лизинг и започвате сами да задавате лизинга.

Същото объркване се появява, когато някой очаква 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, което е IP протокол 47, а не порт; L2TP/IPsec иска UDP 1701 плюс 500 и 4500; SSTP иска TCP 443.

Рутер, който препраща порта, но не и протокола, произвежда опит за връзка, който никога не се автентикира. Това е различна повреда от тунел, който се оформя и след това не достига доникъде, и двете не бива да се отстраняват заедно.

Тествайте от същия LAN и от отдалечената мрежа. Ако опитът от LAN работи, а отдалеченият никога не стига до автентикация, проблемът е във външния път. Ако и двата се автентикират и само отдалеченият клиент няма интернет, върнете се към пула и изхода.