VPN заблакаваны ў сетцы толькі для вэб? Працайце па ўзроўнях

Кампусная або гатэльная сетка, дзе браўзер працуе, а кожны тунель памірае, — гэта не адна праблема, а чатыры накладаныя. Шлях можа дазваляць толькі TCP 443, можа патрабаваць аўтэнтыфікаваны проксі, можа правяраць рукапацісканне і можа проста забараняць аддалены доступ палітыкай. Праца з імі па парадку не дае вам купіць новы кліент, каб выправіць правіла сеткі. Інструкцыя ніжэй займае каля дзесяці хвілін і заканчваецца пісьмовым адказам пра тое, які ўзровень адмовіў вам.

Дакажыце, які ўзровень адмаўляе ў злучэнні

Не пачынайце з кліента VPN. Пачніце са звычайнага запыту HTTPS да таго ж хоста і прачытайце фазы часу, бо фаза, якая не ўдалася, паказвае, якая прылада вінаватая:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Няма адказу і няма часу connect — значыць, TCP так і не завяршыўся, таму ў гульні фаервол, патрабаванне проксі або няправільны пункт прызначэння. Час connect без часу tls — значыць, нешта пасярэдзіне прыняло злучэнне і затрымала рукапацісканне; менавіта так выглядае інспектуючы проксі з боку кліента.

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

Кліент, які ўлічвае проксі, змяняе першы пакет, а не палітыку

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

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Першая каманда даказвае, што проксі панясе пункт прызначэння. Другая просіць кліент выкарыстоўваць TCP на 443 — гэта адзіны транспарт, які большасць шляхоў толькі для вэб наогул прапускае. Калі першая каманда ўдалася, а другая ўсё яшчэ не, то проксі не перашкода.

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

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

Порт 443 дасяжны, а не дазволены

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

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

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

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Пустая адзнака часу рукапаціскання побач з партнёрам, які працаваў учора, — гэта адказ па UDP. Два запыты DNS адказваюць на іншае пытанне: калі лакальны развязальнік і публічны развязальнік разыходзяцца ў адрасе канчатковага пункта, вас накіроўваюць, і аргумент пра транспарт няправільны.

Праверце, што насамрэч пакінула машыну

Журналы кліента апісваюць тое, у што верыць кліент. Перахоп апісвае тое, што бачыла сетка, і большасць такіх выпадкаў вырашаецца ў розніцы паміж імі:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

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

Адкат і нататка, якую варта захаваць

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

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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