VPN užblokuotas tik žiniatinklio tinkle? Dirbkite sluoksniais

Miestelio ar viešbučio tinklas, kuriame naršyklė veikia, o kiekvienas tunelis miršta, nėra viena problema, tai keturi sluoksniai. Kelias gali leisti tik TCP 443, reikalauti autentifikuoto tarpinio serverio, tikrinti rankos paspaudimą arba tiesiog politika uždrausti nuotolinę prieigą. Tvarkant juos iš eilės nereikia pirkti naujo kliento tinklo taisyklei pataisyti. Toliau pateiktas vadovas trunka apie dešimt minučių ir baigiasi rašytiniu atsakymu, kuris sluoksnis jus atmetė.

Įrodykite, kuris sluoksnis atmeta ryšį

Nepradėkite nuo VPN kliento. Pradėkite paprasta HTTPS užklausa tam pačiam hostui ir skaitykite laiko fazes, nes nepavykstanti fazė pasako, kuris įrenginys atsakingas:

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

Nėra atsakymo ir nėra connect laiko reiškia, kad TCP niekada nebuvo baigtas, tad žaidime yra ugniasienė, tarpinio serverio reikalavimas arba neteisingas tikslas. connect laikas be tls laiko reiškia, kad kažkas viduryje priėmė ryšį ir tada sustabdė rankos paspaudimą, ir būtent taip tikrinantis tarpinis serveris atrodo iš kliento pusės.

Dabar patikrinkite sertifikatą, kurį iš tikrųjų gaunate. Tai greičiausias būdas sužinoti, ar kalbatės su serveriu, ar su tarpine dėže, kuri iš naujo pasirašė sesiją:

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

Perskaitykite išdavėjo eilutę. Jūsų pačių CA reiškia, kad pasiekėte paslaugą; įmonės ar įrenginio išdavėjas reiškia, kad filtras užbaigė ryšį ir sprendžia, kas bus toliau. Užrašykite abi išvestis su laiko žyma, nes tas pats testas po valandos svečių tinkle gali duoti kitą atsakymą.

Tarpinį serverį žinantis klientas keičia pirmąjį paketą, o ne politiką

Jei tinklas reikalauja CONNECT per autentifikuotą tarpinį serverį, VPN klientui tai reikia pasakyti, kitaip jis bandys atidaryti lizdą adresu, kurio negali maršrutizuoti. Išbandykite tarpinį serverį atskirai nuo kliento, kad gedimas turėtų vieną paaiškinimą:

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

Pirmoji komanda įrodo, kad tarpinis serveris perneš tikslą. Antroji prašo kliento naudoti TCP 443 prievade, vienintelį transportą, kurį dauguma tik žiniatinklio kelių apskritai perduoda. Jei pirmoji pavyksta, o antroji vis dar nepavyksta, tarpinis serveris nėra kliūtis.

Kai kurie klientai skaito operacinės sistemos tarpinį serverį vietoj perrašymo, o kai kurie neskaito nė vieno. Patikrinkite programos dokumentaciją prieš manydami, kad sisteminis nustatymas galioja. Klientas, kuris sprendžia galinį tašką per sprendiklį, kurio tarpinis serveris neaptarnauja, taip pat nepavyks čia, ir todėl DNS pakeitimas gali atrodyti kaip taisymas, kai tai tik apylanka.

Atkreipkite dėmesį ir į nukreipimo modelį. Filtruojamas tinklas gali atsakyti į tiekėjo aptikimo hosto vardą kažkuo savo, o tai keičia, kokį tarpinio serverio profilį klientas pasirenka. Nekurkite proceso aplink tą keistenybę. Ji skiriasi pagal vietą, keičiasi be įspėjimo, ir tai nėra kažkas, ką galite palaikyti kam nors kitam.

443 prievadas pasiekiamas, bet neleidžiamas

Tunelio įvyniojimas į TLS 443 prievade išsprendžia pasiekiamumą ir nieko daugiau. Filtras, kuris tikrina prievadą, jį praleis; filtras, kuris ima rankos paspaudimo atspaudą, nepraleis, o užšifruotas kliento pasveikinimas slepia serverio vardą tik tada, kai abu galai tai palaiko. Paleiskite testą ir sužinokite, už kokio filtro esate, o ne viltis.

Yra ir našumo kaina, kurią žmonės atranda vėliau. Patikimas transportas patikimo transporto viduje sustiprina nuostolius, nes vidinis stekas siunčia iš naujo segmentus, kuriuos išorinis jau persiuntė. Švarioje linijoje niekas nepastebi. Perkrautame miestelio belaidžiame tinkle tunelis tampa nenaudojamas būtent tada, kai jo reikia, o grafikas atrodo kaip paketų praradimas, nors nieko tyčia nemetama.

UDP paprastai yra pirmoji auka, ir tai verta patvirtinti, o ne spėti. Jei WireGuard ar numatytasis OpenVPN niekada nebaigia rankos paspaudimo, kol TCP 443 veikia, tinklas meta UDP, ir joks raktų pergeneravimas to nepakeis:

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

Tuščia rankos paspaudimo laiko žyma prie vakar veikusio partnerio yra UDP atsakymas. Dvi DNS užklausos atsako į kitą klausimą: jei vietinis sprendiklis ir viešas sprendiklis nesutaria dėl galinio taško adreso, jus nukreipia, ir transporto argumentas yra neteisingas.

Patikrinkite, kas iš tikrųjų paliko mašiną

Kliento žurnalai aprašo, kuo klientas tiki. Užrašas aprašo, ką matė tinklas, ir skirtumas tarp jų yra vieta, kurioje išsprendžiama dauguma šių atvejų:

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

Jei matote SYN paketus ir nėra SYN-ACK, blokas yra aukščiau, o klientas nekaltas. Jei matote užbaigtą rankos paspaudimą adresu, kuris nėra serverio, kalbatės su tarpiniu serveriu arba perėmėju. Jei nematote nieko, patikrinkite, ar įrašėte tinkamoje sąsajoje, prieš darydami išvadas.

Lizdų sąrašas pagauna subtilesnį atvejį: antras tunelis jau laiko numatytąjį maršrutą. Du klientai, kovojantys dėl maršrutizavimo lentelės, sukelia periodiškus gedimus, kurie atrodo lygiai kaip užblokuotas tinklas, o užrašas parodys srautą, išeinantį per sąsają, kurios nesitikėjote.

Atšaukimas ir pastaba, kurią verta pasilikti

Atšaukite pakeitimus atvirkštine tvarka, nei juos padarėte. Pašalinkite tarpinio serverio kintamuosius, sustabdykite rankiniu būdu paleistą klientą ir pašalinkite bet kokį pridėtą maršruto ar sprendiklio perrašymą:

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

Palikti rankiniu būdu paleistą klientą veikti yra būdas, kuriuo nešiojamasis kompiuteris po kito apsilankymo biure lieka su sugedusiu tinklu. Shell profilyje palikti tarpinio serverio kintamieji po kelių savaičių sugadina nesusijusius įrankius, o juos derinantis asmuo nesieja dviejų įvykių.

Tada parašykite keturias eilutes: tinklas, laiko žyma, nepavykusi fazė ir matytas išdavėjas. Kelias, kuris veikia viename miestelyje ir nepavyksta kitame, yra normalu, o kitas žmogus turi žinoti, ar skirtumas buvo tarpinis serveris, sprendiklis ar filtras. Jei atsakymas yra, kad tinklas draudžia nuotolinę prieigą, sustokite ten ir paprašykite administratoriaus palaikomo kelio, o ne neškite apylanką į politiką, kurios neskaitėte.