VPN підключається вдома, але у Wi-Fi готелю час очікування спливає

Ноутбук підключається до домашнього Wi-Fi, клієнт з'єднується за три секунди, а той самий профіль через годину не працює в готелі. Між цим нічого не оновлювалося. Розбирати це з клієнтом перед собою — передусім розуміти, яка помилка належить якому етапу, бо корисна інформація в коді, який друкує клієнт, а не в самому факті збою. Пройдіть чотири кроки нижче по порядку, і ви дізнаєтеся, хто вас відхилив: ім'я, пакет, порт чи політика.

Читайте код помилки як етап, а не як вирок

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

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

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

Перевірте ім'я, перш ніж звинувачувати тунель

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

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

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

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

З'ясуйте, який зовнішній пакет зникає

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

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

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

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

Змініть один транспорт і перевірте знову

Коли ви знаєте, що зовнішній потік відкидається, практичне питання — який потік мережа все ж дозволяє. Більшість обмежених мереж дозволяють вихідний TCP 443, бо інакше вони не можуть працювати, тому перенесення слухача туди — звичайна відповідь. На OpenVPN це перемикач на боці клієнта, доки сервер не змінено:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

У клієнтів IPsec є еквівалентний перемикач у їхніх власних панелях налаштувань, зазвичай описаний як IPsec поверх TCP або проходження NAT. Його зміна — теж діагностика: якщо тунель піднімається поверх TCP і вмирає поверх UDP, ви довели, що мережа фільтрує UDP, і знайшли налаштування, яке знадобиться під час кожного відвідування того місця.

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

Перевірте той самий профіль у другій мережі

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

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

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

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