Var TLS sitter inuti OpenVPN, och vad som ändrar formen

OpenVPN använder verkligen TLS, och människor utökar rutinmässigt det till ett påstående det inte kan bära: att en tunnel därför ser ut som en webbläsare som besöker en webbplats. Den första delen är sann. Den andra inte. TLS hör här till en kontrollkanal som färdas inne i OpenVPN:s egen behållare, vid sidan av en nyttolastkanal med helt annan kryptografi, så den som inspekterar de inledande byten ser OpenVPN.

Två samtal i ett kuvert

Tänk på en session som två samtal som delar ett kuvert. Det ena validerar certifikat och härleder nyckelmaterial. Det andra krypterar det du faktiskt skickar, med det som det första producerade.

Kuvertet är protokollet. Varje paket börjar med ett litet huvud som namnger sin typ, och det huvudet anländer före allt annat.

Vad som faktiskt anländer först

På grund av den ordningen är det första på ledningen inte en TLS-post. Det är OpenVPN:s huvud, följt av innehållet i den kanal huvudet annonserar. En ClientHello finns där inne, bara inte vid byte noll. Ingen dekryptering behövs för att märka skillnaden, eftersom formen ensam avslöjar den.

Standardvärden spelar roll här också. Strömmen är UDP till 1194 om inte profilen väljer TCP. I båda fallen är det yttre utseendet en tunnel och inte en webbförfrågan.

Tre ärliga sätt att ändra formen

En TLS-terminator som stunnel tar emot TLS på en port i varje ände och lämnar den dekrypterade strömmen till OpenVPN lokalt, så nätverket ser TLS till den porten. Ett protokoll som är TLS från första byten beter sig annorlunda igen: det AnyConnect-kompatibla utbytet som ocserv implementerar liknar fjärråtkomsten företag redan förväntar sig. SSTP, som levereras med Windows, har samma egenskap i en annan produkt.

På Linux bär SSH:s -w-alternativ en punkt-till-punkt-förbindelse inne i en SSH-session, vilket är användbart när SSH är det enda tillåtna protokollet. Det är det billigaste av de fyra om SSH redan fungerar från det nätverket, och det minst användbara om det inte gör det.

Vad ingen av dem ändrar

Ingen av dessa ändrar vad tunneln kan nå. De gör inte en blockerad adress nåbar, de autentiserar ingen och de bestämmer inga rutter.

Ett omslag kostar dig också en komponent. Två lyssnare och två konfigurationsfiler betyder två ställen för ett fel, och båda ser identiska ut från användarens plats. Budgetera för det innan du tar i bruk ett. Sessionen förblir ett enda långlivat krypterat flöde till en destination, och dess volym och timing förblir synliga.

Diagnostisera först, välj sedan

Så diagnostisera först. Tappad UDP besvaras av TCP-läge, och en igenkänd signatur besvaras av ett annat protokoll eller ett omslag. Att välja ett verktyg innan du känner blockeringen är hur människor till slut underhåller tre lager som alla misslyckas av samma skäl.

Ett nätverk som bara tillåter webbportar snävar in valet till ett TLS-baserat protokoll på 443. Att använda alla tre på en gång ger en stapel ingen kan felsöka, så ändra en sak och testa om samma flöde.

Om ingen av dem gäller är det exakta svaret att detta nätverk inte kommer att bära en tunnel åt dig. Det är en iakttagelse och inte ett misslyckande i ansträngningen. Att gå igenom fler alternativ vänder inte ett politiskt beslut som fattats högre upp.

En gräns står framför allt detta. Tillstånd att köra en tunnel på någon annans nätverk är en politisk fråga, avgjord separat från om mekanismen fungerar. Dessa fakta förklarar vad en observatör ser, och de ger inget tillstånd.