OpenVPN op 443 noch altyd blokkearre? Sjoch wat it netwurk ûndersiket

De tunnel ferbynt fan in thúsline en stekt fêst op in hotel- of kantoarnetwurk, en it ferpleatsen fan de server nei poarte 443 feroare neat. Dat resultaat is gewoan genôch om in foarm te hawwen: de poarte wie it maklike part, en de rest fan it beslút heart by alles wat tusken de klient en de server sit. Twa fragen besljochtsje de measte gefallen, en gjin fan beide giet oer sjifers. Akseptearret it netwurk in TLS-hânjaan nei dat adres, en hâldt de klient in rûte nei syn eigen wikkel wylst de tunnel oan is?

De hânjaan ferret mear as it nûmer

In eigen VPN-harker op TCP 443 praat syn eigen protokol fan it earste pakket ôf. In ClientHello hat in ferzjefjild, in willekeurige wearde en in list fan útwreidings, en in apparaat dat in pear hûndert bytes lêst, kin it ferskil sjen sûnder eat te ûntsiferjen. Poartenûmers binne goedkeap te befredigjen, en de foarm fan it protokol is wat it filter echt kontrolearret. Regels wurde meastentiids ek per protokol skreaun, dus in belied dat TLS ûndersiket seit neat oer UDP.

In transparante proxy dy’t op in jildige TLS-sesje stiet, lit de ferbining falle by it opsetten, faak nei’t de TCP-hânjaan foltôge is. Dat detail is letter wichtich, want it betsjut dat it log fan de klient stopt nei’t de socket oanmakke is.

It stream ynwikselje skept twa flaterpunten

In TLS-wikkel lykas stunnel herstelt de ferwachte foarm: de klient ferbynt mei in lokale harker, de wikkel iepenet in echte TLS-sesje nei de server op 443, en in twadde wikkel op de server jout de ûntsifere bytes troch oan de VPN-daemon. De bûtenste sesje liket no op elke oare HTTPS-ferbining. De VPN-daemon op de server moat allinnich op loopback harkje, want neat bûten de wikkel hoecht him te berikken.

Trije aparte dingen moatte foar dat ûntwerp byinoar komme. It kliïntprofyl wiist nei de lokale harker, it server-sertifikaat past by de namme dy’t de klient ferifiearret, en it trochstjoeren oan de serverkant rjochtet him op de poarte dy’t de daemon echt brûkt. Ferkeard ien fan de trije en de ferbining stjert foar’t de VPN-laach berikt wurdt. Dan ferskynt in sertifikaatferskil as in wikkelflater ynstee fan in VPN-flater, en dêrom is it de muoite wurdich beide logs njonkeninoar te lêzen.

De rûte nei de wikkel is de falstrik

Sadree’t de tunnel omheech komt, wiist de standertrûte deryn, en de bûtenste TLS-sesje hat in paad nedich dat net yn ’e tunnel komt dy’t er draacht. In gewoane VPN-klient beskermet it adres dat er skillet; in wikkele klient skillet syn eigen loopback, dus it bestimmingsadres fan de wikkel is ûnsichtber foar dy beskerming.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

De krekte adressen meitsje jo sels fol, en de rûte moat bestean yn ’e hiele libbensdoer fan de ferbining, net allinnich by it opstarten. In lyts wikkelskript dat de rûte foar de klient tafoeget en dernei fuorthellet, is betrouberder as in ûntholden opdracht.

Op Android is it ekwivalint fan dy útsûndering in ynstelling per applikaasje: slút de wikkelapplikaasje út fan ’e tunnel, sadat syn eigen ferkear troch de mobile ferbining nei bûten giet. Sûnder de útsûndering wurdt de wikkel yn ’e tunnel stjoerd dy’t er besiket te bouwen, en de werferbininglus liket op in serverprobleem.

Lês it tiidferrin foar’t jo eat feroarje

In sesje dy’t elke kear nei itselde ynterval stjert, is in beliedshandtekening en net in kryptografyske flater, en langduorjende streamlimiten meitsje krekt dat patroan. In ferbining dy’t fuort nei de hânjaan weromset wurdt, suggerearret in proxy dy’t de sertifikaatkeatling net lije mocht.

Fergelykje de sertifikaatútjouwer fan in gewoane HTTPS-side fan beide netwurken. As de útjouwer op it beheinde netwurk oars is, beëiniget eat TLS yn ’e midden, en gjin inkelde wikkel oerlibbet dy ûnderskepping sûnder feroaring. Deselde fergeliking fertelt jo oft de blokkade op jo servernamme rjochtet of op elke TLS-sesje op dat adres.

Skriuw it waarnommen gedrach op: hoe lang’t de sesje duorre, oft de socket iepene, oft de wikkel in hânjaan logge. Elk fan dy punten ferinnert de folgjende test.

Test ien fariabele tagelyk

Kontrolearje earst UDP, want guon netwurken smite it hielendal fuort en in UDP-flater seit neat oer 443. Besykje dan TCP 443 sûnder de wikkel, en dêrnei de wikkel op 443. Lês it log fan de klient by elke stap en stop sa gau’t it gedrach feroaret.

Feroarje ien elemint per besykjen. In nije poarte, in nije wikkel en in nije sjifer yn deselde run litte jo sûnder antwurd op hokker fan de trije telde.