Waar TLS in OpenVPN zit, en wat de vorm verandert

OpenVPN gebruikt inderdaad TLS, en mensen rekken dat steevast op tot een bewering die het niet kan dragen: dat een tunnel er daardoor uitziet als een browser die een site bezoekt. Het eerste deel klopt. Het tweede niet. TLS hoort hier bij een besturingskanaal dat binnen OpenVPN’s eigen container reist, naast een payloadkanaal met heel andere cryptografie, dus wie de openingsbytes bekijkt, ziet OpenVPN.

Twee gesprekken in één envelop

Zie een sessie als twee gesprekken die één envelop delen. Het ene valideert certificaten en leidt sleutelmateriaal af. Het andere versleutelt wat je werkelijk verstuurt, met wat het eerste heeft opgeleverd.

De envelop is het protocol. Elk pakket begint met een kleine kop die het type noemt, en die kop komt vóór alles anders.

Wat er werkelijk eerst aankomt

Door die ordening is het eerste op de lijn geen TLS-record. Het is de kop van OpenVPN, gevolgd door de inhoud van welk kanaal de kop ook aankondigt. Een ClientHello zit daarin, alleen niet op byte nul. Er is geen ontsleuteling nodig om het verschil op te merken, want de vorm alleen verraadt het al.

Standaardwaarden tellen hier ook. De stroom is UDP naar 1194 tenzij het profiel TCP kiest. In beide gevallen is het uiterlijk een tunnel en geen webverzoek.

Drie eerlijke manieren om de vorm te veranderen

Een TLS-terminator zoals stunnel accepteert TLS op een poort aan elk uiteinde en geeft de ontsleutelde stroom lokaal aan OpenVPN, zodat het netwerk TLS naar die poort ziet. Een protocol dat vanaf de eerste byte TLS is, gedraagt zich weer anders: de AnyConnect-compatibele uitwisseling die ocserv implementeert, lijkt op de zakelijke remote access die veel netwerken al verwachten. SSTP, dat met Windows meekomt, heeft dezelfde eigenschap in een ander product.

Op Linux draagt de optie -w van SSH een punt-tot-puntverbinding binnen een SSH-sessie, wat nuttig is wanneer SSH het enige toegestane protocol is. Het is de goedkoopste van de vier als SSH al vanaf dat netwerk werkt, en de minst nuttige als dat niet zo is.

Wat geen van hen verandert

Geen van deze verandert wat de tunnel kan bereiken. Ze maken een geblokkeerd adres niet bereikbaar, ze authenticeren niemand en ze beslissen geen routes.

Een wrapper kost je ook een component. Twee luisteraars en twee configuratiebestanden betekenen twee plekken voor een storing, en beide zien er vanaf de stoel van de gebruiker identiek uit. Begroot dat voordat je er een neemt. De sessie blijft één langdurige versleutelde stroom naar één bestemming, en het volume en de timing blijven zichtbaar.

Diagnoseer eerst, kies dan

Dus diagnoseer eerst. Weggevallen UDP wordt beantwoord met TCP-modus, en een herkende signatuur met een ander protocol of een wrapper. Een hulpmiddel kiezen voordat je de blokkade kent, is hoe mensen uiteindelijk drie lagen onderhouden die allemaal om dezelfde reden falen.

Een netwerk dat alleen webpoorten toestaat, beperkt de keuze tot een TLS-gebaseerd protocol op 443. Alle drie tegelijk toepassen geeft een stapel die niemand kan debuggen, dus verander één ding en test dezelfde stroom opnieuw.

Als geen ervan van toepassing is, is het juiste antwoord dat dit netwerk geen tunnel voor je zal dragen. Dat is een bevinding en geen mislukking van inspanning. Meer opties doorlopen draait een eerder genomen beleidsbesluit niet terug.

Eén grens staat voor dit alles. Toestemming om een tunnel op iemands anders netwerk te draaien is een beleidskwestie, los beslist van of het mechanisme werkt. Deze feiten leggen uit wat een waarnemer ziet, en ze geven geen toestemming.