Hvor TLS sidder indeni OpenVPN, og hvad der ændrer formen

OpenVPN bruger faktisk TLS, og folk udvider rutinemæssigt det til en påstand, den ikke kan bære: at en tunnel derfor ligner en browser, der besøger et websted. Den første del er sand. Den anden er ikke. TLS hører her til en kontrolkanal, der rejser inde i OpenVPNs egen beholder, side om side med en nyttelastkanal med helt anden kryptografi, så den, der inspicerer de indledende byte, ser OpenVPN.

To samtaler i én konvolut

Tænk på en session som to samtaler, der deler én konvolut. Den ene validerer certifikater og udleder nøglemateriale. Den anden krypterer det, du faktisk sender, ved hjælp af det, den første frembragte.

Konvolutten er protokollen. Hver pakke begynder med et lille header, der navngiver sin type, og den header ankommer før alt andet.

Hvad der faktisk ankommer først

På grund af den rækkefølge er det første på ledningen ikke en TLS-post. Det er OpenVPNs header, efterfulgt af indholdet af den kanal, headeren annoncerer. En ClientHello findes derinde, bare ikke ved byte nul. Der skal ikke dekrypteres for at bemærke forskellen, for formen alene afslører den.

Standardværdier betyder også noget her. Strømmen er UDP til 1194, medmindre profilen vælger TCP. I begge tilfælde er det ydre udseende en tunnel snarere end en webforespørgsel.

Tre ærlige måder at ændre formen på

En TLS-terminator som stunnel accepterer TLS på en port i hver ende og giver den dekrypterede strøm til OpenVPN lokalt, så netværket ser TLS til den port. En protokol, der er TLS fra første byte, opfører sig anderledes igen: den AnyConnect-kompatible udveksling, som ocserv implementerer, ligner den virksomhedsfjernadgang, som mange netværk allerede forventer. SSTP, der leveres med Windows, har samme egenskab i et andet produkt.

På Linux bærer SSH's -w-mulighed et punkt-til-punkt-link inde i en SSH-session, hvilket er nyttigt, når SSH er den eneste tilladte protokol. Den er den billigste af de fire, hvis SSH allerede virker fra det netværk, og den mindst nyttige, hvis det ikke gør.

Hvad ingen af dem ændrer

Ingen af disse ændrer, hvad tunnelen kan nå. De gør ikke en blokeret adresse tilgængelig, de autentificerer ikke nogen, og de bestemmer ikke ruter.

En indpakning koster dig også en komponent. To lyttere og to konfigurationsfiler betyder to steder for en fejl, og begge ser identiske ud fra brugerens plads. Budgetter for det, før du tager en i brug. Sessionen forbliver en enkelt langlivet krypteret strøm til én destination, og dens volumen og timing forbliver synlige.

Diagnostiser først, vælg derefter

Så diagnostiser først. Droppet UDP besvares af TCP-tilstand, og en genkendt signatur besvares af en anden protokol eller en indpakning. At vælge et værktøj, før du kender blokeringen, er hvordan folk ender med at vedligeholde tre lag, der alle fejler af samme grund.

Et netværk, der kun tillader webporte, indsnævrer valget til en TLS-baseret protokol på 443. At anvende alle tre på én gang giver en stak, som ingen kan fejlfinde, så ændr én ting og test den samme strøm igen.

Hvis ingen af dem gælder, er det præcise svar, at dette netværk ikke vil bære en tunnel for dig. Det er en konstatering snarere end en fiasko for indsatsen. At cykle gennem flere muligheder omgør ikke en politisk beslutning truffet længere oppe.

En grænse står foran det hele. Tilladelse til at køre en tunnel på en andens netværk er en politikbeslutning, truffet separat fra hvorvidt mekanismen fungerer. Disse fakta forklarer, hvad en observatør ser, og de giver ikke tilladelse.