SoftEtherVPNのプロトコルのファイアウォール透明性はびっくり！しかし、Android プラットフォームのユーザーの多くは、それがもたらす利便性も享受したいと考えています。

[oscar]

VPN over DNS VPN over ICMPは前例のないファイアウォール透明性てパケットblock/dropを直接無視するびっくり！

しかし、Windows や Linux のように、Android の一般的なプラットフォームに広くインストール可能なアプリがあれば素晴らしい状況になるでしょう。

現在、Google Play ストアには、独立したサードパーティ開発者によって開発されたアプリが多数存在します。これらのアプリは Windows や Linux 版のアプリと同等の機能を実現しているかもしれませんが、SoftEtherVPN はオープンソースライセンスに基づいています。Google Play ストアを収益化に利用しているこれらの開発者は、適合性規範 (CoC) のルールを遵守していないようです。iOS プラットフォームでは、https://apps.apple.com/us/app/sstp-connect/id1543667909 が iOS 上で SoftEtherVPN の VPN 機能を完全に実装しています。

私のリクエストを SoftEther メンテナンス チームに伝え、Android プラットフォーム用の SoftEtherVPN クライアント/サーバー アプリの開発を優先するよう依頼した場合、開発チームと vpnusers.com 管理チームはこの提案を受け入れてくれるでしょうか?

Androidは完全にオープンソースのモバイルオペレーティングシステムプラットフォームです。Android上で開発されたアプリは、単一の.apkファイルを介して、あらゆるユーザーに簡単にオンラインで配布し、インストールして使用することができます。さらに、Androidはほとんどのモバイルオペレーティングシステムのハードウェアおよびソフトウェアと完全に互換性があります。そのため、この記事をvpnusers.comに投稿しました。

[adong]

大佬给力

[cedar]

私はこのフォーラムの管理者ですが、SoftEther VPN の開発者ではありません。
Android や iOS で動作する VPN クライアントに興味がありますが、これらの OS は Ethernet レベルの VPN を実現する API を公開しておらず、どうやってそれを実現すればよいのか分かりません。

[oscar]

私はこのフォーラムの管理者ですが、SoftEther VPN の開発者ではありません。
Android や iOS で動作する VPN クライアントに興味がありますが、これらの OS は Ethernet レベルの VPN を実現する API を公開しておらず、どうやってそれを実現すればよいのか分かりません。

iOS App Storeには、SoftEtherVPN通信プロトコルを完全に実装したVPNアプリが既に存在します。ダウンロードとインストールのURLはhttps://apps.apple.com/jp/app/sstp-connect/id1543667909です。

このアプリは、Windows、Linux、macOS のようなレイヤ 2 ローカルブリッジ/仮想 VPN ローカルクライアントネットワークカード機能を備えていません。ただし、ユーザー空間に制限のあるモバイルデバイスでは、レイヤ 2 を使用できない場合（SoftEtherVPN サーバーがカーネルモード NAT と RAW IP モード NAT の使用を禁止され、ユーザーモード NAT のみを使用するように強制されている場合など）でも、レイヤ 3 ルーティングのみを使用してレイヤ 3 ベースの SoftEtherVPN 通信プロトコルを実装できます。

一方、SoftEtherVPN のネットワーク OSI 層を厳密に区別した場合（ソフトウェア以外の物理 NIC カードレベルで）、SoftEtherVPN はネットワーク層よりも下位の OSI 層である OSI 層 3 では動作しません。これは、インターネットへ転送されるすべてのデータパケットは、ルーティングのために IP アドレス情報を持たなければならないためです。また、「ルーティング」という用語はネットワーク OSI 層 3 にのみ存在します。OSI 層 2 はルーティングではなくスイッチングと呼ばれます。さらに、パブリックインターネットにアクセスするために、スイッチだけではネットワーク層 3 のデータ処理（MAC アドレスフレームの転送）を行うことができません。MAC アドレスのみを持ち、IP アドレスを拒否するだけでは、次ホップのインターネットノードでネットワーク操作を行うことはできません（OSI 層 3）。

この投稿では、SoftEther VPN の OSI オペレーティング レイヤー間の厳密な区別に関する詳細な技術的説明が提供されています: https://www.vpnusers.com/viewtopic.php?f=15&t=69879

そのため、iOS は SoftEtherVPN VPN プロトコル アプリを伝送するためのユーザー モード SecureNAT 通信カーネルの開発に成功しましたが、レイヤー 2 データの処理は禁止されていますが、ネットワーク伝送機能があれば十分です。この技術分析によると、Android でこのようなアプリを実装することは技術的に難しいことではないはずです？

