Apple VPNプロファイルのProxyフィールドが実際に何をするのか

Apple VPN構成のProxyフィールドを入力すると、トンネルをウェブポート経由に付け替えられるように感じます。そうはなりません。このフィールドは、対応アプリがそこへ送ると決めた通信のために、アプリケーション層の中継役を選ぶものです。一方、VPNクライアント自身のゲートウェイへの接続は、設定したプロトコル、リスナー、トランスポートが決めることで、これらは別の判断です。

二つの接続、二つの所有者

この種の構成には、クライアントからゲートウェイへの接続と、アプリから宛先への接続があります。Proxyセクションが語るのは二つ目の接続で、一つ目と同じプロファイルに置かれていても変わりません。

Appleのプロキシ設定のリファレンスにはHTTP、HTTPS、SOCKS、自動プロキシ構成が並びますが、これはアプリのプロキシ選択の説明です。IPsecやWireGuardのパケットがゲートウェイにどう届くかは、そこには書かれていません。

決着をつける簡単な確認があります。VPNクライアントがログに出すポートとプロトコルを確かめてください。その行がまだUDP 500やUDP 51820と出ているなら、プロキシのフィールドは何も変えていません。

このフィールドが正しい道具になる場合

プロキシがトンネルの手前に置かれる実際のケースはありますが、それはプロファイルのフィールドではなくクライアントの機能です。OpenVPNのマニュアルは、HTTP CONNECTプロキシ経由で運ぶTCP接続のために--http-proxyを記載しています。使うには対応するクライアントオプション、その経路で到達できるゲートウェイ、使用ポートへのCONNECTを許可するプロキシが必要です。

クライアントがそのオプションを備え、ネットワークがポートへのCONNECTを許すなら機能する可能性があります。クライアントが備えていないなら、システムプロキシを入力してもトンネルには何の影響もありません。

何も変わらない場合

Proxyフィールドが埋まっているからといって、IKEv2やIPsecのプロファイルがHTTPトンネルになるわけではありません。設定形式にプロキシの概念がないWireGuardも同じです。ゲートウェイのポートを変えてもプロトコルは変わりません。そして通常のHTTPSに応答するエンドポイントが自動的にVPNリスナーになるわけでもありません。

同じ罠は、古いiPadの解説からPPTP時代のプロファイルをコピーする人にもかかります。選択肢は画面に残っていますが、その背後のサービスはもうそのプロトコルを話しません。

どの層を直すかを決める

何かを変える前に、どの層が失敗したかを尋ねてください。クライアントがセッションを確立できないなら、問題はトランスポートで、プロキシのフィールドは無関係です。トンネルは上がっているのに一つのアプリがサーバーに届かないなら、アプリのプロキシを調べる価値があります。トンネルが上がっていて全アプリが失敗するなら、疑うべきはトンネル内のルーティングとDNSです。

最初のケースでは、どの承認済みの代替トランスポートやネットワークをサポートしているかを運用者に尋ねてください。TCP 443上のOpenVPNが存在するのは、一部のネットワークがそれしか許さないからで、サーバーがそれを待ち受けている必要は依然としてあります。

ブロックされたUDPポートを、その場しのぎの許可と受け取らないでください。ハンドシェイクを通すためにゲートウェイの証明書や身元の確認を切るのではなく、そのまま保ってください。

二つの層を一つずつ確認する

まずトンネルを確認します。クライアントの状態ページでセッションが確立し、バイト数がゼロでないことを見てください。次にプロキシ設定を直接読みます。有効な構成にはscutil --proxy、保存値にはnetworksetup -getwebproxy Wi-Fiを使います。そのうえで、システムプロキシに従うアプリと無視するアプリを一つずつ試してください。多くのネイティブアプリは無視します。

三つの結果、三つの異なる修正。

両方の層が成功を報告してもアプリが失敗するなら、スプリットトンネリング、DNS、アプリ自身のネットワーク設定を見てください。それは三つ目の層で、プロキシのフィールドでもありません。