Android VPN を Cisco IOS に接続する: まず取り交わすべき契約

スマートフォンを Cisco ゲートウェイに接続したい。導入するクライアントはすでに誰かが指定している。しかしそれは手順の入口ではなく出口の話であり、一時間かけて認証情報を打ち直した末にトンネルが失敗するのはそのためだ。

先に必要なのは接続契約である。プロトコル、認証、アイデンティティ、信頼の材料、アドレスの割り当て、そしてルーティングを、ゲートウェイの運用者が文書で示す。

それが文書であれば、クライアントの選択は照合だけになる。省けば、どの失敗もパスワード違いに見える。

何かを導入する前に聞き取りを済ませる

ゲートウェイの管理者に一覧を送り、製品名ではなく答えを求めよ。九つの項目でリモートアクセスのプロファイルは網羅できる。

1. クライアントが接続するゲートウェイのホスト名またはアドレス、そして外部から到達できるかどうか。
2. プロトコルとバージョン。IKEv2 か、別世代の IPsec か、TLS ベースのサービスか。
3. ゲートウェイが求める相手のアイデンティティと、ゲートウェイ自身が提示するもの。
4. 信頼の材料。ゲートウェイの証明書に署名する CA はどれか、事前共有鍵を使うのか。
5. 利用者の認証。証明書か、EAP のユーザー名とパスワードか、事前共有鍵か。
6. クライアントが収まるアドレスプールと、そのマスクおよびゲートウェイ。
7. トンネル内で使う DNS サーバーと、クライアントがそれを受け入れる必要があるか。
8. 許可された宛先プレフィックスと、その外側の通信を遮断する必要があるか。
9. 対応するクライアントの版と端末の OS の版、さらに登録の要件があればその内容。

このうち二項目が、避けられた失敗の大半を生む。信頼の材料がなければゲートウェイを検証できず、正しいクライアントでも壊れて見える。許可されたプレフィックスがなければ、ルーティングの制限とサービスの不具合を区別できない。

ベンダー名はプロトコルではない

Cisco IOS と IOS XE はリモートアクセスの方式をいくつも提供しており、伝送形式を共有していない。FlexVPN 風のプロファイルを用いる IKEv2 は、旧来の IKEv1 構成と同じサービスではない。TLS ベースのクライアントサービスはさらに別製品で、同じ環境の別プラットフォームにあることも多い。

したがって、名前にルーターのベンダーを含むクライアントは何も証明しない。そのうち一つのサービスをよく実装していても、他は実装していないことがある。どのサービスが設定されているかを尋ね、そのうえでクライアントの文書がそのサービスを対応と記しているかを確認せよ。

Cisco 自身の IKEv2 の文書は、提案、ポリシー、プロファイル、キーリングを別々のオブジェクトとして扱う。この構造は、誰かに貼り付けられた設定を読むときに役立つ。ファイル全体を一塊として扱う代わりに、遠隔の端末にとって重要な設定をどのオブジェクトが持つかが分かる。

Android の標準スタックが担う範囲

Android は Ikev2VpnProfile を通じてプラットフォームの IKEv2/IPsec プロファイルを公開する。事前共有鍵、RSA 証明書、EAP のユーザー名とパスワードという認証方式が分かれている。Ikev2VpnProfile のリファレンスが、ビルダーが何を受け付けるかの拠り所であり、ゲートウェイのホスト名と、その検証に使うサーバールート CA も含まれる。

この API は能力の表明であって、互換性の約束ではない。その認証方式で IKEv2 ができる、というだけだ。特定の OEM の設定画面がすべての項目を出すとも、他製品から書き出したプロファイルが読み込めるとも述べていない。

つまり、ゲートウェイがプラットフォームの実装していないサービスを動かしている場合、標準スタックでは救えない。その場合は運用者が対応するベンダーのクライアントを、運用者の文書どおりに導入して設定する。端末が話さないプロトコルで代用してはならない。

契約に書かれた順に試験する

一度に一層だけ検証し、最初の失敗で止める。前の層が通らないうちは、後の試験に意味がない。

信頼。 クライアントがゲートウェイの証明書を拒否したら、他は問題ではない。渡された CA がゲートウェイの提示する証明書に署名していること、接続したホスト名がその中にあることを確かめる。検証は切らない。切ればアイデンティティの問題が盗聴の危険に変わる。

認証。 認証情報の拒否と提案の不一致は、別の誤りだが似た失敗になる。ゲートウェイのログが決め手であり、利用者について何かを言う前に、提案が受け入れ可能だったかを示す。

アドレスと DNS。 端末が文書化されたプールからアドレスを得たことを確かめ、次に内部名を一つ解決する。アドレスは取れてもリゾルバーがないトンネルは、接続済みに見えて何も動かないように振る舞う。

到達性。 許可された宛先を一つ、アドレスで試し、次に名前で試す。アドレスが通り名前が通らなければ DNS に戻る。どちらも通らなければ、クライアントに触る前に、試験中のプレフィックスを許可一覧と照合する。

故障の型と切り戻し

変更の前に、直前の動作するプロファイルを書き出して文書化しておく。CA の別名とアドレスプールも含める。そうすれば切り戻しは既知のプロファイルの復元であり、障害の最中に記憶から組み直すことではない。

動いたら、聞き取りの九つの答えをプロファイルの隣に記録する。次の端末、次の OS 更新、次のゲートウェイ変更が、当て推量の午後ではなく文書との照合になる。