[oscar]

OSI 層を説明する非常にシンプルな図で、わずか 1 ページですが、説明は驚くほど正確かつ明確です。

SWR.png

[cedar]

あなたは SecureNAT の機能を誤解していると思います。
SecureNAT は、仮想 HUB 内部の Ethernet レベルのインターフェイスに対して、透過プロキシ型のIPマスカレードに似たゲートウェイサービスを提供する機能です。
仮想 HUB 自体には IP パケットを直接取り扱う機能はありません。

[oscar]

あなたは SecureNAT の機能を誤解していると思います。
SecureNAT は、仮想 HUB 内部の Ethernet レベルのインターフェイスに対して、透過プロキシ型のIPマスカレードに似たゲートウェイサービスを提供する機能です。
仮想 HUB 自体には IP パケットを直接取り扱う機能はありません。

ネットワークエンジニアリングでは、OSI層の機能テストと実装を行う前に、まずネットワークエンジニアリング実験全体について理論的な議論を行い、その後、実現可能性分析を行います。これは、VPNは従来、ルーティングテーブルを変更し、ルートを0.0.0.0/0に直接ハイジャックする（ただし、SSTP Connect iOSアプリとVPN Client Windowsアプリではこれを明示的に拒否できます）のに対し、プロキシは通常TCP/UDPのみを転送するため、ネットワーク層のレイヤー3を直接ハイジャックする可能性は低いためです。したがって、TCP/IP OSIモデルに関する私の厳密な技術的議論は、まさにこの目的に向けられたものです。

プロキシサーバーは、ネットワーク帯域幅と伝送性能の点でSoftEtherVPNよりも実際には高速です。これは、プロキシプロトコルがハンドシェイクと明示的なVPNセッション確立通信プロセスを省略しているためです。ただし、プロキシの処理ロジックを書き換えることはできません。つまり、オペレーティングシステム内のルーティングテーブルを直接追加、変更、削除することはできません。つまり、特定のアプリケーショントラフィックのみを明示的にルーティングできるということです。プロキシサーバーは、ネットワークルーティング（IPアドレスとルーティング）を操作するツールではありません。

[cedar]

> VPNは従来、ルーティングテーブルを変更し、ルートを0.0.0.0/0に直接ハイジャックする

それは L3 VPN についての話です。
SoftEther VPN は L2 VPN なので、経路をハイジャックするような動作は行いません。
OS に対して新しいイーサネットのインターフェイスを追加するだけです。

> プロキシサーバーは、ネットワーク帯域幅と伝送性能の点でSoftEtherVPNよりも実際には高速です。

あなたが話しているのは HTTP プロキシのことだと思います。
SecureNAT のような透過型プロキシは、もっと低いTCPレイヤで動作します。

というか、これは何の話でしょう。
私が言っているのは、あなたが仮想 HUB の動作レイヤを誤解しているということです。

[oscar]

> VPNは従来、ルーティングテーブルを変更し、ルートを0.0.0.0/0に直接ハイジャックする

それは L3 VPN についての話です。
SoftEther VPN は L2 VPN なので、経路をハイジャックするような動作は行いません。
OS に対して新しいイーサネットのインターフェイスを追加するだけです。

> プロキシサーバーは、ネットワーク帯域幅と伝送性能の点でSoftEtherVPNよりも実際には高速です。

あなたが話しているのは HTTP プロキシのことだと思います。
SecureNAT のような透過型プロキシは、もっと低いTCPレイヤで動作します。

というか、これは何の話でしょう。
私が言っているのは、あなたが仮想 HUB の動作レイヤを誤解しているということです。

SoftEtherVPN が対象の VPN サーバーに接続する前に、「中継プロキシサーバー」オプションが表示されます。このオプションでは、直接 TCP/IP 接続、HTTP プロキシサーバー、SOCKS プロキシサーバーのいずれかを選択できます。設定タブでは、HTTP または SOCKS プロキシサーバーの IP アドレスとポート番号を明示的に指定できます。

しかし、一部のWindowsプロキシソフトウェアは、127.0.0.1:1080のようなローカルポートをリッスンして動作します。ポート1080は、別のWindowsクライアントソフトウェアが提供するソフトウェアTCPサービスです。つまり、一部のプロキシソフトウェアはポート1080をリッスンし、内部のTCP/IP通信メカニズムを透過的にポート1080に直接送信します。

