Чому профіль OpenVPN працює вдома, але не працює в готелі

Офісний Wi-Fi і готельний номер можуть дати одному й тому самому ноутбуку дві зовсім різні мережі, а профіль між ними про це нічого не знає. Те, що працює вдома, припускає поступливий висхідний канал, робоче розв'язання імен і локальну підмережу, що не перетинається з нічим, що несе тунель. Кожне з цих припущень може відмовити окремо.

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

Чотири мережеві факти змінюються між місцями

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

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

Третій — фільтрування транспорту. Мережі, які хочуть дозволяти лише перегляд, пропускають TCP 443 до довільних призначень і відкидають майже все інше, включно з UDP.

Четвертий — адресація. Локальна підмережа може перетинатися з мережею за тунелем, або висхідний канал узагалі не дає придатного шляху IPv4.

Розв'язання імен і портал входу

Замініть ім'я хоста в профілі на числову адресу сервера й спробуйте ще раз. Якщо IP з'єднується, а ім'я ні, винне розв'язання імен, а сам профіль гаразд.

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

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

Фільтрування транспорту: спершу UDP, TCP 443 як резерв

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

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

Очікуйте ціну в продуктивності. TCP усередині TCP підсилює повторні передачі на каналі з втратами, тож робочий TCP-тунель у перевантаженій готельній мережі все одно може здаватися повільним. Це обмін на доступність, а не дефект, за яким треба гнатися.

Конфлікти адрес і висхідні канали без IPv4

Тунель може встановитися й усе одно нічого не передавати. Коли локальна LAN і віддалена мережа ділять префікс на кшталт 192.168.1.0/24, клієнт вважає віддалений хост підключеним напряму й надсилає пакет до локальної ланки замість тунелю. Симптом — успішне з'єднання з однією недосяжною підмережею, яке легко прочитати неправильно як проблему маршруту на боці сервера.

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

Мобільні висхідні канали додають два варіанти. NAT на рівні оператора означає, що вхідні з'єднання не доходять, що важливо, якщо ви розміщуєте сервер, але не для вихідного клієнта. APN, налаштований лише з IPv6 і трансляцією NAT64, може підвести клієнта, який вимагає справжнього шляху IPv4, і звичайні ліки — змінити протокол APN на IPv4 або подвійний стек.

Симптоми після підняття тунелю

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

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