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

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

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