もちろん、SoftEtherVPN クライアントが VPN サーバーに接続する際に、HTTP/SOCKS プロキシサーバーの IP アドレスとポート番号を 127.0.0.1:1080 と指定すると、VPN トラフィックはポート 1080 経由でこの特殊な Windows プロキシソフトウェアの TCP ポートを直接通過できます。問題は、このリレーモードによってネットワーク RTT が意図せず増加してしまうことです。HTTP/SOCKS プロキシ経由の VPN 機能は、SoftEtherVPN におけるネットワーク伝送の RTT 値を間接的に増加させてしまうのではないでしょうか？

https://www.softether.org/4-docs/1-manu ... VPN_Server

4.4.2 Direct TCP/IP Connection
Use a direct TCP/IP connection in an environment where only direct IP routing can be used to establish an IP connection between the VPN client computer and VPN server computer. Select this setting when, for example, the VPN client computer and VPN server computer are both directly connected to a global IP address usable on the Internet or when a normal NAT or transparent firewall exists between the two computers.

4-4-2.png

Direct TCP/IP Connection.

4.4.3 Connection Via HTTP Proxy Server
When a direct TCP/IP connection cannot be used, you can connect to VPN Server via an HTTP proxy server.

4.4.4 Connection Via SOCKS Proxy Server
When a direct TCP/IP connection cannot be used, you can connect to VPN Server via a SOCKS proxy server if available.

4-4-5.png

Connection Via SOCKS Proxy Server.



To connect to VPN Server via a SOCKS proxy server, select [Connect Via SOCKS Proxy Server], and then click [Proxy Server Connection Setting] and enter the required information. For more information about the settings on the [Proxy Server Connection Setting] window, please contact the administrator of the SOCKS server.

At the time of writing this manual, SoftEther VPN Client supports SOCKS protocol version 4, but does not support version 5.

HTTP SOCKS プロキシサーバーを設定する本当の目的は何でしょうか? HTTP SOCKS プロキシサーバーで既に高品質な TCP/IP 通信が実現できるのであれば、SoftEtherVPN の SSL-VPN の基盤となる物理トランスポートプロトコルとしてこれを使用すると、追加の IP パケットヘッダーによってネットワーク転送のオーバーヘッドが増加するのではないでしょうか?

[cedar]

はい。そのとおりです。
RTTが重要な場合には、HTTP プロキシ経由の接続は適していません。

[oscar]

はい。そのとおりです。
RTTが重要な場合には、HTTP プロキシ経由の接続は適していません。

しかし、科学的証拠によってその実現可能性が実証されているにもかかわらず、一部の極めて厳格なファイアウォール（イランや中国のGFWなど）では、ハンドシェイクフェーズにおけるSoftEtherVPNのTCP接続特性が、高度に専門化されたDPIファイアウォールによって事前に識別される可能性があります。これらのファイアウォールは、接続が確立される前に対象のVPNサーバーをリストに追加することさえ可能であり、VPNクライアントが対象のVPNサーバーと通信するのを阻止します（最悪の場合、OSIレイヤー3ブロッキングにより、pingパケットさえも応答を受信できなくなります）。

SoftEtherVPN は、カスタム暗号化パラメータを実装したり、v2ray/shadowsocks のように SE-VPN プロトコル（SSL-VPN の TCP/443）のポート番号の TCP ヘッダーバイトをランダム化したりすることで、ディープ DPI パケット検出を導入している国を回避できる可能性を設計時に検討しましたか？ 実証テストによると、SoftEtherVPN の SSL-VPN (SE-VPN) プロトコルは、ソフトウェアの多重 TCP 転送によって TTL レイテンシが増加するため、常に SOCKS プロキシサーバー経由の接続に成功します。v2ray/shadowsocks のようなデータ署名難読化モジュールを SE-VPN モジュールに直接追加することは可能でしょうか？

難読化ツールは、必ずしも v2ray/shadowsocks プロジェクトの命名規則を完全に採用する必要はありません。プラグインを通じて機能をリアルタイムに追加、変更、削除できる設計で十分です。SoftEtherVPN プロジェクトチームは、DPI 検閲が厳しい国や地域では、ファイアウォールの動作が単なるパッシブ IP アドレスブロッキングにとどまらないことを考慮しているでしょうか？接続が確立される前に、対象の VPN サーバーのプロトコル特性をプロアクティブに調査し、それらの特性を学習して DPI データベースにフィンガープリントを追加することで、その通信プロトコルの特定の機能に基づいて即座にブロックできるようにする可能性もあるのではないでしょうか？

