OpenVPN не падключаецца ў гатэльным Wi-Fi? Паспрабуйце TCP 443

Адкрыйце кліент, націсніце Connect і чытайце радок стану, а не дыялогавае акно, якое ідзе за ім. Профіль, што спыняецца на Connecting або Waiting for server пасля гатэльнай, кампуснай ці мабільнай сеткі, звычайна страціў транспарт недзе на шляху, а не свае ўліковыя даныя. Карысны наступны крок — даведацца, што гэтая сетка прапускае, перш чым кранаць сервер. Нічога не змяняйце, пакуль той жа профіль не запрацуе ў іншым месцы.

Спачатку праверце з кропкі доступу тэлефона. Калі тунель там уздымаецца, сервер, сертыфікат і ўліковы запіс у парадку, і адзіная зменная, што засталася, — сетка перад вамі.

Пачніце з кліента: прачытайце радок стану

Радок стану кажа, на якім этапе адбыўся збой. Кліент, які засеў на 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 прадвызначаным для ўсяго, што яшчэ яго прапускае.

Запішыце выбар у назве профілю і ў нататках падтрымкі: які порт, які пратакол і якая сетка яго выклікала. Затым спытайце адміністратара сеткі, ці застанецца гэты порт адкрытым пасля наступнага абнаўлення абсталявання, бо рэзерв, які маўкліва знікае, горш за адсутнасць рэзерву.