VPN blokkearre op in netwurk allinnich foar web? Wurkje de lagen

In kampús- of hotelnetwurk dêr’t de browser wurket en elke tunnel stjert is net ien probleem, it binne fjouwer opinoar. It paad kin allinnich TCP 443 tastean, in autentisearre proxy easkje, de hânskudding ynspektearje en it kin gewoan op ôfstan tagong troch belied ferbiede. Se op folchoarder behannelje foarkomt dat jo in nije client keapje om in netwurkregel te reparearjen. De hantlieding hjirûnder duorret sawat tsien minuten en einiget mei in skreaun antwurd oer hokker laach jo wegere.

Bewiis hokker laach de ferbining wegeret

Begjin net mei de VPN-client. Begjin mei in gewoan HTTPS-fersyk nei deselde host en lês de tiidfazes, want de faze dy’t mislearret fertelt hokker apparaat ferantwurdlik is:

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

Gjin antwurd en gjin connect-tiid betsjut dat TCP nea foltôge is, dus in firewall, in proxy-eask of in ferkeard bestimmingsadres is yn it spul. In connect-tiid sûnder tls-tiid betsjut dat eat yn it midden de ferbining oannaam en doe de hânskudding tsjinkearde, en sa sjocht in ynspektearjende proxy der fan de kliïntkant út.

Besjoch no it sertifikaat dat jo echt krije. Dat is de fluchste manier om út te finen oft jo mei de server prate of mei in middenbok dy’t de sesje opnij ûndertekene hat:

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

Lês de rigel fan de útjouwer. Jo eigen CA betsjut dat jo de tsjinst berikte; in bedriuws- of apparaatútjouwer betsjut dat in filter de ferbining einige en beslút wat der folget. Fêstlizze beide útgongen mei in tiidstimpel, want deselde test in oere letter op it gastnetwurk kin in oar antwurd jaan.

In proxybewuste client feroaret it earste pakket, net it belied

As it netwurk CONNECT fia in autentisearre proxy easket, moat de VPN-client dat witte, oars probearret er in socket te iepenjen nei in adres dat er net routje kin. Test de proxy apart fan de client, sadat in mislearring ien ferklearring hat:

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

It earste kommando bewiist dat de proxy it bestimmingsadres drage sil. It twadde freget de client TCP op 443 te brûken, it iennige ferfier dat de measte allinnich-web-paden oeral trochlitte. As it earste kommando slagget en it twadde noch mislearret, is de proxy net it obstakel.

Guon clients lêze de proxy fan it bestjoeringssysteem ynstee fan in oerskriuwing, en guon lêze gjin fan beide. Kontrolearje de dokumintaasje fan de applikaasje foardat jo oannimme dat in systeembreed ynstelling jildt. In client dy’t it einpunt oplost fia in resolver dy’t de proxy net betsjinnet, sil hjir ek mislearje, en dêrom kin in DNS-wiziging as in oplossing lykje wylst it mar in omwei is.

Let ek op it stjoerpatroan. In filtere netwurk kin op in hostnamme foar detectie fan in leveransier antwurdzje mei eat fan himsels, wat feroaret hokker proxyprofyl de client kiest. Bou gjin proses om dy eigenaardigens hinne. It ferskilt per lokaasje, feroaret sûnder warskôging, en it is neat dat jo foar immen oars stypje kinne.

Poarte 443 is berikber, net tastien

In tunnel yn TLS op 443 ferpakke lost berikberens op en neat oars. In filter dat de poarte kontrolearret lit it troch; in filter dat in fingerôfdruk fan de hânskudding nimt net, en fersifere client-groet ferberget de servernamme allinnich as beide kanten it stypje. Run de test en ûntdek efter hokker soarte filter jo sitte ynstee fan te hoopjen.

Der is ek in prestaasjekost dy’t minsken letter ûntdekke. In betrouber ferfier yn in betrouber ferfier fersterket ferlies, want de binnenste stack stjoert segminten opnij dy’t de bûtenste al opnij stjoerd hat. Op in skjinne keppeling merkt nimmen it. Op in oerfolle kampús-draadleas netwurk wurdt de tunnel ûnbrûkber krekt as jo him nedich hawwe, en de grafyk liket op pakketferlies ek al wurdt der neat mei opsetsin weilitten.

UDP is meastal it earste slachtoffer, en dat is de muoite wurdich te befêstigjen ynstee fan te riddenearjen. As WireGuard of standert OpenVPN nea in hânskudding foltôget wylst TCP 443 wurket, lit it netwurk UDP falle, en gjin inkelde kaaiwerdergeneraasje sil dat feroarje:

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

In lege tiidstimpel fan de hânskudding neist in peer dy’t juster wurke is it UDP-antwurd. De twa DNS-fragen beantwurdzje in oare fraach: as de lokale resolver en in iepenbiere resolver it net iens binne oer it adres fan it einpunt, wurde jo stjoerd en is it ferfierargumint it ferkearde.

Kontrolearje wat de masine echt ferliet

Clientlogboeken beskriuwe wat de client leaut. In opname beskriuwt wat it netwurk seach, en it ferskil tusken beide is wêr’t de measte fan dizze gefallen oplost wurde:

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 jo SYN-pakketten sjogge en gjin SYN-ACK, sit de blokkade streamop en is de client ûnskuldich. As jo in foltôge hânskudding sjogge nei in adres dat net fan de server is, prate jo mei in proxy of in ûnderskepper. As jo hielendal neat sjogge, kontrolearje dan oft jo op de juste interface opnommen hawwe foardat jo eat konkludearje.

De socketlist fangt in subtiler gefal: in twadde tunnel dy’t al de standertrûte hâldt. Twa clients dy’t fjochtsje om de routingtabel produsearje tuskentiidske flaters dy’t der krekt as in blokkearre netwurk útsjen, en de opname sil ferkear sjen litte dat fia in interface fuortgiet dy’t jo net ferwachte hiene.

Weromdraaie, en de notysje dy’t de muoite wurdich is

Draai de wizigings werom yn de omkearde folchoarder fan hoe’t jo se makken. Ferwiderje de proxyfariabelen, stopje de client dy’t jo mei de hân starte, en ferwiderje elke rûte- of resolver-oerskriuwing dy’t jo tafoege hawwe:

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

In mei de hân starte client oan litten is hoe’t in laptop by it folgjende kantoarbesyk mei in brutsen netwurk sit. Proxyfariabelen dy’t yn in shell-profyl efterlitten wurde, brekke wiken letter net-relatearre helpmiddelen, en de persoan dy’t se debugt sil de twa barrens net ferbine.

Skriuw dan fjouwer rigels: it netwurk, de tiidstimpel, de faze dy’t mislearre en de útjouwer dy’t jo seagen. In paad dat op ien kampús wurket en op de folgjende mislearret is normaal, en de folgjende persoan moat witte oft it ferskil de proxy, de resolver of it filter wie. As it antwurd is dat it netwurk ôfstan tagong ferbiedt, stopje dêr dan en freegje de behearder om de stipe rûte ynstee fan in omwei yn in belied te dragen dat jo net lêzen hawwe.