Solusi 1:
Buka VPN melalui TLS
VPN Anda menggunakan TCP sebagai protokol transport. Contoh stunnel digunakan untuk mengenkapsulasi konten aliran TCP di TLS/TCP. Anda mendapatkan tumpukan protokol ini:
[IP ]<------------------------>[IP ]
[OpenVPN]<------------------------>[OpenVPN]
[TLS ]<~~~~~>[TLS]
[TCP ]<->[TCP ]<----->[TCP]<->[TCP ]
[IP ]<->[IP ]<----->[IP ]<->[IP ]
[ ] [ ] [ ] [ ]
Server stunnel stunnel Client
Di antara instance stunnel Anda memiliki tumpukan protokol ini di kabel:
[IP ] [OpenVPN ] [TLS ] [TCP(443)] [IP ] [... ]
Saat TLS mengenkripsi muatannya, penyerang hanya dapat melihat:
[??? ] [TLS ] [TCP(443)] [IP ] [... ]
Jadi ya, ini adalah lalu lintas TLS biasa (bisa berupa HTTP/TLS, SMTP/TLS, POP/TLS atau apa pun untuk seseorang yang melihat lalu lintas tetapi sangat mirip dengan HTTP/TLS karena port TCP 443 digunakan). Anda dapat memeriksanya dengan menggunakan wireshark:catat lalu lintas di antara instance stunnel. Di UI wireshark (tombol kanan pada paket aliran), Anda dapat meminta wireshark untuk menginterpretasikan lalu lintas sebagai TLS:ini akan mengenalinya sebagai lalu lintas TLS (Anda akan melihat pesan TLS yang berbeda tetapi bukan muatan sesi TLS) .
Anda mungkin ingin menggunakan SNI di klien agar terlihat seperti browser modern. Anda mungkin ingin menggunakan ALPN juga, tetapi stunnel saat ini tidak menanganinya.
OpenVPN dengan TLS bawaan
Sebagai perbandingan, jika Anda menggunakan OpenVPN, Anda akan mendapatkan sesuatu seperti ini:
[IP ] [OpenVPN ] [TCP ] [IP ] [... ]
Yang terlihat seperti ini:
[??? ] [OpenVPN ] [TCP ] [IP ] [... ]
Lapisan TLS bawaan tidak merangkum paket (IP, Ethernet) tetapi hanya digunakan untuk menyiapkan sesi dan mengautentikasi:
[TLS ] [OpenVPN ] [TCP ] [IP ] [... ]
Dalam hal ini, lalu lintas Anda tidak terlihat seperti lalu lintas TLS biasa tetapi jelas OpenVPN. Jika Anda menafsirkan lalu lintas ini sebagai OpenVPN di wireshark, Anda akan mengenali pesan OpenVPN dan di dalamnya pesan TLS (tetapi bukan payload).
Peringatan
Anda harus menyadari bahwa jika penyerang pasif tidak dapat mengetahui bahwa server jarak jauh Anda sebenarnya adalah server OpenVPN, penyerang aktif akan dapat mengetahuinya:cukup dengan menghubungkan ke server Anda melalui TLS, dia akan dapat untuk mengonfirmasi bahwa itu tidak server HTTP/TLS. Dengan mencoba berbicara tentang protokol OpenVPN, dia akan dapat mendeteksi bahwa server Anda adalah server OpenVPN/TLS.
OpenVPN melalui TLS dengan autentikasi klien
Jika Anda khawatir tentang hal ini, Anda dapat mengaktifkan autentikasi klien TLS:penyerang tidak akan dapat memulai sesi TLS yang berfungsi dan tidak akan dapat menebak muatan mana yang dienkapsulasi melalui TLS.
*Peringatan:** Saya tidak berbicara tentang dukungan TLS bawaan di OpenVPN (lihat di atas untuk penjelasan mengapa ini tidak membantu Anda).
OpenVPN/TLS dan HTTP/TLS multipleks
Solusi lain adalah melayani HTTP dan OpenVPN melalui sesi TLS. sslh dapat digunakan untuk secara otomatis mendeteksi muatan protokol dan mengirimkannya ke server HTTP/TCP biasa atau server OpenVPN/TCP Anda. Server akan terlihat seperti server HTTP/TLS standar tetapi seseorang yang mencoba berbicara OpenVPN/TLS dengan server ini akan dapat mendeteksi bahwa itu sebenarnya adalah server OpenVPN/TLS juga.
either OpenVPN/TCP
or HTTP/TCP
[1].---------. .------.HTTP/TCP.-------------.
-->| stunnel |---->| sslh |------->| HTTP server |
'---------' '------'| '-------------'
| .----------------.
'------>| OpenVPN server |
OpenVPN/TCP'----------------'
[1]= Either OpenVPN/TLS/TCP or HTTP/TLS/TCP
OpenVPN melalui HTTP CONNECT melalui TLS
Solusi lain adalah menggunakan server HTTP/TLS standar dan menggunakan HTTP CONNECT/TLS untuk terhubung ke server OpenVPN:ini akan terlihat seperti server HTTP standar. Anda bahkan dapat meminta autentikasi klien untuk mengotorisasi permintaan HTTP CONNECT (seharusnya squid dapat melakukan ini).
OpenVPN memiliki opsi untuk menggunakan Proksi HTTP:
http-proxy proxy.example.com
Anda seharusnya dapat menggabungkan ini dengan instance stunnel yang terhubung ke PROXY HTTPS jarak jauh:
http-proxy 127.0.0.1 8443
remote vpn.example.com
Yang akan menerapkan tumpukan protokol ini:
[IP ]<------------------------>[IP ]
[OpenVPN]<------------------------>[OpenVPN]
[HTTP ]<------------->[HTTP ]
[TLS ]<~~~~~>[TLS]
[TCP ]<->[TCP ]<----->[TCP]<->[TCP ]
[IP ]<->[IP ]<----->[IP ]<->[IP ]
[ ] [ ] [ ] [ ]
Server HTTPS PROXY stunnel Client
Solusi 2:
jawaban ysdx bagus, dan menjelaskan dengan sangat baik bagaimana tampilan lalu lintas di kabel.
Namun, yang tidak disebutkan adalah bahwa analisis lalu lintas dapat sangat membantu dalam mengidentifikasi aplikasi.
Mari kita asumsikan bahwa koneksi OpenVPN Anda terlihat seperti koneksi https pada kabel, sehingga penyerang tidak dapat membaca aliran byte dan mengetahui jenis koneksinya.
Koneksi https tipikal tidak akan hidup terlalu lama. Mungkin browser Anda tetap membuka koneksi ke server email Anda, saya tidak tahu. Namun secara umum, akan ada banyak koneksi yang relatif singkat ke banyak server jarak jauh yang beragam.
OTOH, koneksi OpenVPN mungkin hidup berjam-jam atau berhari-hari, dan akan mengirim banyak data bolak-balik ke server openvpn.
Anda dapat memitigasi koneksi yang berumur panjang dengan menjatuhkan dan memulai ulang koneksi secara berkala. Ini mungkin memiliki implikasi untuk lalu lintas aplikasi Anda, tetapi mungkin bisa diterapkan. Namun, pola lalu lintas yang banyak dan banyak antara Anda dan server openvpn akan jauh lebih sulit untuk disamarkan.