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

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

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