vpnトラフィックをstunnelし、ポート443でSSLトラフィックのように見えることを確認します

発信および着信トラフィックを可能な限りSSLトラフィックにできるだけ合法的に見えるようにしています。OpenVPNトラフィックではなくSSLトラフィックのように見えるように、独自のトラフィックをDPIする方法はありますか？そして私の設定に基づいて、すべてのトラフィックはSSLポートであるポート443を使用しますか？

私の構成は次のとおりです。

ラップトップ上のSTUNNEL：

[openvpn]
# Set sTunnel to be in client mode (defaults to server)
client = yes  
# Port to locally connect to
accept = 127.0.0.1:1194  
# Remote server for sTunnel to connect to
connect = REMOTE_SERVER_IP:443

ラップトップ上のOPENVPN CONFIG：

client
dev tun
proto tcp
remote 127.0.0.1 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun

サーバー上のSTUNNEL CONFIG：

sslVersion = all
options = NO_SSLv2
;chroot = /var/lib/stunnel4/
; PID is created inside the chroot jail
pid = /stunnel4.pid
; Debugging stuff (may useful for troubleshooting)
 debug = 7
 output = /var/log/stunnel4/stunnel4.log
setuid = root
setgid = root
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
compression = zlib
[openvpn]
accept = REMOTE_SERVER_IP:443
connect = REMOTE_SERVER_IP:11440
cert=/etc/stunnel/server.pem
key=/etc/stunnel/server.key

サーバー上のOPENVPN CONFIG：

local REMOTE_SERVER_IP
port 11440
proto tcp

OpenVPN over TLS

VPNはトランスポートプロトコルとしてTCPを使用しています。stunnelインスタンスは、TLS / TCPでTCPストリームのコンテンツをカプセル化するために使用されます。このプロトコルスタックを取得します。

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 サーバーstunnel stunnelクライアント

stunnelインスタンス間では、このプロトコルスタックがネットワーク上にあります。

[IP]
[OpenVPN]
[TLS]
[TCP（443）]
[IP]
[...]

TLSはそのペイロードを暗号化するため、攻撃者は次のものしか見ることができません。

[??? ]
[TLS]
[TCP（443）]
[IP]
[...]

はい、それはプレーンなTLSトラフィックです（HTTP / TLS、SMTP / TLS、POP / TLS、またはトラフィックを見る人にとっては他のものでも構いませんが、TCPポート443が使用されるためHTTP / TLSによく似ています）。Wiresharkを使用してこれを確認できます。stunnelインスタンス間のトラフィックを記録します。Wireshark UI（ストリームのパケットの右ボタン）で、wiresharkにトラフィックをTLSとして解釈するように要求できます。TLSトラフィックとして認識します（異なるTLSメッセージが表示されますが、TLSセッションのペイロードは表示されません） 。

クライアントでSNIを使用して、最新のブラウザーが行うように見えるようにすることができます。ALPNを使用することもできますが、stunnelは現在それを処理していません。

TLSが組み込まれたOpenVPN

これに対して、OpenVPNを使用している場合は、次のようなものがあります。

[IP]
[OpenVPN]
[TCP]
[IP]
[...]

これは次のようになります。

[??? ]
[OpenVPN]
[TCP]
[IP]
[...]

組み込みのTLSレイヤーは（IP、イーサネット）パケットをカプセル化しませんが、セッションのセットアップと認証にのみ使用されます：

[TLS]
[OpenVPN]
[TCP]
[IP]
[...]

この場合、トラフィックは単純なTLSトラフィックのようには見えませんが、明らかにOpenVPNです。WiresharkでこのトラフィックをOpenVPNとして解釈すると、OpenVPNメッセージとその中のTLSメッセージ（ペイロードではない）を認識します。

警告

受動的な攻撃者がリモートサーバーが実際にOpenVPNサーバーであることを認識できない場合、アクティブな攻撃者はこれを見つけることができることに注意する必要があります：TLS経由でサーバーに接続するだけで、彼はHTTP / TLSサーバーではないことを確認します。OpenVPNプロトコルを話そうとすることで、彼はあなたのサーバーがOpenVPN / TLSサーバーであることを検出できます。

クライアント認証を使用したOpenVPN over TLS

これについて心配しているので、TLSクライアント認証を有効にできます。攻撃者は、有効なTLSセッションを開始できず、TLSを介してカプセル化されているペイロードを推測できません。

*警告：** OpenVPNの組み込みTLSサポートについては説明していません（なぜ役に立たないかについては上記を参照してください）。

多重化OpenVPN / TLSおよびHTTP / TLS

別のソリューションは、TLSセッションを介してHTTPとOpenVPNの両方を提供することです。 sslhを使用して、プロトコルのペイロードを自動的に検出し、プレーンHTTP / TCPサーバーまたはOpenVPN / TCPサーバーにディスパッチできます。サーバーは標準のHTTP / TLSサーバーのように見えますが、このサーバーでOpenVPN / TLSを話そうとしている人は、それが実際にOpenVPN / TLSサーバーでもあることを検出できます。

        OpenVPN / TCP
          またはHTTP / TCP       
[1] .---------。.------。HTTP / TCP .-------------。
-> | トンネル| ----> | sslh | -------> | HTTPサーバー|
   '---------' '------' | '-------------'
                           | .----------------。
                           '------> | OpenVPNサーバー|
                        OpenVPN / TCP '----------------'

[1] = OpenVPN / TLS / TCPまたはHTTP / TLS / TCPのいずれか

OpenVPN over HTTP CONNECT over TLS

別の解決策は、標準のHTTP / TLSサーバーを使用し、HTTP CONNECT / TLSを使用してOpenVPNサーバーに接続することです。これは標準のHTTPサーバーのように見えます。HTTP CONNECTリクエストを許可するために、クライアントの認証を要求することもできます（squidはこれを行うことができるはずです）。

OpenVPNには、HTTPプロキシを使用するオプションがあります。

http-proxy proxy.example.com

これを、リモートHTTPSプロキシに接続するstunnelインスタンスと組み合わせることができるはずです。

http-proxy 127.0.0.1 8443
remote vpn.example.com

このプロトコルスタックを実装するもの：

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [HTTP] <-------------> [HTTP]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 サーバーHTTPS PROXY stunnelクライアント

ysdxの答えは素晴らしく、トラフィックがワイヤ上でどのように見えるかを非常によく説明しています。

ただし、トラフィック分析はアプリケーションの特定に大きく役立つ可能性があることに言及していません。

OpenVPN接続が有線のhttps接続のように見えるため、攻撃者がバイトストリームを読み取って接続の種類を知ることができないと仮定しましょう。

一般的なhttps接続は、それほど長く生きることはありません。おそらく、ブラウザがメールサーバーへの接続を開いたままにしているのかもしれません。ただし一般的には、多くの多様なリモートサーバーへの比較的短い接続が多数存在します。

OTOH、OpenVPN接続は数時間または数日間存続する可能性があり、openvpnサーバーとの間で大量のデータをやり取りします。

定期的に接続をドロップして再起動することにより、長期間有効な接続を軽減できます。これはおそらくアプリケーションのトラフィックに影響を与えますが、実行可能かもしれません。ただし、あなたとopenvpnサーバーの間を流れる大量のトラフィックのパターンは、偽装するのがはるかに難しくなります。