VPN е свързан, но няма интернет? Проверете четирите слоя

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

Започнете от мрежата, от която сте дошли

Прекъснете тунела със собствената контрола за прекъсване на клиента, след което опитайте два несвързани HTTPS сайта, ако политиката позволява. Оставете чувствителната работа затворена за времетраенето на теста. Ако и обикновеният достъп се проваля, VPN не е първият заподозрян.

Погледнете Wi-Fi връзката, рутера и всяка портална страница, която изисква вход, преди да пипате тунела. Kill switch може да блокира трафика при прекъсване по проект, затова следвайте документираната му процедура за тестване, вместо да заключавате, че мрежата е мъртва. Друга доверена мрежа е полезно сравнение, а нов VPN изход няма да довърши изтекъл хотелски вход. Ако отворената мрежа работи, а тунелът не, мрежата е оправдана и следващият слой е ваш.

Определете дали отказът е в разрешаването на имена

Запишете текста на грешката, защото отказ при разрешаване, изчакване и предупреждение за сертификат сочат всяко на друго място. Моделът, който да хванете рано, е име на хост, което никога не сте посещавали, да се проваля, докато приложение с отворена сесия продължава. Този модел е за нови заявки, а не за това дали тунелът носи пакети. Единична заявка показва какво връща резолверът и отнема секунда. Опитайте и второ име, за да не реши диагнозата един кеширан отговор или един повреден запис.

nslookup example.com

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

Пълен тунел или само фирмени подмрежи

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

По-конкретен маршрут може да победи, докато маршрутът по подразбиране още съществува, затова таблицата трябва да се чете, а не да се предполага. Конкуриращи се виртуални адаптери също могат да притежават трафик, който сте очаквали другаде, особено след като втори VPN клиент е бил инсталиран и забравен. Не изтривайте маршрута по подразбиране като експеримент; това превръща диагнозата във втори срив.

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

Когато сървърът никога не препраща нищо

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

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

Прегледайте клиентския журнал след вход за откази при прилагане на маршрути, DNS настройки или виртуалния адаптер. Грешките на този етап сочат към устройството, а не към сървъра. Грешка, която никога не се появява в журнала, е също толкова информативна, защото премества подозрението на другата страна.

Проверявайте един слой наведнъж

След като промените нещо, свържете се отново и повторете точно приложението, което се провали. Една заредена страница доказва по-малко от повтаряем път до ресурсите, за които е създаден профилът. Две команди разделят разрешаването от достъпността и втората е специфична за хоста. Изпълнете реда curl навсякъде, след което изпълнете командата за маршрути, която отговаря на хоста пред вас.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

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