Unde stă TLS în interiorul OpenVPN și ce schimbă forma

OpenVPN folosește într-adevăr TLS, iar oamenii extind de obicei asta la o afirmație pe care nu o poate duce: că un tunel arată astfel ca un browser care vizitează un site. Prima parte este adevărată. A doua nu. TLS aparține aici unui canal de control care călătorește în interiorul propriului container al OpenVPN, alături de un canal de încărcare cu o criptografie complet diferită, așa că cine inspectează primii octeți vede OpenVPN.

Două conversații într-un singur plic

Gândiți-vă la o sesiune ca la două conversații care împart un singur plic. Una validează certificatele și derivă materialul cheii. Cealaltă criptează ce trimiteți efectiv, folosind ce a produs prima.

Plicul este protocolul. Fiecare pachet începe cu un antet mic care îi numește tipul, iar acel antet sosește înaintea oricui altceva.

Ce sosește efectiv primul

Din cauza acestei ordini, primul lucru pe fir nu este o înregistrare TLS. Este antetul OpenVPN, urmat de conținutul canalului pe care antetul îl anunță. Un ClientHello există acolo, doar că nu la octetul zero. Nu este nevoie de nicio decriptare pentru a observa diferența, pentru că forma singură o trădează.

Valorile implicite contează și aici. Fluxul este UDP către 1194 dacă profilul nu alege TCP. În ambele cazuri aspectul exterior este un tunel, nu o cerere web.

Trei moduri oneste de a schimba forma

Un terminator TLS precum stunnel acceptă TLS pe un port la fiecare capăt și predă fluxul decriptat către OpenVPN local, așa că rețeaua vede TLS către acel port. Un protocol care este TLS de la primul octet se comportă din nou altfel: schimbul compatibil cu AnyConnect pe care îl implementează ocserv seamănă cu accesul la distanță corporativ pe care multe rețele îl așteaptă deja. SSTP, care vine cu Windows, are aceeași proprietate într-un alt produs.

Pe Linux, opțiunea -w a SSH transportă o legătură punct-la-punct în interiorul unei sesiuni SSH, ceea ce este util când SSH este singurul protocol permis. Este cea mai ieftină dintre cele patru dacă SSH funcționează deja din acea rețea, și cea mai puțin utilă dacă nu.

Ce nu schimbă niciuna dintre ele

Niciuna dintre acestea nu schimbă ce poate atinge tunelul. Nu fac o adresă blocată accesibilă, nu autentifică pe nimeni și nu decid rute.

Un ambalaj te costă și o componentă. Doi ascultători și două fișiere de configurare înseamnă două locuri de eșec, iar ambele arată identic din scaunul utilizatorului. Bugetați asta înainte de a adopta unul. Sesiunea rămâne un singur flux criptat de lungă durată către o destinație, iar volumul și momentul ei rămân vizibile.

Mai întâi diagnosticați, apoi alegeți

Deci mai întâi diagnosticați. UDP-ul abandonat primește răspuns prin modul TCP, iar o semnătură recunoscută primește răspuns printr-un alt protocol sau un ambalaj. Alegerea unui instrument înainte de a cunoaște blocajul este felul în care oamenii ajung să întrețină trei straturi care eșuează toate din același motiv.

O rețea care permite doar porturi web restrânge alegerea la un protocol bazat pe TLS pe 443. Aplicarea tuturor trei deodată dă un stivă pe care nimeni nu o poate depana, așa că schimbați un singur lucru și retestați același flux.

Dacă niciuna nu se aplică, răspunsul exact este că această rețea nu va transporta un tunel pentru dumneavoastră. Aceasta este o constatare și nu un eșec al efortului. Parcurgerea mai multor opțiuni nu inversează o decizie de politică luată mai sus.

O limită stă în fața tuturor acestora. Permisiunea de a rula un tunel în rețeaua altcuiva este o chestiune de politică, decisă separat de dacă mecanismul funcționează. Aceste fapte explică ce vede un observator și nu acordă permisiune.