VPN е свързан, но IP адресът не се е променил: защо

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

Потвърдете какво всъщност е измерил тестът

Адресът в диалога за Wi-Fi или Ethernet е адресът на интерфейса в собствения ви сегмент, а не адресът, който вижда сайтът, затова може да остане същият, докато тунелът работи безупречно. Местоположението отново е отделен сигнал: запазен регион на акаунта или разрешено геолокационно отчитане не се мести, когато смените изхода, нито вход, който вече ви разпознава.

Използвайте ехо на публичния адрес и питайте всяко семейство поотделно, защото резултатът от тест с двоен стек скрива интересния случай:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Изпълнете и двете преди и след свързване. Ако отговорът на IPv4 се смени с адреса на изхода, а отговорът на IPv6 не, нямате счупен тунел; имате едно семейство, което пътува извън него. Ако и двата отговора останат същите, заявката изобщо не е достигнала до тунела и останалото тук важи.

Профилът може да покрива само част от трафика

Профилът с разделен тунел е обичайният отговор и не е дефект. OpenVPN изпраща всичко през тунела само когато redirect-gateway е сред подадените опции; без него клиентът получава шепа конкретни маршрути и маршрутът ви по подразбиране остава на физическата връзка. В Windows същият превключвател се появява като „Използване на шлюз по подразбиране в отдалечена мрежа“ в свойствата на IPv4 на адаптера, а изключването му е съзнателен избор, който оцелява след всяко повторно свързване.

Обхватът по приложения е второто ниво. Настройката за VPN по приложения в Android решава кои приложения са включени, така че ключът за VPN в лентата на състоянието не доказва, че браузърът е вътре в него. Разширение за браузър, което проксира собствения си трафик, създава огледален образ: браузърът показва адреса на изхода, докато пощенски клиент или игра на същата машина все още показва вашия. Сравнете същата заявка в две приложения. Ако едното се промени, а другото не, гледате обхват, не провален тунел.

Едно семейство адреси все още може да минава директно

Повечето VPN профили са писани за IPv4 и много все още са такива. В мрежа с двоен стек тунелът взема 10.8.0.x за IPv4, докато физическата връзка запазва глобален адрес IPv6 и маршрут по подразбиране, така че сайт с поддръжка на IPv6 се достига директно и адресът, който той съобщава, е на вашия доставчик. Това е изтичане при работещ IPv4 тунел и е невидимо за тест, който говори само IPv4.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Прочетете интерфейса във всеки отговор. Ако търсенето на IPv6 посочва вашето Ethernet или Wi-Fi устройство, а търсенето на IPv4 посочва тунела, политиката за това семейство липсва, а не е счупена. Изключването на IPv6 за цялото устройство премахва симптома и скрива решението; предпочитайте да поправите покритието на профила или да изключите семейството само за тази връзка и запишете кое от двете сте избрали.

Втори път може да спечели търсенето

Конкуриращо прокси, втори VPN клиент, виртуален адаптер от контейнер или инструмент за отдалечен работен плот, или допълнителен маршрут за точния префикс, който тествате, всички могат да получат предимство. Конкретният маршрут винаги побеждава маршрута по подразбиране, затова остатъчен /24 за сайта, който измервате, сочещ към вашия LAN шлюз, продължава да изпраща този трафик извън тунела, колкото и здрав да е тунелът.

Направете опис, преди да промените нещо, с команди само за четене:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

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

Измерете отново с нова заявка

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

Дръжте двата изхода отделно. Ако адресът се промени, но един сайт все още ви отказва, тунелът работи и сайтът отхвърля адрес на център за данни; това е различен проблем с различен отговор. Ако адресът никога не се промени, минавете четирите въпроса по ред: кой адрес отпечата тестът, кое семейство беше, кое приложение направи заявката и кой маршрут следваше тази заявка. Документацията на Microsoft за решенията за маршрутизиране на VPN обяснява как Windows клиент избира между тунела и физическия адаптер, когато и двата имат маршрут.