SoftEther VPN User Forum

ルーティング/ブリッジ モードで動作する VPN サーバーは、DPI ファイアウォールのブロックを効果的に回避できることが科学的に証明されています。

https://github.com/fatedier/frp

https://cpolar.com

結論は信じられないほど単純です。HTTPS トラフィックは、このテクノロジーを導入した VPN サーバーをシームレスにバイパスできるため、SOCKS HTTP プロキシ サーバーは必要ありません。

ゲーム理論に関する Q & A セッション！

Q：DPI ファイアウォール/政府ファイアウォールを使用してこれらのサービス プロバイダーをブロックする方がはるかに簡単ではないでしょうか? vpngate.net は DPI 干渉下では正常に動作しません。

A：インターネットは基本的なTCP/IP通信機能を備えています。

インターネットを完全に遮断するには、ルート0.0.0.0/0へのすべてのTCP/IPトラフィックをブロックするだけで十分です。TCPブロッキング技術を備えた複雑なDPIファイアウォールを構築するために多額の費用をかける必要はありません。

Q：これらのサービスには制限を回避する機能があるため、VPN Gate ではなく DPI などのプロトコルをターゲットにすることで、ほとんどの人が TCP/IP DPI ブロックの牢獄から逃れるのを防ぐことができます！

A：その後、サービスをバージョン 1 からバージョン 2 にアップグレードしてリリースするだけです。

クライアントは、IP アドレスの変更など、技術的な調整をほとんど行う必要がありません。

もしかして、あなたは制約を回避しつつWebサーバーを公開したいのでしょうか？
それなら、わざわざ制限付きのVPN Gateノードを使うのではなく、VPS を借りて自前の VPN サーバーを設置することで解決します。

cedar wrote: ↑

Tue Nov 25, 2025 2:11 pm

もしかして、あなたは制約を回避しつつWebサーバーを公開したいのでしょうか？
それなら、わざわざ制限付きのVPN Gateノードを使うのではなく、VPS を借りて自前の VPN サーバーを設置することで解決します。

これを行った目的は、カスケード接続モードを用いてDPIファイアウォール監視を間接的に回避することでした。

しかし、カスケード接続モードを許可するには、VPNサーバーがルーター/ブリッジモードをブロックできません。

残念ながら、ほとんどのVPN Gate VPNサーバーはルーター/ブリッジモードを明示的に拒否します。

たとえ私が自主管理型VPS上でクライアント/簡易IP/TCPルータープログラムを使用していたとしても、これは依然としてVPSのローカルeth0()インターフェースのデフォルトの送信ルーティングテーブル（0.0.0.0/0）に依存します。

制御可能なネットワークデバイス上でカスタム L3 転送/IP テーブルデバイスを実行し、このデバイスを使用して VPN Gate サーバーの通信を中継したいと考えていることは明らかです。

しかし、なぜカスケード接続をクライアントとして実行できず、ルーター/ブリッジモードで実行する必要があるのでしょうか？

または、VPN 仮想 NIC の単一の IP テーブルのみを処理する別のユーザー空間プログラムを実行する必要がありますか?

これは私が管理するネットワークなので、レイテンシ、パケットロス、RTT について理解しています。

VPN Gate は学術的な実験プロジェクトであるため、ブリッジモードを使用して DPI を回避することは、DPI をターゲットとした「緊急構築、実証実験」とも言えます。

cedar wrote: ↑

Tue Nov 25, 2025 2:11 pm

もしかして、あなたは制約を回避しつつWebサーバーを公開したいのでしょうか？
それなら、わざわざ制限付きのVPN Gateノードを使うのではなく、VPS を借りて自前の VPN サーバーを設置することで解決します。

netsh interface portproxy add v4tov4 listenport=53 listenaddress=0.0.0.0 connectport=443 connectaddress=219.100.37.58 すでに目標は達成しましたが、さらに一歩進んで、VPS の IP アドレス自体を L3 サードパーティ ホスティング プロバイダーの DDNS の別のレイヤーで管理し、DPI と高度な DNS ポイズニングおよび URL をターゲットとする DPI ブロッキングをさらに回避したいと考えています。