現在、イラン/中国のグレートファイアウォールはこの新しいDPI技術（パッシブプロトコルトラフィック検出とアクティブプロトコル機能検出の同時実行）を採用しています。SoftEtherVPN開発チームは、最新のUSENIX技術論文に記載されている2024～2025年の検閲デバイスの動作に関する最新の動向を把握していますか？

SoftEtherVPN がプラグイン可能な機能窃取モジュールを開発しない限り、プロトコルシグネチャに基づき、たとえ初期通信トラフィックが最小限であっても、新しい DPI（Deep Packet Inspection）によってすぐにブロックされてしまうでしょう。これは単なる憶測ではありません。USENIX の 2024-2025 年学術研究論文は、これを裏付ける明確な科学的証拠を提供しています。SoftEtherVPN は、DPI 組織が最近この作業に着手したことを認識していますか？2025-2026 年に対応モジュールを更新する予定はありますか？

[hiura]

遮断に関しては、下記の通り禁止されています。

国家の検閲用ファイアウォール管理者への警告

https://www.vpngate.net/ja/#:~:text=%E5 ... 3%E3%80%82

[hiura]

＞あっても、新しい DPI（Deep Packet Inspection）によってすぐにブロックされてしまうでしょう。これは単なる憶測ではありません。USENIX の

質問ですが、新しい DPIとは具体的にHTTPSのプロトコルのどの部分をINSPECTIONするのですか？

TLSハンドシェイク部分ですか？そうであれば、
TLSハンドシェイク時のパケットの送信元、送信先IPアドレスを見ても、
そのIPのパケットがWEB BROUSING 用かVPN用のものなのかは判断できないと思いますが？
区別がつかないから、VPN用に利用できるのであって。

[oscar]

＞あっても、新しい DPI（Deep Packet Inspection）によってすぐにブロックされてしまうでしょう。これは単なる憶測ではありません。USENIX の

質問ですが、新しい DPIとは具体的にHTTPSのプロトコルのどの部分をINSPECTIONするのですか？

TLSハンドシェイク部分ですか？そうであれば、
TLSハンドシェイク時のパケットの送信元、送信先IPアドレスを見ても、
そのIPのパケットがWEB BROUSING 用かVPN用のものなのかは判断できないと思いますが？
区別がつかないから、VPN用に利用できるのであって。

率直に言えば、検閲機関のDPI技術はSoftEtherVPNのHTTPSスプーフィングに対抗するのが技術的に困難ですが、HTTPSプロトコルには正当なデータと不正なデータが混在していることを認識しています。そのため、軽率にTCP/IPネットワーク全体を遮断する勇気はありません。これはゲーム理論上の状況であり、A. 不正なHTTPSデータフローの一部を許可するか、B. TCP/IPネットワーク全体を遮断するかのどちらかです。

VPN ユーザーは、検閲者の視点からこの問題を考えると、ジレンマに陥ります。明らかに HTTPS トラフィックではないが、他の通信プロトコルを伝送するために確立された HTTPS トラフィックであるように見える一部の TCP 接続を許可するか、DPI デバイスを通過するすべての接続を完全にブロックするかのいずれかです。ただし、経済的/政治的考慮、特に政治的考慮により、ほとんどの検閲機関は軽率な行動をとることはありません。

一方、AndroidプラットフォームにはSE-VPNプロトコルを使用するVPNクライアントは現時点では存在しません。Open SSTP Connectは、通信にSE-VPNプロトコルではなくMicrosoft SSTPプロトコルを使用します。したがって、厳密に言えば、AndroidプラットフォームでネイティブにSE-VPNプロトコルを使用できるVPNクライアントは存在しません。ただし、Apple社のiOS iTunes Storeにはそのようなアプリが存在します。Apple iTunes -> https://apps.apple.com/jp/app/sstp-connect/id1543667909

[hiura]

＞率直に言えば、検閲機関のDPI技術はSoftEtherVPNのHTTPSスプーフィングに対抗するのが技術的に困難ですが、HTTPSプロトコルには正当なデータと不正なデータが混在していることを認識しています。そのため、軽率にTCP/IPネットワーク全体を遮断する勇気はありません。これはゲーム理論

不正なデータとは具体的にどんなデータですか？

また、未回答のため再質問します。新しい DPIとは具体的にHTTPSのプロトコルのどの部分をINSPECTIONするのですか？　

[oscar]

