iPhone の VPN パケットサイズをめぐる議論は、最後には必ず ppp0 という名前のインターフェースに対する同じ Mac コマンドを、たいてい数字付きで勧めます。それは通用しませんし、そのインターフェースが問題の接続のものでない限り、Mac 上でも正しい制御ではありません。電話側では数字はトンネルを実装する側が所有し、ネイティブプロファイルなら OS、アプリならパケットトンネルプロバイダ、文書化された属性がネゴシエートされるならゲートウェイになります。そのどれに当たるかは三つの問いで決まります。

問い一:どのクライアントが動いているか

ネイティブの IKEv2 プロファイル、内蔵の Cisco IPsec プロファイル、サードパーティの Cisco クライアントは、対応する属性の集合が異なる三つの別実装です。設定のプロファイル種別を見れば電話が実際に起動したのはどれかが分かり、アプリ一覧を見れば経路上にプロバイダがいるかどうかが分かります。残りの判断はそこから導かれるので、まずそこから始めてください。アプリ一覧にプロバイダが現れなければ、トンネルは OS の所有です。

ゲートウェイのベンダーから実装を推測しないでください。Cisco のヘッドエンドは、ベンダー名以外に共通点のないクライアントの接続も終端できます。古いリリース上の古いビルドのスクリーンショットは、その組み合わせが何に対応していたかを示すもので、手元の電話の挙動を示すものではありません。

問い二:その値は誰のものか

Apple はネットワーク拡張の設定オブジェクトを通じて、パケットトンネルの開発者に MTU プロパティを公開しています。これは自分のトンネルを構成するプロバイダ向けの API であり、利用者や管理者が他人のインストール済みクライアントで切り替えられるスイッチではありません。サードパーティのアプリは、公開するか、無視するか、値を固定するかを選べます。

ネイティブプロファイルではインターフェースのサイズを OS が選び、電話側にはそれを編集する手段がありません。Cisco のリモートアクセスゲートウェイには接続プロファイル用の文書化された属性があり、それが適用されるかはクライアント、リリース、ネゴシエートされたトランスポート次第です。文書化されていることと守られていることの間のこの隙間が、コピーした数字が狂う場所です。

OwnerWho can change itReachable from the phone
Packet-tunnel providerThe app vendor through its APIOnly if the app exposes a setting
Native IKEv2 or Cisco IPsec profileThe operating systemNo user control
Gateway group policy attributeThe gateway administratorIf the client honours it

問い三:症状はそもそもサイズ依存か

サイズの問題には、小さい要求は成功し、大きなアップロードや大きな応答は止まり、同じサービスが別のアクセス網では動くという特徴があります。フィルタリング、アプリのペイロード上限、停止したサーバーでも似た訴えは起きるので、失敗する操作を成功する操作の隣に記録してください。アプリが時刻とサイズを報告するなら、両方ともそれを添えて書きます。その対がなければ、後の変更はすべて推測です。

同じテストを Wi-Fi と携帯網で行ってください。網に追随する失敗は経路を指し、端末に追随する失敗はクライアントかプロファイルを指し、両者は別の所有者を必要とします。両方の実行で同じサービスと同じアカウントを使わなければ、比較は何も語りません。

Mac のレシピが何度も現れる理由

PPP ベースのデスクトップ VPN が長年使われたことで、インターフェースサイズの変更は正当なローカル回避策になり、その手順がモバイルの議論へコピーされました。電話側にはシェルも、そうしたインターフェース名も、再接続をまたぐ永続性もありません。2011 年にデスクトップの問題を解いたレシピは、それを正しくした条件よりもはるか遠くまで旅しました。議論が何を主張しても、モバイルクライアントはこれにシェルコマンドを受け付けません。

コピーした値は設定ではなく、経路についての仮説として扱ってください。小さいサイズで転送が通り、大きいサイズで確実に失敗するなら経路についての証拠はありますが、それに働きかける権限のある構成要素はなお探す必要があります。その探索はたいていゲートウェイのプロファイルかアプリのベンダーで終わり、電話で終わることはめったにありません。

トランスポートで答えが変わる

セッションが IPsec ではなく TLS 上で動いているなら、TCP フローに対して広告するセグメントサイズを書き換えるため、ゲートウェイでの TCP セグメンテーション調整が助けになることがあります。UDP の通信には何の効果もなく、そこには人々が思うより多くの現代のウェブが含まれます。変更を提案する前にネゴシエートされたトランスポートを確認し、どのトランスポートに影響が出ると見込むかをチケットに書いてください。

経路 MTU 探索は、端点が推測ではなく実際の上限を学ぶために存在します。フィードバックを遮断して小さいサイズを固定するのは、動く大きな転送を、接続ごとの恒久的で見えないコストと引き換えることです。

ゲートウェイチームに何を聞くか

属性の正確な名前とその範囲、配備済みクライアントがそれを守るか、セッションがどのトランスポートでネゴシエートしたか、という三つを尋ねてください。一つのグループポリシーに適用した変更は検証できますが、全体編集はできず、問題を報告していない利用者にリスクを移します。属性名はリリース間で変わるので、文書の参照も求めてください。

次に一つだけ変えて、速度テストのダウンロードではなく元の失敗した操作を再テストしてください。変更前と変更後の記録をクライアントのバージョンとアクセス網とともに残せば、次の報告は蒸し返すのではなく比較できます。

元のサイズでも操作が失敗するなら、サイズが原因ではなかったのです。次に担当する人が同じ仮説を開き直さないよう、その結論も記録してください。

関連記事