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 оставете го како стандард за сѐ што сѐ уште го пропушта.

Запишете го изборот во името на профилот и во белешките за поддршка: кој порт, кој протокол и која мрежа го предизвика. Потоа прашајте го администраторот на мрежата дали тој порт ќе остане отворен по следната замена на опрема, зашто резерва што тивко исчезнува е полоша отколку воопшто да нема резерва.