VPN блокиран на мрежи само за веб? Радите по слојевима
Браузер ради, тунел умире. Прочитајте временске фазе curl-а, тестирајте прокси, проверите да ли је 443 заиста дозвољен, затим забележите шта је напустило машину.
Мрежа кампуса или хотела у којој браузер ради, а сваки тунел умире није један проблем, него четири наслагана. Путања може да дозвољава само 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, једини транспорт који већина путања само за веб уопште пропушта. Ако прва успе, а друга и даље не, прокси није препрека.
Неки клијенти читају прокси оперативног система уместо замене, а неки не читају ни једно. Проверите сопствену документацију апликације пре него што претпоставите да системско подешавање важи. Клијент који решава крајњу тачку преко resolver-а који прокси не опслужује такође ће овде пасти, и зато промена 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 упита одговарају на друго питање: ако се локални resolver и јавни resolver не слажу око адресе крајње тачке, ви се усмеравате и аргумент о транспорту је погрешан.
Проверите шта је заиста напустило машину
Дневници клијента описују у шта клијент верује. Снимак описује шта је мрежа видела, а разлика између њих је место где се већина ових случајева решава:
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, блок је изнад и клијент је невин. Ако видите завршено руковање ка адреси која није серверова, разговарате са проксијем или пресретачем. Ако не видите ништа, проверите да ли сте снимали на исправном интерфејсу пре него што било шта закључите.
Списак сокета хвата суптилнији случај: други тунел који већ држи подразумевану руту. Два клијента која се боре за табелу рутирања стварају повремене дефекте који изгледају тачно као блокирана мрежа, а снимак ће показати саобраћај који излази кроз интерфејс који нисте очекивали.
Враћање назад и белешка коју вреди сачувати
Опозовите измене обрнутим редоследом од оног којим сте их направили. Уклоните променљиве проксија, зауставите клијента који сте покренули ручно и уклоните свако додато преписивање руте или resolver-а:
unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default
Остављање ручно покренутог клијента да ради је начин на који лаптоп заврши са поквареном мрежом при следећој посети канцеларији. Променљиве проксија остављене у профилу шкољке кваре неповезане алате недељама касније, а особа која их отклања неће повезати два догађаја.
Затим напишите четири реда: мрежа, временска ознака, фаза која је пала и виђени издавалац. Путања која ради на једном кампусу и пада на следећем је нормална, а следећа особа треба да зна да ли је разлика била прокси, resolver или филтер. Ако је одговор да мрежа забрањује даљински приступ, зауставите се ту и питајте администратора за подржану путању уместо да носите заобилазницу у политику коју нисте прочитали.