Hol ül a TLS az OpenVPN-en belül, és mi változtatja a formát

OpenVPN valóban használ TLS-t, és az emberek ezt rutinszerűen olyan állítássá tágítják, amelyet nem tud elhordozni: hogy az alagút ezért úgy néz ki, mint egy webhelyet meglátogató böngésző. Az első rész igaz. A második nem. A TLS itt egy vezérlőcsatornához tartozik, amely az OpenVPN saját konténerén belül utazik, mellette egy teljesen más kriptográfiájú hasznos teher csatorna van, így aki a nyitó bájtokat vizsgálja, OpenVPN-t lát.

Két beszélgetés egy borítékban

Gondoljon egy munkamenetre úgy, mint két beszélgetésre, amelyek egy borítékot osztanak meg. Az egyik tanúsítványokat ellenőriz és kulcsanyagot származtat. A másik titkosítja, amit valójában küld, felhasználva azt, amit az első előállított.

A boríték maga a protokoll. Minden csomag egy kis fejléccel kezdődik, amely megnevezi a típusát, és ez a fejléc minden más előtt megérkezik.

Mi érkezik valójában elsőként

E sorrend miatt a vezetéken az első dolog nem TLS-rekord. Ez az OpenVPN fejléce, majd az általa bejelentett csatorna tartalma. ClientHello létezik benne, csak éppen nem a nulladik bájton. A különbség észleléséhez nem kell visszafejtés, mert a forma maga elárulja.

Az alapértelmezések itt is számítanak. Az adatfolyam UDP-n megy az 1194-es portra, kivéve ha a profil TCP-t választ. Mindkét esetben a külső megjelenés alagút, nem webes kérés.

Három őszinte mód a forma megváltoztatására

Egy TLS-terminátor, például a stunnel, mindkét végén TLS-t fogad egy porton, és a visszafejtett folyamot helyben átadja az OpenVPN-nek, így a hálózat TLS-t lát afelé a port felé. Az a protokoll, amely az első bájttól TLS, megint másképp viselkedik: az ocserv által megvalósított, AnyConnect-kompatibilis csere hasonlít arra a vállalati távoli hozzáférésre, amelyet sok hálózat már elvár. Az SSTP, amely a Windowsszal érkezik, ugyanezzel a tulajdonsággal bír egy másik termékben.

Linuxon az SSH -w opciója pont-pont kapcsolatot visz egy SSH-munkameneten belül, ami akkor hasznos, ha az SSH az egyetlen engedélyezett protokoll. A négy közül ez a legolcsóbb, ha az SSH már működik arról a hálózatról, és a legkevésbé hasznos, ha nem.

Mit nem változtat egyikük sem

Ezek egyike sem változtat azon, mit érhet el az alagút. Nem teszik elérhetővé a blokkolt címet, nem hitelesítenek senkit, és nem döntenek útvonalakról.

Egy burkoló egy komponensbe is kerül. Két figyelő és két konfigurációs fájl két hibapontot jelent, és mindkettő ugyanúgy néz ki a felhasználó helyéről. Számoljon ezzel, mielőtt átvesz egyet. A munkamenet egyetlen hosszú életű titkosított folyam marad egy cél felé, és annak térfogata és időzítése látható marad.

Először diagnosztizáljon, aztán válasszon

Tehát először diagnosztizáljon. Az eldobott UDP-re a TCP mód a válasz, a felismert aláírásra pedig egy másik protokoll vagy egy burkoló. Eszközt választani a blokkolás ismerete előtt az az út, amelyen az emberek végül három réteget tartanak fenn, amelyek mind ugyanezen okból hibáznak.

Az a hálózat, amely csak webportokat engedélyez, a választást a 443-as TLS-alapú protokollra szűkíti. Mindhármat egyszerre alkalmazva olyan vermet kap, amelyet senki nem tud hibakeresni, ezért egy dolgot változtasson, és tesztelje újra ugyanazt a folyamot.

Ha egyik sem alkalmazható, a pontos válasz az, hogy ez a hálózat nem visz alagutat Önnek. Ez megállapítás, nem az igyekezet kudarca. Több lehetőség végigpróbálása nem fordítja vissza a feljebb hozott szakpolitikai döntést.

Egy határ áll mindezek előtt. Az engedély arra, hogy valaki más hálózatán alagutat futtasson, szakpolitikai kérdés, amelyről külön döntenek attól, hogy a mechanizmus működik-e. Ezek a tények megmagyarázzák, mit lát egy megfigyelő, és nem adnak engedélyt.