VPN geblokkeer op ’n netwerk net vir die web? Werk laag vir laag

’n Kampus- of hotelnetwerk waar die blaaier werk en elke tonnel sterf, is nie een probleem nie, dit is vier gestapelde probleme. Die pad laat dalk net TCP 443 toe, dit eis dalk ’n geauthentiseerde instaanbediener, dit ondersoek dalk die handdruk, en dit verbied dalk bloot afstandtoegang per beleid. Om hulle in volgorde te werk, keer dat jy ’n nuwe kliënt koop om ’n netwerkreeël reg te maak. Die draaiboek hieronder neem omtrent tien minute en eindig met ’n geskrewe antwoord oor watter laag jou geweier het.

Bewys watter laag die verbinding weier

Moenie met die VPN-kliënt begin nie. Begin met ’n gewone HTTPS-versoek na dieselfde gasheer en lees die tydsfases, want die fase wat misluk, sê vir jou watter toestel verantwoordelik is:

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

Geen antwoord en geen connect-tyd beteken TCP het nooit voltooi nie, dus is daar ’n vuurmuur, ’n instaanbedienervereiste of ’n verkeerde bestemming in die spel. ’n connect-tyd sonder enige tls-tyd beteken iets in die middel het die verbinding aanvaar en toe die handdruk laat hang, wat is hoe ’n ondersoekende instaanbediener van die kliëntkant lyk.

Ondersoek nou die sertifikaat wat jy werklik ontvang. Dit is die vinnigste manier om uit te vind of jy met die bediener praat of met ’n middelboks wat die sessie heronderteken het:

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

Lees die uitreikerlyn. Jou eie CA beteken jy het die diens bereik; ’n korporatiewe of toestel-uitreiker beteken ’n filter het die verbinding beëindig en besluit wat volgende gebeur. Teken beide uitsette met ’n tydstempel aan, want dieselfde toets ’n uur later op die gasnetwerk kan ’n ander antwoord gee.

’n Instaanbewuste kliënt verander die eerste pakket, nie die beleid nie

As die netwerk CONNECT deur ’n geauthentiseerde instaanbediener vereis, moet jou VPN-kliënt daarvan weet, anders probeer dit ’n sok aan ’n adres oopmaak wat dit nie kan roeteer nie. Toets die instaanbediener apart van die kliënt, sodat ’n mislukking een verklaring het:

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

Die eerste opdrag bewys die instaanbediener sal die bestemming dra. Die tweede vra die kliënt om TCP op 443 te gebruik, wat die enigste vervoer is wat die meeste web-only paaie hoegenaamd sal deurstuur. As die eerste opdrag slaag en die tweede steeds misluk, is die instaanbediener nie die hindernis nie.

Sommige kliënte lees die bedryfstelsel se instaanbediener in plaas van ’n oorheersende instelling, en sommige lees nie een van die twee nie. Kontroleer die toepassing se eie dokumentasie voordat jy aanneem ’n stelselwye instelling geld. ’n Kliënt wat die eindpunt deur ’n oplosser oplos wat die instaanbediener nie bedien nie, sal ook hier misluk, en daarom kan ’n DNS-verandering soos ’n oplossing lyk wanneer dit net ’n ompad is.

Let ook op die stuurpatroon terwyl jy hiermee besig is. ’n Gefiltreerde netwerk kan ’n verskaffer se opsporingsgasheernaam met iets van sy eie beantwoord, wat verander watter instaanprofiel die kliënt kies. Moenie ’n proses rondom daardie eienaardigheid bou nie. Dit verskil per terrein, dit verander sonder kennisgewing, en dit is nie iets wat jy vir iemand anders kan ondersteun nie.

Poort 443 is bereikbaar, nie toegelaat nie

Om ’n tonnel in TLS op 443 te draai, los bereikbaarheid op en niks anders nie. ’n Filter wat die poort kontroleer, sal dit deurlaat; ’n filter wat die handdruk vingerafdruk, sal dit nie, en geënkripteerde kliënt-groet verberg net die bedienernaam wanneer beide kante dit ondersteun. Hardloop die toets en vind uit watter soort filter jy agter is in plaas daarvan om te hoop.

Daar is ook ’n prestasiekoste wat mense later ontdek. ’n Betroubare vervoer binne ’n betroubare vervoer versterk verlies, want die binneste stapel stuur segmente weer wat die buitenste stapel reeds weer gestuur het. Op ’n skoon skakel merk niemand dit nie. Op ’n oorlaaide kampus-draadlose netwerk word die tonnel onbruikbaar presies wanneer jy dit nodig het, en die grafiek lyk soos pakketverlies al word niks doelbewus laat val nie.

UDP is gewoonlik die eerste slagoffer, en dit is die moeite werd om te bevestig eerder as om dit af te lei. As WireGuard of standaard OpenVPN nooit ’n handdruk voltooi terwyl TCP 443 werk nie, laat die netwerk UDP val, en geen hoeveelheid sleutelhergenerering sal dit verander nie:

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

’n Leë handdruk-tydstempel langs ’n eweknie wat gister gewerk het, is die UDP-antwoord. Die twee DNS-navrae antwoord ’n ander vraag: as die plaaslike oplosser en ’n openbare oplosser oor die eindpuntadres verskil, word jy gestuur en is die vervoerargument die verkeerde een.

Verifieer wat werklik die masjien verlaat het

Kliëntlogboeke beskryf wat die kliënt glo. ’n Opname beskryf wat die netwerk gesien het, en die verskil tussen die twee is waar die meeste van hierdie gevalle opgelos word:

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

As jy SYN-pakkette sien en geen SYN-ACK nie, is die blok opstroom en is die kliënt onskuldig. As jy ’n voltooide handdruk na ’n adres sien wat nie die bediener s’n is nie, praat jy met ’n instaanbediener of ’n onderskepper. As jy glad niks sien nie, kontroleer dat jy op die regte koppelvlak opgeneem het voordat jy enigiets aflei.

Die sok-lys vang ’n subtieler geval: ’n tweede tonnel wat reeds die verstekroete hou. Twee kliënte wat oor die roetetabel veg, lewer onderbroke mislukkings wat presies soos ’n geblokkeerde netwerk lyk, en die opname sal verkeer wys wat deur ’n koppelvlak vertrek wat jy nie verwag het nie.

Terugrol, en die nota wat die moeite werd is om te hou

Maak die veranderinge ongedaan in die omgekeerde volgorde wat jy hulle gemaak het. Verwyder die instaanveranderlikes, stop die kliënt wat jy met die hand begin het, en verwyder enige roete of oplosser-oorheersing wat jy bygevoeg het:

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

Om ’n handbegin kliënt te laat loop, is hoe ’n skootrekenaar met ’n gebreekte netwerk by die volgende kantoorbesoek beland. Instaanveranderlikes wat in ’n skulp-profiel gelaat word, breek weke later onverwante gereedskap, en die persoon wat dit ontfout, sal die twee gebeurtenisse nie verbind nie.

Skryf dan vier reëls: die netwerk, die tydstempel, die fase wat misluk het, en die uitreiker wat jy gesien het. ’n Pad wat op een kampus werk en op die volgende misluk, is normaal, en die volgende persoon moet weet of die verskil die instaanbediener, die oplosser of die filter was. As die antwoord is dat die netwerk afstandtoegang verbied, stop daar en vra die administrateur vir die ondersteunde roete eerder as om ’n omweg in ’n beleid te dra wat jy nie gelees het nie.