->不正なデータとは具体的にどんなデータですか？

A：Wiresharkの解析からわかるように、すべてのTCP/443ポート通信は、TLSハンドシェイクと証明書検証を用いて暗号化された接続を確立しているようです。しかし、VPN通信に使用されるHTTPSは、通常の（実際のHTTPSウェブページ）通信とは微妙な違い（ウェブサイトから返される証明書名、IPパケットヘッダー、ペイロード長、SoftEtherVPNプロトコルと通常のHTTPSウェブサイト間の微妙なフィンガープリントの違いなど）が生じるため。

-> 新しい DPIとは具体的にHTTPSのプロトコルのどの部分をINSPECTIONするのですか？　

HTTP メッセージは、リクエスト ライン、リクエスト ヘッダー、空白行、リクエスト ボディの 4 つの部分に大まかに分けられます。

しかし、ユーザーとオペレータ間のNATブラックボックスには、HTTPSを標的とした中間者（MITM）証明書ハイジャックモジュールが含まれている可能性があります。SoftEtherVPNの証明書検証設定が無効（OFF）になっている場合、ユーザーのクライアントは証明書ハイジャック攻撃に対して脆弱になる可能性があります。一方、GFWデバイスはTLSをスニッフィングすることで、ユーザーが通信しようとしているサーバーの特性を把握することができます。GFWはこの証明書を傍受し、SoftEtherVPNクライアントになりすますことで、クライアントとサーバー間の通信内容を任意に再生することが可能になります。

ある国のグレートファイアウォール（GFW）は、サーバーに偽装し、MITM（Man-In-The-Middle-Attack）方式でユーザーの通信トラフィックをすべて傍受することができます（これはGFWの物理的な設備上の優位性から推測されます。ユーザーのTCP/IP物理伝送チャネルはGFWを必ず通過するため、つまり、このDPIデバイスはユーザーとサーバー間の不可避のパスとなります）。さらに、GFWはTLSコンテンツを復号化し、本物のHTTPSウェブサイト（DPIをバイパスするように設計されたHTTPSパケットではない）の署名データベースと比較することができます。これにより、将来的にはSE-VPNプロトコルをより正確かつ効果的にブロックおよび遮断できるようになります。

これらの実験理論は、GitHub上のShadowsocksプロジェクトとV2RayプロジェクトのリポジトリやIssueに掲載されている、これらの主張を裏付ける多数の.pcapファイルやテスト実験設計文書に含まれています。私のHTTPS通信は実際にはDPI+TCPによってブロックされませんでしたが、これらの理論と実験は根拠のないものではないため、SoftEtherVPNプロトコルを標的としたTCP/IP+QoS通信ポートのプロアクティブな識別とブロック／パッシブスキャンを理論的に回避するための具体的な科学的手法を検討する必要があります。

既存の科学研究論文や各種試験報告に基づくと、GFWはポート443（HTTPS/TLS/TCP）のトラフィックをすべて無視するわけではありません。もしGFWがポート443のトラフィックを無条件に信頼すると、世界各国におけるDPI（Distributed Traffic Interference）導入プロジェクトは完全に破壊され、大きな失敗に終わるか、全く効果を発揮しなくなるでしょう。したがって、vpn.packetix.net:443は現在DPIによって具体的にブロックされていませんが、将来的にDPIによってブロックされる可能性を検討する必要があります。

[oscar]

＞率直に言えば、検閲機関のDPI技術はSoftEtherVPNのHTTPSスプーフィングに対抗するのが技術的に困難ですが、HTTPSプロトコルには正当なデータと不正なデータが混在していることを認識しています。そのため、軽率にTCP/IPネットワーク全体を遮断する勇気はありません。これはゲーム理論

不正なデータとは具体的にどんなデータですか？

また、未回答のため再質問します。新しい DPIとは具体的にHTTPSのプロトコルのどの部分をINSPECTIONするのですか？　

https://ensa.fi/active-probing/#overview

SoftEtherVPN プロジェクト チームは、2025 年までに DPI に対抗する必要性を認識する必要があるようです。複数の関係者が DPI の存在を確認しているのに、なぜ真剣に受け止めないのでしょうか。

[hiura]

将来、SOFTETHER VPNがFIRE WALLでブロックされる可能性があるということですね。

SOFTETHER VPNの作者は
登 大遊 (Daiyuu Nobori, Ph.D.)さんのようです。

https://ja.softether.org/9-about#:~:tex ... 9%E3%80%82

こちらに連絡されてはどうでしょうか？

