UDP/ICMP 経由の VPN は技術的に DPI デバイスの TCP ブロックを回避できますか?

[oscar]

VPNGATE上のIPアドレス範囲のうち、Mainland Chinaのグレートファイアウォールによってブロックされていると特定されているもの（つまり、DPIデバイスに出入りするすべてのTCPパケットがICMPを除き無条件にドロップされるもの）（例えば219.100.*.*）については、VPN over UDP/ICMP/DNSモードを使用する必要があります。

しかし、VPN over UDP/ICMP/DNSモードを有効化するにはどうすればよいでしょうか？

私の知る限り、UDP/ICMP/DNS 経由の VPN モードは、TCP が利用できない状況で SoftEtherVPN クライアントが UDP 経由の VPN 接続を確立することを受動的に許可することしかできません。

しかし、実際の実験結果によると、219.100.*.* は、TCP を使用する特定の Mainland China GFW (Great Firewall) によって恒久的にブロックされているようです。

Examples for some ip addresses TCP-based blocking in Mainland GFW firewall for IP Range 219.100.0.0/16
219.100.37.208
219.100.37.112
219.100.37.11
219.100.37.206

この場合、クライアントはこのブロックを回避するために、間違いなく UDP/ICMP/DNS 経由の VPN モードを積極的に使用する必要があります。TCP モードを使い続けることは、問題が罠に陥るのを待つようなものです。

問題は、現在 SoftEtherVPN クライアントが手動でオプションを設定することで UDP/ICMP/DNS 経由の VPN モードを明示的に使用できないということです。

VPNGateは素晴らしいプロジェクトですが、SoftEtherVPNはすでにUDP/ICMP/DNS経由のVPN機能を備えているため、このような極端な状況では、常にUDP/ICMP/DNS経由のVPN機能を使用する必要があります。従来の標準TCPモードを使い続けることはもはや役に立ちません！

したがって、多くの科学的実験を経て、私はSoftEtherVPNプロジェクトチームに対し、VPNクライアントに「ローカルDPIデバイス/国内ISPルーターがTCP通信をブロックしています。VPN通信を確立するには、UDP/ICMP/DNSモード経由のVPNを強制的に使用してみてください」というオプションを追加することを強く提案します。さらに、この機能をカスケード接続にも追加してください。現在、これは特定の中国製GFWに対するTCPブロックを突破する唯一の強力な手段です。（カスケード接続へのこのオプションの追加は、2025年に予定されているSoftEtherVPNの新アーキテクチャアップグレードの一部となる予定です。）

SoftEtherVPN プロジェクトチーム、助けてください!

[oscar]

https://github.com/GFW-knocker/gfw_resist_tls_proxy

既に多くのプラグインが存在し、SoftEtherVPNプロジェクトチームは開発者版を使ってそれらを直接ビルドすることさえ可能です。しかし、私の観察では、SoftEtherVPNは6年以上もの間、ソフトウェアアーキテクチャに真に画期的な改善を加えていないようですか？

[oscar]

この.VPNファイルをダウンロードし、接続して*.cnドメインにアクセスしてください。多くのページが完全に表示されないか、完全に空白になっていることがわかります。これはTCPブロックの決定的な証拠です。

# VPN Client Connect config

declare root
{
bool AddDefaultCA false
bool CheckServerCert false
uint64 CreateDateTime 0
uint64 LastConnectDateTime 0
bool RetryOnServerCert false
bool StartupAccount false
uint64 UpdateDateTime 0

declare ClientAuth
{
uint AuthType 0
string Username vpn
}
declare ClientOption
{
string AccountName GFWTCPBannedVPNGATEPUBLIC
uint AdditionalConnectionInterval 1
string BindLocalIP ::
uint BindLocalPort 0
uint ConnectionDisconnectSpan 0
string CustomHttpHeader $
string DeviceName VPN
bool DisableQoS true
bool HalfConnection false
bool HideNicInfoWindow false
bool HideStatusWindow false
string Hostname 219.100.37.114
string HubName VPNGATE
uint MaxConnection 32
bool NoRoutingTracking true
bool NoUdpAcceleration false
uint NumRetry 0
uint Port 443
uint PortUDP 0
string ProxyName $
uint ProxyPort 0
uint ProxyType 0
string ProxyUsername $
bool RequireBridgeRoutingMode false
bool RequireMonitorMode false
uint RetryInterval 15
bool UseCompress false
bool UseEncrypt true
}
}

