Чому портал авторизації блокує ваш VPN і як знову увійти

У відкритій мережі точка доступу не просто передає пакети в інтернет. Точка політики вище перевіряє, чи пристрій уже авторизовано, і доти майже все відкидається. Ваш VPN-клієнт читає цю тишу як мертвий сервер. Він рідко каже це прямо: WireGuard повторює рукостискання в порожнечу, OpenVPN повідомляє про вичерпання часу з'єднання, а IKEv2 повертається помилкою 809 про віддалений сервер, який не відповідає.

Що портал справді контролює

Портал авторизації — це дві склеєні речі: точка ухвалення політики та перенаправлювач. Коли пристрій під'єднується й отримує оренду DHCP, мережа ставить вас у стан до авторизації.

Цей стан — набір правил брандмауера. Зазвичай він пропускає DNS і дозволяє HTTP або HTTPS до короткого списку хостів порталу, а все інше відкидає. Дозволений список — це обгороджений сад, і VPN-ендпоінт до нього майже ніколи не входить.

Жодне з цих відкидань не є ввічливим. Пакети до VPN-сервера відкидаються, а не відхиляються, тому клієнт не отримує ні ICMP unreachable, ні TCP reset, лише відсутність відповіді. Залежно від виробника перенаправлювач може відповісти на порт 80 перенаправленням на сторінку входу, тоді як порт 443 відкидається або перехоплюється. Перенаправлення легко помітити, бо вони несуть звичайну відповідь HTTP; перехоплення на 443 потребує сертифіката, якому ваш браузер відмовиться довіряти.

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

Чому рукостискання VPN помирає, не почавшись

Кожен протокол має власний транспорт, і брандмауер до авторизації ламає кожен по-своєму. IKEv2 у Windows та iOS іде через UDP 500 і UDP 4500; відкидання на цих портах виявляється як 809 або як збій на кшталт розв'язання імен у клієнтів, які повідомляють про фази окремо. OpenVPN через UDP 1194 залишається в стані підключення, доки не вичерпається його час. OpenVPN через TCP 443 — цікавий випадок, бо портал може завершити рукостискання TCP і потім відповісти своєю сторінкою перенаправлення, тож ви бачите помилку TLS замість тайм-ауту.

WireGuard показує механізм найясніше. Він за задумом лише UDP, без резерву TCP, тому брандмауер, що відкидає невідомий UDP, повністю прибирає транспорт. Клієнт продовжує надсилати ініціації рукостискання зі зростаючою паузою і повідомляє про рукостискання, яке ніколи не завершується. Ніщо в цьому повідомленні не згадує Wi-Fi і ніщо не натякає, що треба відкрити браузер.

Платформи намагаються помітити стан раніше за ваш VPN. Windows запитує відомий URL, щоб вирішити, чи показувати сповіщення про вхід, Android запитує ендпоінт, який має відповісти 204 No Content, а пристрої Apple відкривають невелике вікно мережі з авторизацією. Ці проби працюють, бо портал відповідає перенаправленням замість очікуваного тіла. Та сама поведінка пояснює, чому портал може виглядати цілком здоровим, коли тунель мертвий: пробу й тунель оцінюють за різними правилами.

Що насправді скидає завершення сеансу

Заклади завершують сеанси з причин, не пов'язаних із вашим обліковим записом VPN: тайм-аут бездіяльності, максимальна тривалість сеансу, нова оренда DHCP або повторне під'єднання до іншої точки доступу. Коли таймер спрацьовує, запис у таблиці сеансів зникає, і набір правил до авторизації повертається точно таким, яким був під час входу.

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

У цей момент помилка клієнта каже, на якому етапі ви, якщо уважно її прочитати:

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

Спершу увійдіть, потім піднімайте тунель

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

Клієнт для настільного комп'ютера з опцією блокування поза тунелем потрібно призупинити, щоб сторінка порталу завантажилася, а чутливі застосунки варто тримати закритими в цьому вікні поза тунелем; це єдиний інтервал, коли локальний трафік виходить без захисту. Керований постійно ввімкнений пристрій має використовувати процедуру, опубліковану власником, а не те, що ви знімаєте політику. Якщо портал показує попередження про сертифікат, зупиніться: його прийняття спрямує сеанс через перехоплювальний проксі закладу, а той проксі зможе прочитати все, що ви надсилаєте. На Android блокування під постійно ввімкненим VPN зупиняє трафік до того, як тунель підніметься, і деякі збірки не вміють виключати потік порталу; якщо ваша не вміє, скористайтеся альтернативним доступом закладу або іншим пристроєм, а не залишайте блокування вимкненим. Правила on-demand від Apple можна написати так, щоб тунель відхилявся до успішної проби, і це та поведінка, яка потрібна в готельних мережах.

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

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

До авторизації звичайний портал дає одну з двох відповідей: 302, чий Location вказує на сторінку входу, або 200 з тілом HTML, яке є сторінкою порталу. Запишіть, яку отримали. Перенаправлення до входу — не збій; портал каже, куди йти. Після того як портал повідомить про успіх, повторіть команду й очікуйте 200, тіло якого — буквально слово Success. Саме цей рядок робить пробу осмисленою. Якщо хост відповідає звичайно ще до того, як ви коли-небудь увійшли, у цій мережі немає перехоплювального порталу. У записі відкидання до авторизації — це вихідні пакети, з яких нічого не повертається, тоді як робочий шлях показує відповідь на той самий потік приблизно за секунду. Під'єднайтеся й потім повторіть запис.

Якщо тунель усе одно не працює після того, як портал сказав так

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

Інші збої живуть на пристрої. Сеанс, досі прив'язаний до старого MAC, другий адаптер Wi-Fi зі своєю орендою або клієнт, що закешував виняток сертифіката порталу, можуть і далі зазнавати невдач після чистого повторного авторизування. Розірвіть зв'язок, авторизуйтеся заново й спробуйте один раз, перш ніж торкатися налаштувань клієнта. RFC 8952 варто прочитати, якщо потрібна архітектура за компонентами, які ви спостерігаєте.

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

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