OpenVPN op 443 steeds geblokkeer? Kyk wat die netwerk ondersoek

Die tonnel verbind vanaf ’n tuislyn en staak op ’n hotel- of kantoor-netwerk, en die skuif van die bediener na poort 443 het niks verander nie. Daardie uitslag is algemeen genoeg om ’n vorm te hê: die poort was die maklike deel, en die res van die besluit hoort by alles wat tussen die kliënt en die bediener sit. Twee vrae beslis die meeste gevalle, en nie een daarvan gaan oor sifre nie. Aanvaar die netwerk ’n TLS-handdruk na daardie adres, en hou die kliënt ’n roete na sy eie wikkel terwyl die tonnel op is?

Die handdruk verraai meer as die nommer

’n Inheemse VPN-luisteraar op TCP 443 praat sy eie protokol vanaf die eerste pakkie. ’n ClientHello het ’n weergaweveld, ’n ewekansige waarde en ’n lys uitbreidings, en ’n toestel wat ’n paar honderd grepe lees, kan die verskil sien sonder om enigiets te dekripteer. Poortnommers is goedkoop om te bevredig, en protokolvorm is wat die filter werklik nagaan. Reëls word gewoonlik ook per protokol geskryf, so ’n beleid wat TLS ondersoek, sê niks oor UDP nie.

’n Deursigtige proxy wat op ’n geldige TLS-sessie aandring, laat die verbinding tydens die opstelling val, dikwels nadat die TCP-handdruk voltooi is. Daardie besonderheid saak later, want dit beteken die kliëntlog stop nadat die sokkel gevestig is.

Om die stroom te wikkel skep twee foutpunte

’n TLS-wikkel soos stunnel herstel die verwagte vorm: die kliënt verbind na ’n plaaslike luisteraar, die wikkel open ’n werklike TLS-sessie na die bediener op 443, en ’n tweede wikkel op die bediener stuur die gedekripteerde grepe na die VPN-daemon. Die buitenste sessie lyk nou soos enige ander HTTPS-verbinding. Die VPN-daemon op die bediener moet net op loopback luister, want niks buite die wikkel hoef dit te bereik nie.

Drie afsonderlike dinge moet vir daardie ontwerp in lyn kom. Die kliëntprofiel wys na die plaaslike luisteraar, die bediener-sertifikaat pas by die naam wat die kliënt verifieer, en die deurstuur aan die bedienerkant mik na die poort wat die daemon werklik gebruik. Kry enige een daarvan verkeerd en die verbinding sterf voordat die VPN-laag bereik word. ’n Sertifikaatverskil verskyn dan as ’n wikkelfout eerder as ’n VPN-fout, en daarom is dit die moeite werd om albei logs langs mekaar te lees.

Die roete na die wikkel is die lokval

Sodra die tonnel opkom, wys die verstekroete daarin, en die buitenste TLS-sessie het ’n pad nodig wat nie in die tonnel ingaan wat dit dra nie. ’n Gewone VPN-kliënt beskerm die adres wat hy skakel; ’n gewikkelde kliënt skakel sy eie loopback, so die wikkel se bestemmingsadres is onsigbaar vir daardie 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

Die presiese adresse is joune om in te vul, en die roete moet vir die hele lewe van die verbinding bestaan, nie net by die opstart nie. ’n Klein wikkelskrip wat die roete voor die kliënt byvoeg en daarna verwyder, is betroubaarder as ’n opgedreunde opdrag.

Op Android is die ekwivalent van daardie uitsondering ’n instelling per program: sluit die wikkeltoepassing uit die tonnel, sodat sy eie verkeer deur die mobiele verbinding vertrek. Sonder die uitsluiting word die wikkel in die tonnel ingelei wat hy probeer bou, en die herverbind-lus lyk soos ’n bedienerprobleem.

Lees die tydsberekening voordat jy enigiets verander

’n Sessie wat elke keer na dieselfde interval sterf, is ’n beleidskenmerk eerder as ’n kriptografiese fout, en langdurige vloeibeperkings lewer presies daardie patroon. ’n Verbinding wat dadelik na die handdruk herstel, dui op ’n proxy wat nie van die sertifikaatketting gehou het nie.

Vergelyk die sertifikaatuitgewer van ’n gewone HTTPS-werf vanaf albei netwerke. As die uitgewer op die beperkte netwerk verskil, is iets besig om TLS in die middel te beëindig, en geen wikkel sal daardie onderskepping onveranderd oorleef nie. Dieselfde vergelyking vertel jou of die blok op jou bedienernaam of op elke TLS-sessie na daardie adres gemik is.

Skryf die waargenome gedrag neer: hoe lank die sessie geduur het, of die sokkel oopgegaan het, of die wikkel ’n handdruk gelog het. Elkeen daarvan vernou die volgende toets.

Toets een veranderlike op ’n slag

Toets eers UDP, want sommige netwerke laat dit heeltemal val en ’n UDP-fout sê niks oor 443 nie. Probeer dan TCP 443 sonder die wikkel, dan die wikkel op 443. Lees die kliëntlog by elke stap en stop sodra die gedrag verander.

Verander een element per poging. ’n Nuwe poort, ’n nuwe wikkel en ’n nuwe sifer in dieselfde lopie laat jou nie sê watter van die drie saak gemaak het nie.