VPN заблоковано в мережі лише для вебу? Пройдіть рівні

Браузер працює, тунель помирає. Прочитайте фази часу curl, перевірте проксі, з'ясуйте, чи справді дозволено 443, а потім зафіксуйте, що залишило машину.

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

Доведіть, який рівень відхиляє з'єднання

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

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Немає відповіді й немає часу connect — отже, TCP так і не завершився, тому в грі міжмережевий екран, вимога проксі або хибна ціль. Час connect без часу tls — отже, щось посередині прийняло з'єднання й затримало рукостискання, саме так виглядає інспектуючий проксі з боку клієнта.

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

Клієнт, який знає про проксі, змінює перший пакет, а не політику

Якщо мережа вимагає CONNECT через автентифікований проксі, про це треба сказати VPN-клієнту, інакше він спробує відкрити сокет на адресу, яку не може маршрутизувати. Перевіряйте проксі окремо від клієнта, щоб у збою було одне пояснення:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

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

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

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

Порт 443 доступний, але не дозволений

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

Є й ціна продуктивності, яку люди виявляють пізніше. Надійний транспорт усередині надійного транспорту підсилює втрати, бо внутрішній стек повторно надсилає сегменти, які зовнішній уже повторно надіслав. На чистому каналі цього ніхто не помічає. У перевантаженій кампусній бездротовій мережі тунель стає непридатним саме тоді, коли він потрібен, і графік виглядає як втрата пакетів, хоча нічого не відкидається навмисно.

UDP зазвичай перша жертва, і це варто підтвердити, а не припускати. Якщо WireGuard або типовий OpenVPN ніколи не завершує рукостискання, поки TCP 443 працює, мережа відкидає UDP, і жодна регенерація ключів цього не змінить:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Порожня позначка часу рукостискання біля піра, який працював учора, — це відповідь про UDP. Два запити DNS відповідають на інше питання: якщо локальний резолвер і публічний резолвер розходяться щодо адреси кінцевої точки, вас скеровують, і аргумент про транспорт неправильний.

Перевірте, що насправді залишило машину

Журнали клієнта описують, у що клієнт вірить. Перехоплення описує, що бачила мережа, і різниця між ними — те місце, де вирішується більшість таких випадків:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

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

Відкат і нотатка, яку варто зберегти

Скасуйте зміни в зворотному порядку до того, в якому ви їх робили. Зніміть змінні проксі, зупиніть клієнт, запущений вручну, і приберіть будь-яке перевизначення маршруту або резолвера, яке ви додали:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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

Схожі статті