解決策 1:
TLS 経由の OpenVPN
VPN はトランスポート プロトコルとして TCP を使用しています。 stunnel インスタンスは、TLS/TCP で TCP ストリームのコンテンツをカプセル化するために使用されます。このプロトコル スタックを取得します:
[IP ]<------------------------>[IP ]
[OpenVPN]<------------------------>[OpenVPN]
[TLS ]<~~~~~>[TLS]
[TCP ]<->[TCP ]<----->[TCP]<->[TCP ]
[IP ]<->[IP ]<----->[IP ]<->[IP ]
[ ] [ ] [ ] [ ]
Server stunnel stunnel Client
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 サーバーでもあることがわかります。
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 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 ]
[ ] [ ] [ ] [ ]
Server HTTPS PROXY stunnel Client
解決策 2:
ysdx の回答は素晴らしく、ネットワーク上でトラフィックがどのように見えるかを非常によく説明しています。
ただし、言及されていないのは、トラフィック分析がアプリケーションの特定に大いに役立つ可能性があることです。
OpenVPN 接続が回線上の https 接続のように見えるため、攻撃者はバイト ストリームを読み取ることができず、接続の種類を知ることができないと仮定しましょう.
典型的な https 接続はそれほど長く存続しません。ブラウザがメール サーバーへの接続を開いたままにしているのかもしれませんが、わかりません。ただし、一般的には、多数の多様なリモート サーバーへの比較的短い接続が多数存在します。
OTOH、OpenVPN 接続は数時間または数日間存続する可能性があり、大量のデータを openvpn サーバーとの間で送受信します。
接続を定期的にドロップして再起動することで、接続の長期化を軽減できます。これはおそらくアプリケーション トラフィックに影響を与えますが、実行できる可能性があります。ただし、あなたとopenvpnサーバーの間を行き来する大量のトラフィックのパターンは、カモフラージュするのがはるかに難しくなります.