[oscar]

将来、SOFTETHER VPNがFIRE WALLでブロックされる可能性があるということですね。

SOFTETHER VPNの作者は
登 大遊 (Daiyuu Nobori, Ph.D.)さんのようです。

https://ja.softether.org/9-about#:~:tex ... 9%E3%80%82

こちらに連絡されてはどうでしょうか？

様々なソーシャルネットワーキングサイト（Twitterなど）を通じて彼に連絡を取ろうとしましたが、残念ながら彼は忙しすぎるようで、私のプライベートメッセージを完全に無視してしまいました。しかし、もしSoftEtherVPNプロジェクトチームがこのプラグイン（DNS/ICMP/UDP経由のVPNを強制的に使用するプラグイン）の開発の必要性に気づけば、DPIデバイスがSE-VPNプロトコルを日々積極的にプローブしている現状ほど状況は悪化しないかもしれません。

しかし、これは大きな問題ではありません。SoftEtherVPN がローカルネットワークが常にすべての TCP 通信をブロックしていると認識し、UDP/ICMP/DNS 経由の VPN モードを強制的に使用するようにする方法が見つかれば、このコンポーネントの機能が不足している問題は解決するでしょう。

[hiura]

＞UDP/ICMP/DNS 経由の VPN モードを強制的に使用するようにする方法が見つかれば

についてです。

SoftEther VPN Developer Editionに関しては、
PULL REQUEST（ユーザ自身でソースコード変更してマージしてもらう）することができます。
https://ja.softether.org/5-download/src ... tEtherVPN/

[oscar]

＞UDP/ICMP/DNS 経由の VPN モードを強制的に使用するようにする方法が見つかれば

についてです。

SoftEther VPN Developer Editionに関しては、
PULL REQUEST（ユーザ自身でソースコード変更してマージしてもらう）することができます。
https://ja.softether.org/5-download/src ... tEtherVPN/

すべてのTCPトラフィックをブロックするだけでも、netfilterだけで十分です。SoftEtherVPNのコードを意図的に変更する必要はありません。

あらゆるエンジニアリングプロジェクトでは、前提に対して強い懐疑心を持つことが求められるため、ローカルデバイスのネットワーク環境を具体的に変更するだけで十分です。

一方、科学的な実証的手法によって、ユーザーのTCP/IP伝送装置が常にDPI検閲装置の背後にある限り、ユーザーが高度な通信プロトコル変更プラグインを使用しても、常に受動的な状態（つまり、DPI装置の動作がユーザーの特定の環境設定によって変更されない状態）にあることが証明された場合、ユーザーは特別に構築されたプラグインを使用することで、これが実際にDPIによって実装されたトラフィックブロックであることを証明できます。

この理論的な検証のプロセスは、SoftEtherVPN の VPN over ICMP/DNS モジュールがどのように動作するかを技術的な観点から説明しようとするユーザーの試み、つまり科学的な経験的手法に相当します。

[oscar]

＞率直に言えば、検閲機関のDPI技術はSoftEtherVPNのHTTPSスプーフィングに対抗するのが技術的に困難ですが、HTTPSプロトコルには正当なデータと不正なデータが混在していることを認識しています。そのため、軽率にTCP/IPネットワーク全体を遮断する勇気はありません。これはゲーム理論

不正なデータとは具体的にどんなデータですか？

また、未回答のため再質問します。新しい DPIとは具体的にHTTPSのプロトコルのどの部分をINSPECTIONするのですか？　

DPIファイアウォールデバイスの管理者であれば、HTTPSプロトコルの特定のPOSTターゲットパスとコンテンツ、そしてSNIが指し示すホスト名を確認すれば、これらの特徴を利用してサーバーのIPアドレスやTCP接続をブロック/遮断することができます。機能分析の観点から見ると、SoftEtherVPNのプロトコルには様々な明らかな特徴が見られます。

これが通信ログです。

SSL 暗号化を選択した場合でも、データ ブロック サイズを調べることで、DPI (乱数エントロピーのサイズに基づく統計分析) を使用して、多くのハンドシェイク/応答パケットの具体的な内容をさらに分析できます。

[oscar]

これはApple iOSモバイルデバイス用のSoftEtherVPNクライアントアプリです。Android版の開発は原則的には難しくありませんが、現時点ではGoogle Playストアで完全に機能するアプリを見つけることができません。

iTunes Store の URL は次のとおりです: https://apps.apple.com/jp/app/sstp-connect/id1543667909