OpenVPN не підключається у Wi-Fi готелю? Спробуйте TCP 443

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

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

Почніть із клієнта: прочитайте рядок стану

Рядок стану каже, на якому етапі стався збій. Клієнт, що застряг на «Підключення», ще розв'язує ім'я вузла або відкриває зовнішній сокет; той, що доходить до «Очікування сервера», має шлях, але не має відповіді; той, що проходить автентифікацію і потім падає, має зовсім іншу проблему. Журнал клієнта й власні поля remote та proto профілю показують, що клієнт намагається зробити, а --verb 4 у клієнті командного рядка друкує ті самі подробиці. Саме порівняння цього з мережею перед вами перетворює «VPN заблоковано» на конкретне твердження.

Потім перевірте мережу інструментами, які вже маєте. nc -vzu 203.0.113.10 1194 надсилає UDP-дейтаграму, curl -v telnet://203.0.113.10:443 повідомляє, чи завершується рукостискання TCP, а браузер, що завантажує сторінку HTTPS, доводить лише те, що вихідний 443 досягає цього одного вузла. Невеликі перевірки відповідають на те, чого не може клієнт VPN: який порт і який протокол узагалі залишають цю мережу.

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

Переносьте слухач і профіль разом

На боці сервера задайте слухач так, як дозволяє мережа: port 443 і proto tcp у конфігурації сервера, потім перезапустіть службу й підтвердьте сокет за допомогою ss -lntp. На боці клієнта профіль має погодитися, бо транспорт і порт стоять поза тунелем: proto tcp і port 443 у .ovpn або відповідні поля на екрані налаштувань застосунку. Профіль, досі націлений на UDP 1194, зазнає невдачі точно як раніше, і з'являється спокуса звинуватити вже виправлений брандмауер. Якщо той самий вузол відповідає й через HTTPS на 443, два слухачі не можуть ділити цю адресу й протокол; дайте VPN другу адресу або поставте попереду демультиплексор.

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

Коли з мережі виходить лише проксі

Деякі гостьові мережі не дозволяють нічого, крім HTTP-проксі, — це інше обмеження, ніж закритий порт, і воно виключає більше, ніж OpenVPN. Клієнти, що говорять лише PPTP, L2TP/IPsec або голим IPsec, не мають шляху крізь нього, бо такі рішення розраховують, що їхній зовнішній протокол дійде до сервера напряму. OpenVPN може, з http-proxy proxy.example.net 8080 у профілі клієнта, за умови що проксі дозволяє метод CONNECT на ваш порт. Проксі SOCKS ще простіше, бо пересилає потік, не переймаючись тим, що всередині.

Там, де клієнт не підтримує проксі, зазвичай залишається SSH-тунель поверх 443. Він додає другий шар, і оператор мережі може мати щодо цього думку, тож ставтеся до нього як до мосту для однієї поїздки, а не як до архітектури.

Оцініть ціну запасного шляху, перш ніж залишати його

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

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