Meraki が AnyConnect に対応できるかどうかで二つのサポートスレッドが対立しており、どちらも同じように自信たっぷりに間違っています。問題は MX が IKEv2 を話すかどうかではなく、機器上の AnyConnect が IPsec ではなく TLS のサービスであるという点です。答えを決めるのは二つの別々の確認であり、どちらもブランドの比較ではありません。順番に進めれば、意見ではなく互換性の記録が残ります。

まず機種とリリース

機能がその両方に限定されているため、まず正確な機器と、それが動かしているソフトウェアから始めます。Meraki は対応機種と最低ファームウェアを示す表を公開しており、引用に値するのはその表だけです。一覧にある機種が自動的にその機能を支えるリリースであるとは限らず、機能を支えるリリースが手元のものとは限りません。機種とインストール済みファームウェアを二つの事実として別々に記録します。そのうえで、その組み合わせについて表を読みます。

同じ系列の似た機種から推測してはいけません。一覧は機種ごとであり、違いは現実のものです。

AnyConnect は SSL サービスであり IPsec ではない

Meraki は MX 上の AnyConnect を TLS と DTLS によるアプリケーションベース VPN と説明し、別個の L2TP/IPsec クライアント VPN サービスの隣に記載しています。これは同じダッシュボードを偶然共有する二つの製品です。IKEv1 と IKEv2 を比べても、わかるのは IPsec サービスについてであり、手元の機器に TLS サービスがあるかどうかはわかりません。証拠が IKE の版の表なら、別の問いに答えていることになります。

クライアントを比べる前に、機器がどのサービスを公開しているかを特定します。動く L2TP/IPsec プロファイルは、同じ組織に届くという理由で AnyConnect プロファイルになるわけではなく、両者は別のクライアント設定を必要とします。

MX が実際に提供する機能

Cisco の ASA の機能一覧は MX の機能一覧ではなく、十二のことを支えるクライアントがあってもゲートウェイがそれを支えることにはなりません。実際に必要な機能、つまり認証方式、分割トンネルの挙動、DNS の扱い、そして機器が求める権利を比べます。それぞれを展開中のリリースについて Meraki の文書から取ります。

たいてい問題になるのは認証です。クライアントが提供しても機器側で設定できない方式は、起きるのを待っているサポート案件です。

クライアントの版と権利

Cisco Secure Client は同じクライアント系列の現在の名称なので、AnyConnect に触れた文書が必ず古いわけではありません。重要なのは組織が展開する版と、機器のリリースがそれに対して検証されているかどうかです。

ライセンス要件は別のプラットフォームから推測せず、同じガイドで確認します。この三つは独立して壊れるため、エンドポイント名、証明書の検証、承認済みの認証フローを一つのサービス記録にまとめて保ちます。利用者がクリックして通り過ぎる証明書の警告は互換性の結果ではなく、検証されていない設定です。リモートアクセスは仕事の半分にすぎず、利用者には目的地に届くための経路と権限がいまも必要だからです。

五つの項目で記録を書く

機種、ファームウェア、リモートアクセス方式、クライアントの版、そして展開が求める機能です。五つの項目であり、AnyConnect を使えるかという答えは、どれか一つではなく組み合わせの中にあります。その記録は、ファームウェア更新後に何を再確認すべきかを次の技術者に伝えます。

次に、認証し、内部名を解決し、許可された資源に届き、届くべきでない資源が拒否されることを確かめる形で、経路を端から端まで試します。ログインは成功しても資源がまったく読み込まれないのは部分的な結果であり、欠けている半分はたいていクライアントではなく経路制御か権限です。試した組み合わせを変更と一緒に記録し、次の人が標語ではなく証拠を受け取れるようにします。

関連記事