良く分かりません。あなたのやりたいことは背後にある複数のホストのインターネットトラフィックを、代表した1台のVPNクライアントだけで実現することですか？
もしそうなら、Windows であれば「インターネット接続の共有(ICS)」、Linux であれば IP マスカレーディングを使うことで、ブリッジモードなしで実現可能です。

cedar wrote: ↑

Thu Nov 27, 2025 10:56 am

良く分かりません。あなたのやりたいことは背後にある複数のホストのインターネットトラフィックを、代表した1台のVPNクライアントだけで実現することですか？
もしそうなら、Windows であれば「インターネット接続の共有(ICS)」、Linux であれば IP マスカレーディングを使うことで、ブリッジモードなしで実現可能です。

実は、とても簡単です。

Example 1

条件 1: IP アドレス 219.100.37.58 のサーバーが特定の国の DPI ファイアウォールによって厳しくブロックされており、すべての TCP 接続を確立できなくなりました。

条件2：IPアドレス47.57.1​​08.98はDPIによって恒久的にホワイトリストに登録されたサーバー（完全除外サーバー）であるため、そのトラフィックはいかなる検閲によってもブロックされることはなく、またブロックされることもありません。

つまり、DPIファイアウォール内部の通信は常に許可されます。[このサーバーはDPIファイアウォールの外側にあると想定しています。一部の国では、これは海外の国際サーバーに相当します。]

条件3：サーバー47.57.1​​08.98は219.100.37.58と制限なく通信できます。47.57.1​​08.98はDPIの外側にあり、DPIの適用を完全に免除されていますが、47.57.1​​08.98は219.100.37.58とのOSIレイヤー3通信を積極的に中継しないため、47.57.1​​08.98ではレイヤー4トラフィックの転送が必要です。例えば、以下のようになります。

[!次の PowerShell / cmd コマンドがホスト 47.57.1​​08.98 で実行]
netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=219.100.37.58

理論的には、レイヤー 3 ネットワーク ルーティングを使用する方がより直接的な方法ですが、以前このフォーラムでルーティング/ブリッジ モードを制限しないように提案しましたが、VPN サーバー管理者 [のぼり だいゆう] は私の提案を受け入れませんでした。

PUBLIC VPN サーバーは、VPN セッションの基盤となるトランスポートプロトコルとして TCP/UDP の使用をサポートしており、上記のコマンドプログラムはトランスポート層 4 に基づいています。

ただし、純粋なネットワーク層ルーティングでは、SoftEtherVPN がブリッジ/ルーティングモードの実行を明示的に許可する必要があります。

これはサーバーホスト 47.57.1​​08.98 のルーティングテーブルを変更することで実現できますが、問題が発生します。デフォルトルート 0.0.0.0/0 が乗っ取られたり変更されたりすると、パブリック IP アドレスを使用して 47.57.1​​08.98 にアクセスするトラフィックは、その NIC に到達できなくなります (デフォルトルート 0.0.0.0/0 は失われます)。

サーバーホスト 47.57.1​​08.98 のルーティングテーブルを強制的に変更することはできますが、ホスト 219.100.37.58 のセキュリティポリシーにより、このルーティング動作ではすべてのパケットが破棄されます。


最後に、VPNGATE モードで動作している VPN ホスト上の仮想 HUB が、デフォルトでルーティング/ブリッジモードを常に拒否するのはなぜでしょうか？

たとえこのモードが許可されていたとしても、VPN サーバー管理者がセキュリティ上の懸念を抱いている場合、LAN セグメント 192.168.0.0/16 および 172.16.0.0/16 からのすべてのトラフィックをブロックする可能性があります。

VPNGATE 仮想 HUB でルーティング/ブリッジモードの実行を許可することにセキュリティ上の問題はないのでしょうか？