Hvor TLS sitter inne i OpenVPN, og hva som endrer formen
OpenVPN kjører TLS for kontrollkanalen sin inne i sin egen innramming, så de første bytene er ikke et web-håndtrykk. Tre alternativer endrer faktisk det som ses.
OpenVPN bruker faktisk TLS, og folk utvider rutinemessig det til en påstand det ikke kan bære: at en tunnel derfor ser ut som en nettleser som besøker et nettsted. Den første delen er sann. Den andre er ikke. TLS her tilhører en kontrollkanal som reiser inne i OpenVPNs egen beholder, ved siden av en nyttelastkanal med helt annen kryptografi, så den som inspiserer de innledende bytene ser OpenVPN.
To samtaler i én konvolutt
Tenk på en økt som to samtaler som deler én konvolutt. Den ene validerer sertifikater og utleder nøkkelmateriale. Den andre krypterer det du faktisk sender, ved hjelp av det den første produserte.
Konvolutten er protokollen. Hver pakke begynner med et lite hode som navngir typen, og det hodet ankommer før alt annet.
Hva som faktisk ankommer først
På grunn av den rekkefølgen er det første på ledningen ikke en TLS-post. Det er OpenVPNs hode, etterfulgt av innholdet i den kanalen hodet annonserer. En ClientHello finnes der inne, bare ikke ved byte null. Det trengs ingen dekryptering for å legge merke til forskjellen, for formen alene avslører den.
Standardverdier betyr noe her også. Strømmen er 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 å endre formen på
En TLS-terminator som stunnel godtar TLS på en port i hver ende og leverer den dekrypterte strømmen til OpenVPN lokalt, så nettet ser TLS til den porten. En protokoll som er TLS fra første byte oppfører seg annerledes igjen: den AnyConnect-kompatible utvekslingen som ocserv implementerer, ligner fjernaksessen bedrifter allerede forventer. SSTP, som følger med Windows, har samme egenskap i et annet produkt.
På Linux bærer SSH-valget -w en punkt-til-punkt-forbindelse inne i en SSH-økt, noe som er nyttig når SSH er den eneste tillatte protokollen. Den er den billigste av de fire hvis SSH allerede virker fra det nettet, og den minst nyttige hvis det ikke gjør det.
Hva ingen av dem endrer
Ingen av disse endrer hva tunnelen kan nå. De gjør ikke en blokkert adresse tilgjengelig, de autentiserer ingen, og de bestemmer ikke ruter.
En innpakning koster deg også en komponent. To lyttere og to konfigurasjonsfiler betyr to steder for en feil, og begge ser identiske ut fra brukerens plass. Budsjetter for det før du tar i bruk en. Økten forblir en enkelt langvarig kryptert strøm til én destinasjon, og volumet og tidspunktet forblir synlig.
Diagnostiser først, velg deretter
Så diagnostiser først. Droppet UDP besvares av TCP-modus, og en gjenkjent signatur besvares av en annen protokoll eller en innpakning. Å velge et verktøy før du kjenner blokkeringen er hvordan folk ender opp med å vedlikeholde tre lag som alle feiler av samme grunn.
Et nett som bare tillater webporter, snevrer valget inn til en TLS-basert protokoll på 443. Å bruke alle tre på én gang gir en stabel ingen kan feilsøke, så endre én ting og test den samme strømmen på nytt.
Hvis ingen av dem gjelder, er det nøyaktige 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 reverserer ikke en politisk beslutning tatt lenger opp.
Én grense står foran alt dette. Tillatelse til å kjøre en tunnel på noen andres nett er et politisk spørsmål, avgjort separat fra hvorvidt mekanismen fungerer. Disse fakta forklarer hva en observatør ser, og de gir ikke tillatelse.