VPN estetty vain verkkoselaimen sallivassa verkossa? Käy kerrokset läpi

Kampus- tai hotelliverkko, jossa selain toimii ja jokainen tunneli kuolee, ei ole yksi ongelma vaan neljä päällekkäistä. Polku voi sallia vain TCP 443:n, vaatia todennetun välityspalvelimen, tarkastaa kättelyn tai yksinkertaisesti kieltää etäkäytön käytännöllä. Niiden käsittely järjestyksessä estää sinua ostamasta uutta asiakasta verkkosäännön korjaamiseksi. Alla oleva ohje kestää noin kymmenen minuuttia ja päättyy kirjalliseen vastaukseen siitä, mikä kerros hylkäsi sinut.

Todista, mikä kerros hylkää yhteyden

Älä aloita VPN-asiakkaasta. Aloita tavallisella HTTPS-pyynnöllä samaan isäntään ja lue aikavaiheet, koska epäonnistuva vaihe kertoo, mikä laite on vastuussa:

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

Ei vastausta eikä connect-aikaa tarkoittaa, ettei TCP koskaan valmistunut, joten pelissä on palomuuri, välityspalvelinvaatimus tai väärä kohde. connect-aika ilman tls-aikaa tarkoittaa, että jokin välissä otti yhteyden vastaan ja pysäytti sitten kättelyn, ja juuri tältä tarkastava välityspalvelin näyttää asiakkaan puolelta.

Tarkastele nyt sertifikaattia, jonka todella saat. Se on nopein tapa selvittää, puhutko palvelimelle vai välikölle, joka allekirjoitti istunnon uudelleen:

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

Lue myöntäjän rivi. Oma CA tarkoittaa, että pääsit palveluun; yrityksen tai laitteen myöntäjä tarkoittaa, että suodatin päätti yhteyden ja päättää, mitä seuraavaksi tapahtuu. Tallenna molemmat tulosteet aikaleimalla, koska sama testi tuntia myöhemmin vierasverkossa voi antaa toisen vastauksen.

Välityspalvelimen tunteva asiakas muuttaa ensimmäistä pakettia, ei käytäntöä

Jos verkko vaatii CONNECTin todennetun välityspalvelimen kautta, VPN-asiakkaalle on kerrottava siitä, muuten se yrittää avata pistokkeen osoitteeseen, jota se ei voi reitittää. Testaa välityspalvelinta erikseen asiakkaasta, jotta epäonnistumisella on yksi selitys:

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

Ensimmäinen komento todistaa, että välityspalvelin kantaa kohteen. Toinen pyytää asiakasta käyttämään TCP:tä portissa 443, ainoa siirto, jonka useimmat vain verkon polut ylipäätään välittävät. Jos ensimmäinen onnistuu ja toinen yhä epäonnistuu, välityspalvelin ei ole este.

Jotkut asiakkaat lukevat käyttöjärjestelmän välityspalvelinta ohituksen sijaan, jotkut eivät kumpaakaan. Tarkista sovelluksen oma dokumentaatio ennen kuin oletat järjestelmäasetuksen pätevän. Asiakas, joka ratkaisee päätepisteen ratkaisijalla, jota välityspalvelin ei palvele, epäonnistuu myös täällä, ja siksi DNS-muutos voi näyttää korjaukselta, kun se on vain kiertotie.

Huomaa myös ohjauskuvio. Suodatettu verkko voi vastata toimittajan tunnistusisäntänimelle omalla jotakin, mikä muuttaa sitä, minkä välityspalvelinprofiilin asiakas valitsee. Älä rakenna prosessia tuon omituisuuden varaan. Se vaihtelee kohteen mukaan, muuttuu ilman ilmoitusta, eikä sitä voi tukea kenellekään muulle.

Portti 443 on tavoitettavissa, ei sallittu