[cedar]

そのゲートウェイは日本にあり、そこから中国本土への*VPN を通さない*HTTPアクセスは一部制限されます。
あなたは何を証明しようとしているのでしょうか？

[oscar]

そのゲートウェイは日本にあり、そこから中国本土への*VPN を通さない*HTTPアクセスは一部制限されます。
あなたは何を証明しようとしているのでしょうか？

VPN Gate の当初の目標は、インターネット上のすべてのエンドポイント（0.0.0.0/0 など）が世界中のあらゆるインターネットコンテンツに無制限にアクセスできるようにし、任意のポートがあらゆる方向のトラフィックを制限なく処理できるようにすることでした。しかし、GFW の DPI ブロッキングデバイスにより、たとえユーザーが VPN Gate 経由で日本の仮想ハブに接続できたとしても、持続的な TCP ブロッキングにより、この仮想ハブから中国本土への一部の TCP 接続が DPI デバイス（GFW 内）によってブロックされてしまいます。つまり、中国本土のユーザーはこの仮想HUBに直接接続できないのです。

VPN Gate は当初、長期無料仮想HUBを通じてすべてのユーザーがローカル DPI（ディープ・パケット・インスペクション）ブロッキングデバイスを継続的に回避できるように設計されていましたが、現在では DPI ブロッキングデバイスがアップグレードされ、中国国内のパブリック VPN 仮想HUBの IP アドレスが具体的にブロックされるようになりました。

これにより、これらの仮想HUBに接続しているすべてのネットワークユーザーが、DPI 検閲対象国のファイアウォールに匿名でアクセスすることが困難になります（仮想HUBがこれらの DPI ファイアウォールによってブロックされていない場合、このような逆接続は制限されません）。

長年にわたり、VPN Gate ネットワークセグメント 219.100.*.* を中継するパブリック VPN 仮想HUBは IPv4 アドレスを変更していないようで、どの国の DPI ファイアウォールでも国内の通信をブロックすることが非常に容易でした。

しかし、IPv6 の普及が進むにつれ、VPN Gate プロジェクトチームは、現在非常に厳格な IPv4 ネットワーク DPI 検閲を回避するために、IPv6 パブリック VPN リレーサーバーを追加することを検討したことがありますか？ 現在、DPI ファイアウォールは IPv6 データパケットのフィルタリング機能が非常に限られており、たとえブロックされたとしても簡単にバイパスできます。

[cedar]

中国本土のサーバーにアクセスしたい場合は、日本の VPN サーバーの代わりに中国本土の VPN サーバーを利用すればよいだけです。

[oscar]

中国本土のサーバーにアクセスしたい場合は、日本の VPN サーバーの代わりに中国本土の VPN サーバーを利用すればよいだけです。

実際、これはストリーミングメディアやニュースサイトへのアクセスではなく、物理的なTCP/IP層に関するものです。原則として、vpngate.net上のサーバーは、0.0.0.0/0方向であれば、任意の送信元IPアドレスから任意の宛先IPアドレスへ自由にアクセスできます。

私の投稿の要点は、このDPIデバイスのブロッキング戦略です。物理的に中国本土（つまり送信元IP）を発信元とするクライアントから宛先VPNサーバーへのデータストリームは許可しますが、VPNサーバーのダウンリンクトラフィック（例えば、219.100.*.*のようなIPアドレスからクライアントに送信されるデータ）は、このDPIデバイスによって完全にブロックされます。

これは、219.100.*.* を使用すると中国本土のストリーミング/ニュース Web サイトにアクセスできなくなるという意味ではなく、この DPI デバイスが物理的な TCP/IP の観点から VPN セッションの基盤となる物理的なトランスポート プロトコル チャネルをブロックするという意味です。

基盤となる物理的な TCP/IP トランスポート プロトコルがBLOCKされている場合、VPN Sessionを確立できないので、ローカル ニュース Web サイトやストリーミング ビデオをどのように閲覧できるでしょうか?（DPI デバイスによる TCP Blockは、上位の HTTP アプリケーション層データではなく、VPN Clientの基盤となる物理的な TCP/IP 送信を直接BLOCK/DROPします。）