Android の IKEv2 が非標準の UDP ポートで失敗する理由

ゲートウェイが UDP 4443 で IKEv2 に応答するのには理由があり、プロファイルには Server という名前のフィールドがあり、ホスト名とポートを入力しても、端末はサーバーに到達できない、またはアドレスを解決できないと報告します。何もブロックされていません。Android の標準フォームはホストを想定しており、Windows でも同じです。カスタムポートはサーバー設定である前にクライアントの機能であり、それを表現できるのは一部のクライアントだけです。三つの部分を順に確認してください: クライアントが何を言えるか、サーバーが何を待ち受けているか、両端が同じ方法でパケットをフレーミングしているかです。

端末が実際に送ったもの

名前用のフィールドに入力された host:port という文字列は、名前として解決されます。リゾルバーは vpn.example.net:4443 に対して何も返さず、表示されるエラーはポートのタイムアウトではなく、名前解決の失敗または到達不能です。短い名前や別のネットワークで再試行してもフォームが解析できない文字列は決して直らないため、この違いは重要です。

Android の標準 IKEv2 プロファイルは、Windows の組み込み VPN クライアントと同様に、標準の IKE ポートに固定されています。どちらもポートのフィールドを表示せず、プロファイルを編集しても追加できません。事業者のリスナーが本当に 4443 にあるなら、組み込みクライアントは設定ミスではなく、間違った道具です。

ポートを公開するクライアントを使う

strongSwan の Android クライアントは、プロファイルの詳細設定で構成可能なサーバーポートを文書化しており、この設計で機能するほとんどすべての手順に登場するのはそのためです。そのサポートはそのクライアント固有のもので、別の IKEv2 アプリや同じアプリのベンダーフォークは、基盤の strongSwan デーモンが対応していても同じフィールドを公開しないことがあります。

事業者には一式をまとめて確認してください: ゲートウェイ名、UDP ポート、認証方式、そしてクライアントが期待すべきサーバー識別子です。カスタムポートは、証明書の検証を切ったりプロトコルを変えたりする理由にはなりません。インストール済みのクライアントがポートを期待する場所に入力し、そのクライアントにそのようなフィールドがなければ、答えは推測の回避策ではなく別の承認済みクライアントです。

サーバーには二つのポートがあり、両方が一致しなければならない

IKE は UDP 500 で始まり、NAT トラバーサルは通常 IKE とカプセル化された ESP を UDP 4500 に移します。strongSwan では別々の設定なので、単一のカスタムポートに移したサーバーは両方を同じ値に変える必要があります:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

一つのポートで両方の役割を担う場合、デーモンは同じソケット上で IKE と ESP-in-UDP を区別する必要があり、それは IKE メッセージの前に付く四バイトの非 ESP マーカーで行います。そのためクライアントはカスタムポートで交渉してから 4500 で黙って続行することはできず、「ポートを変えるだけ」という表現はフレーミングの要件を隠しています。

転送はリスナーではない

4443 を通常の IKE リスナーに転送することは、ほぼ成功したように見える失敗の形です。最初の交換が届き、サーバーが応答し、その後に接続が止まるか鍵を何もないまま再生成しますが、これは応答が別のポートから出るため、後続のカプセル化トラフィックが両端の作った状態と決して一致しないからです。リスナーを動かさずに宛先ポートを書き換えるルールは、まさにこの半開きの結果を生みます。

経路は UDP も端から端まで許可しなければなりません。TCP 443 がホテルや携帯網を通ることは、同じ番号であっても UDP ポート上の IKEv2 については何も語りません。TCP 443 しか許可されていない場所では、カスタム UDP ポートは IKEv2 を HTTPS には変えず、正しい答えは別のポート実験ではなく別のアクセス経路かもしれません。

テストでは三つの段階を分ける

クライアントが一度試す間にサーバーでキャプチャします。決して届かない要求はエンドポイントかファイアウォールの問題であり、応答なしで届く要求はリスナーかポリシーの問題であり、応答の後に沈黙が続くのはフレーミングか識別子の問題です。

tcpdump -ni eth0 -vv udp port 4443

次に、クライアントの回転インジケーターではなくメッセージを読みます。提案エラーはアルゴリズムが一致しないことを意味し、認証の失敗は識別子か証明書が一致しないことを意味し、応答のない再送が繰り返されるのはそのポートで何も応答していないことを意味します。一度に一段階ずつ試して試行の間に一つのフィールドだけを変え、NAT トラバーサルに関する strongSwan の文書が、キャプチャの示しているマーカーとポートの挙動を説明しています。