VPN blokeeritud ainult veebi võrgus? Töötage kihid läbi

Ülikoolilinna või hotelli võrk, kus brauser töötab ja iga tunnel sureb, ei ole üks probleem, vaid neli kihiti. Tee võib lubada ainult TCP 443, nõuda autenditud puhverserverit, kontrollida kätlust ja lihtsalt poliitikaga kaugjuurdepääsu keelata. Nende järjekorras läbitöötamine hoiab ära uue kliendi ostmise võrgureegli parandamiseks. Allolev juhend võtab umbes kümme minutit ja lõpeb kirjaliku vastusega, milline kiht teid tagasi lükkas.

Tõestage, milline kiht ühenduse tagasi lükkab

Ärge alustage VPN-kliendist. Alustage tavalise HTTPS-päringuga samale hostile ja lugege ajafaase, sest nurjuv faas ütleb, milline seade on vastutav:

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

Vastust pole ja connect aega pole tähendab, et TCP ei lõppenud kunagi, seega on mängus tulemüür, puhverserveri nõue või vale sihtkoht. connect aeg ilma tls ajata tähendab, et miski keskel võttis ühenduse vastu ja peatas seejärel kätluse, ja täpselt nii näeb kontrolliv puhverserver kliendi poolelt välja.

Nüüd uurige sertifikaati, mille tegelikult saate. See on kiireim viis teada saada, kas räägite serveriga või vahekastiga, mis sessiooni uuesti allkirjastas:

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

Lugege väljaandja rida. Teie enda CA tähendab, et jõudsite teenuseni; ettevõtte või seadme väljaandja tähendab, et filter lõpetas ühenduse ja otsustab, mis edasi saab. Salvestage mõlemad väljundid ajatempliga, sest sama test tund hiljem külalisvõrgus võib anda teistsuguse vastuse.

Puhverserverist teadlik klient muudab esimest paketti, mitte poliitikat

Kui võrk nõuab CONNECT-i autenditud puhverserveri kaudu, tuleb VPN-kliendile sellest öelda, muidu proovib ta avada sokli aadressile, mida ta ei saa marsruutida. Testige puhverserverit klientist eraldi, et ebaõnnestumisel oleks üks seletus:

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

Esimene käsk tõestab, et puhverserver kannab sihtkoha. Teine palub kliendil kasutada TCP-d pordil 443, ainus transport, mida enamik ainult veebi teid üldse edasi laseb. Kui esimene käsk õnnestub ja teine ikka ebaõnnestub, ei ole puhverserver takistus.

Mõned kliendid loevad operatsioonisüsteemi puhverserverit alistamise asemel ja mõned ei loe kumbagi. Kontrollige rakenduse enda dokumentatsiooni, enne kui eeldada, et süsteemne säte kehtib. Klient, mis lahendab lõpp-punkti resolveri kaudu, mida puhverserver ei teeninda, ebaõnnestub ka siin, ja seetõttu võib DNS-i muudatus tunduda parandusena, kui see on vaid ümbersõit.

Pange tähele ka suunamismustrit. Filtreeritud võrk võib vastata tarnija tuvastushostinimele millegi omaga, mis muudab, millise puhverserveri profiili klient valib. Ärge ehitage protsessi selle veidruse ümber. See erineb saiditi, muutub ilma teatamata ja see pole midagi, mida te saaksite kellegi teise jaoks toetada.

Port 443 on kättesaadav, mitte lubatud

Tunneli mähkimine TLS-i pordil 443 lahendab kättesaadavuse ja ei midagi muud. Porti kontrolliv filter laseb selle läbi; kätluse sõrmejälge võttev filter ei lase, ja krüpteeritud klienditervitus peidab serverinime ainult siis, kui mõlemad pooled seda toetavad. Käivitage test ja saage teada, millise filtri taga olete, selle asemel et loota.

On ka jõudluskulu, mille inimesed avastavad hiljem. Usaldusväärne transport usaldusväärse transpordi sees võimendab kadu, sest sisemine virn saadab uuesti segmente, mille välimine virn on juba uuesti saatnud. Puhtal lingil ei märka keegi. Ülekoormatud ülikoolilinna traadita võrgus muutub tunnel kasutuskõlbmatuks täpselt siis, kui te seda vajate, ja graafik näeb välja nagu paketikaotus, kuigi midagi ei visata meelega ära.

UDP on tavaliselt esimene ohver, ja seda tasub kinnitada, mitte oletada. Kui WireGuard või vaikimisi OpenVPN ei lõpeta kunagi kätlust, samal ajal kui TCP 443 töötab, viskab võrk UDP-d ära, ja ükski võtmete uuendamine ei muuda seda:

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

Tühi kätluse ajatempel kõrvuti eakaaslasega, mis eile töötas, on UDP vastus. Kaks DNS-päringut vastavad teisele küsimusele: kui kohalik resolver ja avalik resolver ei ole lõpp-punkti aadressi osas ühel meelel, suunatakse teid ja transpordiargument on vale.

Kontrollige, mis masinast tegelikult väljus

Kliendi logid kirjeldavad, mida klient usub. Püüdis kirjeldab, mida võrk nägi, ja nende kahe erinevus on koht, kus enamik neist juhtumitest laheneb:

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

Kui näete SYN-pakette ja SYN-ACK puudub, on blokeering ülesvoolu ja klient on süütu. Kui näete lõpetatud kätlust aadressile, mis pole serveri oma, räägite puhverserveri või pealtkuulajaga. Kui ei näe üldse midagi, kontrollige, kas püüdsite õigel liidesel, enne kui midagi järeldate.

Soklite loend püüab peenema juhtumi: teine tunnel hoiab juba vaikimisi marsruuti. Kaks klienti, kes marsruutimistabeli pärast võitlevad, tekitavad katkendlikke tõrkeid, mis näevad täpselt välja nagu blokeeritud võrk, ja püüdis näitab liiklust väljumas liidesest, mida te ei oodanud.

Tagasipööramine ja märkus, mida tasub hoida

Võtke muudatused tagasi vastupidises järjekorras, kui te neid tegite. Eemaldage puhverserveri muutujad, peatage käsitsi käivitatud klient ja eemaldage kõik lisatud marsruudi või resolveri alistamised:

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

Käsitsi käivitatud kliendi tööle jätmine on viis, kuidas sülearvuti järgmisel kontorikülastusel katkise võrguga jääb. Shell-profiili jäetud puhverserveri muutujad rikuvad nädalaid hiljem mitteseotud tööriistu, ja inimene, kes neid silub, ei seosta neid kahte sündmust.

Seejärel kirjutage neli rida: võrk, ajatempel, nurjunud faas ja nähtud väljaandja. Tee, mis töötab ühes ülikoolilinnas ja ebaõnnestub järgmises, on normaalne, ja järgmine inimene peab teadma, kas erinevus oli puhverserver, resolver või filter. Kui vastus on, et võrk keelab kaugjuurdepääsu, peatuge seal ja küsige administraatorilt toetatud teed, selle asemel et kanda möödasõitu poliitikasse, mida te pole lugenud.