Hvor TLS befinner seg inne i OpenVPN, og hva som forandrer formen

OpenVPN bruker nemlig TLS, og folk strekker det stadig til en påstand det ikke holder: at en tunnel dermed ser ut som en nettleser som besøker en nettside. Den første delen stemmer. Den andre gjør det ikke. TLS her hører til en kontrollkanal som ferdes inne i OpenVPNs egen beholder, side om side med en nyttelastkanal med helt forskjellig kryptografi, så den som undersøker de første bytene ser OpenVPN.

To samtaler i én konvolutt

Se for deg en økt som to samtaler som deler én konvolutt. Den ene validerer sertifikater og utleder nøkkelmateriale. Den andre krypterer det du faktisk sender, med det den første har frembrakt.

Konvolutten er protokollen. Hver pakke starter med en liten header som navngir typen, og den headeren kommer før alt annet.

Hva som faktisk kommer først

På grunn av denne rekkefølgen er det første på ledningen ikke en TLS-oppføring. Det er headeren til OpenVPN, deretter innholdet i den kanalen headeren kunngjør. En ClientHello finnes der, bare ikke på byte null. Det trengs ingen dekryptering for å oppdage forskjellen, fordi formen alene avslører den.

Også standardverdier betyr noe her. Strømmen går over UDP til 1194 med mindre profilen velger TCP. I begge tilfeller er det ytre utseendet en tunnel og ikke en webforespørsel.

Tre ærlige måter å forandre formen

En TLS-terminator som stunnel tar imot TLS på en port i hver ende og overlater den dekrypterte strømmen til OpenVPN lokalt, så nettet ser TLS mot den porten. En protokoll som er TLS fra første byte, oppfører seg annerledes igjen: utvekslingen som er kompatibel med AnyConnect og som ocserv implementerer, minner om den bedriftsfjernaksessen mange nett allerede forventer. SSTP, som leveres med Windows, har samme egenskap i et annet produkt.

På Linux bærer -w-valget i SSH en punkt-til-punkt-forbindelse inne i en SSH-økt, noe som er nyttig når SSH er den eneste tillatte protokollen. Det er det rimeligste av de fire hvis SSH allerede virker fra det nettet, og det minst nyttige hvis det ikke gjør det.

Hva ingen av dem forandrer

Ingen av disse forandrer hva tunnelen kan nå. De gjør ikke en blokkert adresse tilgjengelig, de autentiserer ingen, og de avgjør ikke ruter.

En innpakning koster deg også en komponent. To lyttere og to konfigurasjonsfiler betyr to steder der noe kan svikte, og begge ser like ut fra brukerens plass. Ta høyde for det før du tar i bruk en. Økten forblir én langvarig kryptert strøm mot én destinasjon, og volumet og tidspunktet forblir synlig.

Diagnostiser først, velg så

Så diagnostiser først. Falt UDP besvares med TCP-modus, og en gjenkjent signatur besvares med en annen protokoll eller en innpakning. Å velge et verktøy før du kjenner blokkeringen er måten folk ender med å vedlikeholde tre lag som alle svikter av samme grunn.

Et nett som bare tillater webporter, snevrer valget inn til en TLS-basert protokoll på 443. Bruker du alle tre samtidig, får du en stabel ingen kan feilsøke, så endre én ting og test den samme strømmen på nytt.

Hvis ingen av dem passer, er det presise svaret at dette nettet ikke vil bære en tunnel for deg. Det er en konstatering og ikke et nederlag for innsatsen. Å gå gjennom flere alternativer snur ikke en politisk beslutning som er tatt lenger opp.

Én grense står foran alt dette. Tillatelse til å kjøre en tunnel på andres nett er et politisk spørsmål, avgjort atskilt fra om mekanismen virker. Disse fakta forklarer hva en observatør ser, og de gir ikke tillatelse.