分割トンネルが除外するのはランチャーで、ゲームではない
ランチャーは試合のために別の実行ファイルを起動し、そのプロセスは独自のソケットを持ちます。実際のプロセスを見つけ、正しい識別子を合わせてからテストしてください。
ランチャーを除外リストに追加すると、ダウンロードは遅い状態から速い状態へ跳ね上がり、試合は依然として遠くのサーバーに着地します。壊れているものは何もありません。ランチャーとゲームは別々のソケット群を持つ二つのプロセスであり、片方を除外してももう片方については何も言えません。ダウンロードが速くなったのは、ダウンロードがランチャーの通信だったからであり、試合は別の誰かの接続で、あなたのルールが見たことのない実行ファイルが開いたものです。
一つのインストーラー、多くのプロセス
現代のゲームソフトウェアは小さな星座です。サインインさせるクライアント、コンテンツを取得するアップデーター、ゲームを起動するランチャー、そしてアンチチートやマッチメイキングのオーバーレイのために自ら第二のプロセスを生み出すゲームの実行ファイルがあります。それぞれが独自の接続を独自の宛先に保持できます。
除外ルールは通常、そのうちの一つを指名します。どれを指名するかは VPN クライアントが対応する識別子に完全に依存し、そこがユーザーがあまり確認しない部分です。実行ファイルのパスを照合するクライアントもあれば、パッケージやバンドルの識別子を照合するものもあり、無関係な二つのバイナリが共有できるプロセス名を照合するものもあります。ルールは表現できることさえ制約するから、プロセス一覧を読む前にルールを読んでください。
したがって症状は「分割トンネルが壊れている」ではありません。「ルールが、私が気にかける通信を運んでいるプロセスではないプロセスを対象にしている」という、はるかに狭く、はるかに修正しやすい説明になります。そう言い表せば、次の一歩は当て推量ではなくなります。
試合の接続を所有するプロセスを見つける
ゲームを起動して試合に入り、画面に何があるかではなく、誰がソケットを所有しているかを見ます。Windows では、プロセス一覧とプロセスごとのソケット照会が二つのコマンドで答えを出します:
Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcess二つ目のコマンドは名前ではなくプロセス ID を出力するので、二つの出力を ID で結合します。探している行は、リモートアドレスがゲームサービスに属する行であり、それを所有するプロセスがあなたのルールで指名すべき実行ファイルです。
Linux では同じ問いにソケット種別ごとに一つのコマンドが必要で、両方を確認する価値があり、試合の接続は UDP でも、ほかはすべて TCP かもしれないからです:
ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'ゲームがコンテナや互換レイヤーで動いている場合、見つけたプロセスはインストールしたバイナリではなくシムかもしれません。その場合に重要な識別子はクライアントが見るもので、シムのパスである可能性があり、元のファイルをどれだけ編集しても影響しません。
クライアントが対応する識別子を合わせる
何かを追加する前に、除外ルールについてクライアントのドキュメントを読んでください。よくある三つのモデルは動作が異なり、そのうち一つは罠です。
| Identifier | How it behaves | Failure mode |
|---|---|---|
| Executable path | Matches exactly the file at that path | Breaks when an update moves the binary |
| Process name | Matches any binary with that name | Too broad; catches unrelated software |
| Package or bundle id | Matches a signed application group | May include services you did not intend |
パスルールは最も正確で最も壊れやすいものです。実行ファイルを移動させるランチャーの更新は、ルールをもう実行されないファイルに向けたままにし、何も明らかに変わらないのに症状が戻ります。パッケージルールはそれに耐え、考えもしなかったヘルパープロセスを静かに覆うこともあり、それが便利か警戒すべきかはヘルパー次第です。
クライアントが何に対応していても、見つけられるすべての実行ファイルにエントリを追加しないでください。一つのセッションが動くまで試行錯誤で組み立てた一覧はレビューできず、無関係なソフトウェアの例外を静かに蓄積します。見つけたプロセスを指名し、それが何のためのものかを書き留めてください。
ダウンロードではなく試合でテストする
ランチャーのダウンロード速度は最悪のテストで、すでに除外されているプロセスを正確に動かすからです。失敗していたものを使い、ゲーム自身のパフォーマンス表示ではなく経路を確認してください:
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015最初のコマンドには試合サーバーが解決されたアドレスが必要で、それはゲームの接続ログかクライアントが教えてくれます。経路が物理インターフェースを示していれば、ルールは機能しています。二つ目はセッションがそもそも存在するかを示し、「除外されているがサーバーが落ちている」と「除外されていない」を分けます。
テスト中は地域とアクセスネットワークを固定してください。試行ごとに別のデータセンターに着地する試合は異なるアドレスを生み、ルールを検証する代わりに動く標的を追うことになります。同じアドレスでの二回の実行は、異なるアドレスでの十回より価値があります。
次の更新後に再確認する
パスに基づくルールには、パッチサイクルで測られる寿命があります。一か月後にゲームが除外を尊重しなくなったら、まず実行ファイルが移動したかを確認し、次にその隣に新しいヘルパープロセスが現れたかを確認します。
あるクライアントが文書化しているアプリケーション除外モデルは、これらのルールの説明方法として妥当な参考になりますが、詳細は製品によって異なります。自分のものを読み、使った識別子を記録し、日付を書き留めてください。その記録が、次にランチャーが更新を出すときに謎を五分の修正に変えます。
クライアントが必要な境界をどうしても表現できないなら、承認されたより広いポリシーのほうが、文書化されていない例外の山より優れています。広く理解されている方が、狭く間違っているより勝り、特に狭い版こそが全員に有効だと思われている場合には。