Tunnelin kääriminen TLS:ään portissa 443 ratkaisee tavoitettavuuden eikä mitään muuta. Portin tarkistava suodatin päästää sen läpi; kättelyn sormenjäljen ottava ei päästä, ja salattu asiakastervehdys piilottaa palvelimen nimen vain, kun molemmat päät tukevat sitä. Aja testi ja selvitä, minkä suodattimen takana olet, sen sijaan että toivoisit.

On myös suorituskykykustannus, jonka ihmiset löytävät myöhemmin. Luotettava siirto luotettavan siirron sisällä vahvistaa häviötä, koska sisempi pino lähettää uudelleen segmenttejä, jotka ulompi pino on jo lähettänyt uudelleen. Puhtaalla yhteydellä kukaan ei huomaa. Ruuhkaisessa kampuksen langattomassa verkossa tunnelista tulee käyttökelvoton juuri kun tarvitset sitä, ja kuvaaja näyttää pakettihäviöltä, vaikka mitään ei hylätä tahallaan.

UDP on yleensä ensimmäinen uhri, ja se kannattaa vahvistaa eikä päätellä. Jos WireGuard tai oletus-OpenVPN ei koskaan suorita kättelyä loppuun, kun TCP 443 toimii, verkko pudottaa UDP:tä, eikä avainten uudelleenluonti muuta sitä:

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

Tyhjä kättelyn aikaleima vertaisen vieressä, joka toimi eilen, on UDP-vastaus. Kaksi DNS-kyselyä vastaavat toiseen kysymykseen: jos paikallinen ratkaisija ja julkinen ratkaisija ovat eri mieltä päätepisteen osoitteesta, sinua ohjataan ja siirtoargumentti on väärä.

Varmista, mitä koneesta todella lähti

Asiakkaan lokit kuvaavat, mitä asiakas uskoo. Kaappaus kuvaa, mitä verkko näki, ja näiden ero on paikka, jossa useimmat näistä tapauksista ratkeavat:

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

Jos näet SYN-paketteja eikä SYN-ACK:ia, esto on ylävirrassa ja asiakas on syytön. Jos näet valmiin kättelyn osoitteeseen, joka ei ole palvelimen, puhut välityspalvelimelle tai sieppaajalle. Jos et näe mitään, tarkista että kaappasit oikealla liitännällä ennen kuin päättelet mitään.

Pistokeluettelo nappaa hienovaraisemman tapauksen: toinen tunneli pitää jo oletusreittiä. Kaksi reititystaulusta taistelevaa asiakasta tuottaa ajoittaisia vikoja, jotka näyttävät täsmälleen estetyltä verkolta, ja kaappaus näyttää liikennettä, joka lähtee liitännästä, jota et odottanut.

Peruutus ja muistiinpano, joka kannattaa säilyttää

Kumoa muutokset käänteisessä järjestyksessä siihen, miten teit ne. Poista välityspalvelinmuuttujat, pysäytä käsin aloittamasi asiakas ja poista kaikki lisäämäsi reitti- tai ratkaisijaohitus:

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

Käsin aloitetun asiakkaan jättäminen käyntiin on se, miten kannettava päätyy rikkinäiseen verkkoon seuraavalla toimistokäynnillä. Shell-profiiliin jätetyt välityspalvelinmuuttujat rikkovat asiaankuulumattomia työkaluja viikkoja myöhemmin, eikä niitä debuggaava yhdistä kahta tapahtumaa.

Kirjoita sitten neljä riviä: verkko, aikaleima, epäonnistunut vaihe ja näkemäsi myöntäjä. Polku, joka toimii yhdellä kampuksella ja epäonnistuu seuraavalla, on normaalia, ja seuraavan ihmisen on tiedettävä, oliko ero välityspalvelin, ratkaisija vai suodatin. Jos vastaus on, että verkko kieltää etäkäytön, pysähdy siihen ja pyydä ylläpitäjältä tuettu reitti sen sijaan, että veisit kiertotien käytäntöön, jota et ole lukenut.