VPNトラフィックを抑制し、ポート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インスタンスは、TCPストリームのコンテンツをTLS/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が使用されます。wiresharkを使用してこれを確認できます：stunnelインスタンス間のトラフィックを記録します。wiresharkUI（ストリームのパケットの右ボタン）では、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プロキシトンネルクライアント
ysdxの答えは素晴らしく、トラフィックがネットワーク上でどのように見えるかを非常によく説明しています。
ただし、トラフィック分析はアプリケーションの識別に非常に役立ちます。
OpenVPN接続が回線上のhttps接続のように見え、攻撃者がバイトストリームを読み取ってその接続の種類を知ることができないと仮定しましょう。
典型的なhttps接続は、それほど長くは存続しません。たぶん、ブラウザがメールサーバーへの接続を開いたままにしているのかもしれません。ただし、一般的には、多数の多様なリモートサーバーへの比較的短い接続が多数存在します。
OTOH、OpenVPN接続は数時間または数日間存続する可能性があり、openvpnサーバーとの間で大量のデータを送受信します。
接続を定期的に削除して再起動することで、長期間有効な接続を軽減できます。これは、おそらくアプリケーショントラフィックに影響を与えますが、実行可能かもしれません。ただし、ユーザーとopenvpnサーバーの間を行き来する大量のトラフィックのパターンは、カモフラージュするのがはるかに難しくなります。