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

Міф: гатэль блакуе VPN

Большасць гатэльных сетак не фільтруе тунэлі спецыяльна. Яны перахопліваюць вэб-трафік, пакуль госць не аўтэнтыфікуецца, і могуць таксама абмяжоўваць колькасць прылад, завяршаць сесіі або зніжаць прапускную здольнасць. Кожнае з гэтага дае збой, які знутры кліента VPN выглядае як блакіроўка.

Тунэль тут дрэнны дыягнастычны сродак, бо гэта адзіная праграма, якая гарантавана пацерпіць няўдачу, пакуль партал не аўтарызаваны. Звычайны вэб-доступ лепшы індыкатар, бо ён можа паказаць вам саму старонку ўваходу.

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

Спачатку завершыце партал, потым праверце звычайны HTTPS

Спытайце ў персаналу афіцыйную назву сеткі і спосаб уваходу. Пераканаўчы SSID не з'яўляецца доказам уласнасці, а другая сетка з падобнай назвай звычайная хітрасць у публічных месцах. Карыстайцеся ўласным акном уваходу аперацыйнай сістэмы, дзе яно прапанавана, або дакументаванай старонкай гатэля.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

Першы запыт звяртаецца да вядомага пункту выяўлення партала ўваходу праз звычайны HTTP; перанакіраванне або нечаканае цела азначае, што вы ўсё яшчэ за парталам. Другі правярае звычайны сайт HTTPS. Калі першы паказвае перахоп, а другі не працуе, уваход не завершаны, і VPN тут ні пры чым.

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

Ніколі не абыходзьце папярэджанне пра сертыфікат і не ўсталёўвайце невядомы сертыфікат або дапаможную праграму, каб выйсці ў сетку. Калі партал патрабуе нечага нечаканага, пацвердзіце гэта ў персаналу, а калі прылада належыць працадаўцу, у адміністратара.

Захавайце зыходны профіль і яго памылку

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

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

Калі звычайны доступ працуе, а перамовы ўсё яшчэ сканчаюцца тайм-аўтам, спытайце ў гатэля, ці падтрымлівае ён такі трафік, і параўнайце з надзейнай кропкай доступу, трымаючы прыладу і профіль нязменнымі. Праца на кропцы доступу звужае ўвагу да шляху гатэля, не даказваючы нічога пра профіль.

Выкарыстоўвайце толькі тыя альтэрнатывы, якія дае аператар

Адпаведны профіль TCP можа ўдацца там, дзе прапанаваны шлях UDP не працуе, але толькі калі сервер сапраўды слухае на гэтым транспарце і порце. Порт TCP 443 не разглядаецца аўтаматычна як звычайны HTTPS і не з'яўляецца гарантыяй праходу праз абмежавальную сетку.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

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

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

Нарэшце, праверце аднаўленне пасля сну ноўтбука. Аўтарызацыя партала можа скончыцца незалежна ад тунэля, таму прылада, якая аўтаматычна перападключаецца, можа вярнуцца ў сетку, якая ўжо яе забылася. Паўторнае адкрыццё старонкі партала звычайны крок, а не знак, што VPN зламаўся.

Падобныя артыкулы