OpenVPN не се свързва в хотелски Wi-Fi? Опитайте TCP 443

Отворете клиента, натиснете Connect и прочетете реда със състоянието, вместо диалога, който го следва. Профил, който засяда на Connecting или Waiting for server след хотелска, кампусна или мобилна мрежа, обикновено е загубил транспорта си някъде по пътя, а не идентификационните си данни. Полезната следваща стъпка е да разберете какво носи тази мрежа, преди да пипате сървъра. Не променяйте нищо, докато същият профил не проработи другаде.

Първо тествайте от мобилен hotspot. Ако тунелът тръгне там, сървърът, сертификатът и акаунтът са наред и единствената останала променлива е мрежата пред вас.

Започнете от клиента: прочетете реда със състоянието

Редът със състоянието показва кой етап е пропаднал. Клиент, заседнал на Connecting, още резолвва хоста или отваря външния сокет; този, който стига до Waiting for server, има път, но няма отговор; този, който се удостовери и след това прекъсне, има съвсем друг проблем. Клиентският лог и собствените полета 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 по подразбиране за всичко, което още го пропуска.

Запишете избора в името на профила и в бележките за поддръжка: кой порт, кой протокол и коя мрежа го наложи. После попитайте администратора на мрежата дали този порт остава отворен след следващото обновяване на оборудването, защото резерва, който тихо изчезва, е по-лош от никакъв резерв.