OpenVPN via een HTTP-proxy: lees eerst het CONNECT-antwoord

Richt een VPN-client op een bedrijfs-HTTP-proxy, en het eerste nuttige feit is dat de proxy niet het protocol van de VPN spreekt. Hij opent een gewone TCP-verbinding naar het adres dat u opgaf en stapt dan opzij, zodat uw client en de server hun eigen uitwisseling via die stroom doen. Alles wat de client nodig heeft, van het transporttype tot de listener van de server, moet bij die opzet passen. Twee mismatches verklaren de meeste storingen: een UDP-profiel dat op een CONNECT-proxy is gericht, en een proxy-antwoord dat voor een VPN-fout wordt aangezien.

Wat de proxy draagt, en wat niet

De proxy is slechts een transportstap. Hij wordt niet uw browserproxy, hij cachet de sites die u via de tunnel bezoekt niet, en hij ziet het interne verkeer niet, tenzij iemand bewust inspectie heeft ingesteld. De tunnel die hij opent, is voor hem ontworpen om ondoorzichtig te zijn.

Dat betekent ook dat de proxy een server zonder bijpassende listener niet kan repareren. Toestemming om een bestemming te bereiken en een dienst die op die bestemming luistert, zijn twee afzonderlijke feiten, en alleen het eerste hoort bij de proxybeheerder.

De drager moet aan beide kanten TCP zijn

Een conventionele CONNECT-proxy geeft alleen een bytestroom door , dus de client moet een stroomtransport gebruiken. Een clientfragment voor dat geval ziet er zo uit:

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

De serverkant heeft een echte TCP-listener nodig op de poort die in de remote-regel wordt genoemd. proto udp in een profiel wijzigen in proto tcp-client maakt een client die een stroom verwacht; het maakt de stroom aan de andere kant niet. Als dezelfde server op die poort ook via UDP antwoordt, is dat een andere listener, niet een tweede modus van dezelfde.

Waar een aparte TCP-instantie bestaat, zijn het tunnelapparaat, de adrespool en de routering ervan eigen resources. Een werkende configuratie kopiëren en het transportwoord wijzigen laat die resources naar de oorspronkelijke instantie wijzen, wat een verbinding oplevert die authenticeert en vervolgens niets routeert.

Lees het proxy-antwoord vóór het VPN-resultaat

De eerste uitwisseling van de client is een verzoekregel die de bestemmingshost en -poort noemt. Het antwoord op die regel vertelt u of er überhaupt een bytestroom bestaat, en het komt voordat een certificaat of inloggegeven wordt gecontroleerd:

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

Een antwoord van klasse 200 op CONNECT betekent dat de stroom bestaat. Het zegt niets over of het gatewaycertificaat vertrouwd is, of de gedeelde sleutel klopt, of het gebruikersaccount geldig is. Die controles gebeuren daarna, binnen de stroom, en ze mislukken met de eigen berichten van de client in plaats van met een HTTP-statusregel. Zoek in het clientlog naar de eerste OpenVPN gebeurtenis na de handshake met de proxy, niet naar de laatste regel voordat het venster sloot.

Proxy-inloggegevens en VPN-inloggegevens zijn vaak verschillende identiteiten bij verschillende teams. Een 407 is geen verkeerd wachtwoord van het VPN-account, en een geweigerd certificaat is geen proxyrechtenprobleem.

Wat CONNECT niet blootlegt

Een expliciete CONNECT-tunnel is geen onderschepping. De proxy geeft bytes door en beëindigt de TLS-sessie van de VPN niet, dus de verificatie van het servercertificaat door de client blijft zinvol en moet aan blijven. Verificatie uitzetten om een proxy te passeren lost een ander probleem op dan het uwe.

Er bestaan aparte regelingen waarbij een organisatie TLS bewust beëindigt en inspecteert. Die vereisen hun eigen vertrouwensconfiguratie en hun eigen beleidsbeslissing, en ze zijn niet wat een gewone http-proxy-regel vraagt.

De prijs van TCP in TCP

De tunnel over TCP dragen houdt de buitenste stroom geordend en met herverzending, en het binnenste verkeer is meestal ook TCP. De twee herstelmechanismen coördineren niet, dus één verloren segment kan alles blokkeren wat die buitenste stroom deelt, tot het opnieuw wordt verzonden. Dat is een echte ruil voor compatibiliteit, geen gratis upgrade.

Gebruik het proxypad wanneer het netwerk u geen alternatief laat, en geef de voorkeur aan een direct UDP-pad waar het beleid dat toestaat. Controleer in elk geval na een wijziging dat dezelfde proxy, bestemming en hetzelfde profiel de volgende fase bereiken; een browser die op dat adres een pagina laadt, gebruikt een ander protocol en bewijst niets over de tunnel.