【Check Point】構築に関する小ネタまとめ【バージョン別】

ファイアウォール(UTM)
スポンサーリンク

R75, R77 台

RC4 暗号方式のために HTTPS 接続ができない

R75 台では TLS 暗号方式がデフォルトで RC4 になっています。ですが現在ののブラウザでは RC4 は非対応になっているため、デフォルトのままではどのブラウザを使っても HTTPS 接続ができません。つまり、初期設定ウィザードすら表示することができません。

回避策としては、Check Point 機器にコンソール接続して TLS 暗号方式として RC4 を使用しないように設定変更します。設定方法については以下のサポート情報を確認してください。

Gaia Portal cannot load showing ERR_SSL_VERSION_OR_CIPHER_MISMATCH error in the browser

ただし、上の回避策を実施したとしても IE 以外では HTTPS アクセスできません。

R75.40 の Gaia ポータルにはアップグレード用の画面がある

R77.30 以降では、Gaia ポータルの CPUSE の画面で各種パッチやアップグレード/クリーンインストールのパッケージをインポートしたり適用したりすることができます。一方、R75.40 では、Gaia ポータルに Upgrade という画面があり、アップグレード用パッケージのインポートや適用はこの画面で行う必要があります。R75.40 では CPUSE の画面でアップグレード用パッケージのインポートをしようとするとインポートに失敗します。

初期設定ウィザード後に SmartDashboard にてログインが失敗する

初期設定ウィザード実施後に、初めて SmartDashboard にて管理サーバにログインしようとしたときに、以下のようなエラーメッセージが表示されてログインできない場合があります。

  • Connection cannot be initiated. Please make sure the server ‘x.x.x.x’ is up and running and that you are defined as a GUI Client.

このとき、CLI で cpca_client lscert コマンドで証明書情報を表示しようとすると以下のような内容になり、証明書情報が表示できません。

> cpca_client lscert
Operation failed. rc=-1.

R77.30、R75.40 のとあるアプライアンスでこの事象を確認していますが、原因は、内部認証局の初期設定時に作成される証明書の有効期限が関係していて、2018年1月24日以降に初期設定ウィザードを実行した場合にこの事象が発生する場合があります。

回避策としては、システムの日付設定を一時的に2018年1月23日以前に設定した後で、内部認証局の初期化をすることです。(CLI で日付設定後は save config を実行します。)

内部認証局の初期化は cpconfig コマンドから実施します。cpconfig のメニューの中から「Certificate Authority」の番号を指定すると内部認証局を初期化できます。

> cpconfig
This program will let you re-configure
your Check Point products configuration.


Configuration Options:
----------------------
(1)  Licenses and contracts
(2)  Administrator
(3)  GUI Clients
(4)  SNMP Extension
(5)  PKCS#11 Token
(6)  Random Pool
(7)  Certificate Authority
(8)  Certificate's Fingerprint
(9)  Disable Check Point SecureXL
(10) Check Point CoreXL
(11) Automatic start of Check Point Products

(12) Exit

Enter your choice (1-12) :7



Configuring Certificate Authority...
====================================

The Internal CA will now be initialized
with the following name: hostname
Is it OK (y/n) [y] ? y

Initializing the Internal CA...(may take several minutes)
 Internal Certificate Authority created successfully
 Certificate was created successfully
Certificate Authority initialization ended successfully
Trying to contact Certificate Authority. It might take a while...
hostname was successfully set to the Internal CA

Done

なお、システム日付設定を2018年1月23日以前に設定していない場合は内部認証局の初期化は失敗します。

内部認証局を初期化できたら以下の手順を実施します。

  1. cpstop/cpstart を実行し Check Point サービスを再起動
  2. 日付設定を正しい日付に戻す(設定後 save config を実行)
  3. 再度 cpstop/cpstart を実行し Check Point サービスを再起動

この後、cpca_client lscert コマンドで証明書情報が表示できることを確認してください。

証明書情報が表示できていれば、SmartDashboard でログインができるはずなのでその確認をしてください。

Check Point クラウドサーバのドメインが古くてアクセスできない

これは R75.40 のとあるアプライアンスで判明した事象です。

ライセンスのオンラインアクティベートを試してみたところ、ネットワーク接続性の問題で Check Point クラウドサーバにアクセスできないとのエラーになりました。設定・環境上は問題ないはずだったのでパケットキャプチャしてみたところ、Check Point のドメインに関する DNS クエリに対する戻りパケットとして DNS サーバから「そのドメイン見つからなかったぞい」というパケットが来ていました。

どうやら Check Point 機器内部で持っている Check Point クラウドのドメインが古いか何かの理由で名前解決できなかったようです。これはもうどうしようもないですね。検証でライセンスが必要な場合はサポートから評価ライセンスをもらってください。

Deployment Agent のバージョンが古い場合は手動アップデートが必要

バージョンが古い機器の場合、Deployment Agent も古いバージョンになっている場合があります。Deployment Agent のバージョンが一定以上であれば、機器がインターネット接続できる環境にあれば Deployment Agent をオンラインで自動アップデートしたり、JHF やアップグレード用のパッケージを Gaia ポータル上でインポートしたりできますが、古いバージョンではそれができません。

Deployment Agent が古いバージョンの場合は手動でアップデートする必要があります。アップデートするためにはアップデート用のデータを入手して機器に格納し、インストールコマンドを実行する必要があります。アップデート用のデータはサポートから提供してもらう必要があるため、サポートに問い合わせをしてください。

R75.40 では Gaia バックアップ/リストアは CLI でのみ対応

R75.40 では Gaia ポータルに System Backup の画面があるにもかかわらず、Gaia ポータル上からのバックアップ/リストアには対応しておらず、CLI からの実行のみ対応しています。

R75.40 のとあるアプライアンスで Gaia ポータルにてリストアを実行したところ、リストアは実行できるものの、中途半端な結果となり正常にリストアできませんでした。その後、CLI でリストアしたところ正常にリストアできました。

この結果から、R75.40 ではバックアップ/リストアは CLI での実施を推奨します。

R80 台

R81 台

R81 については以下の記事にまとめています。

共通

アップグレードしても Factory Default 先のバージョンは変わらない

アプライアンスでバージョンアップをしたい場合、現在の設定値を引き継ぎつつバージョンアップする「アップグレード」と、設定値を完全に初期化しつつバージョンアップする「クリーンインストール」の 2 つの方法があります。

アップグレード」方式でバージョンアップした場合、Gaia ポータルから実施できる Factory Default の初期化先バージョンはアップグレード前のバージョンのままとなっています。

検証などでバージョンアップ後にバージョンを元に戻す予定がある場合などは、アップグレード方式で行うとバージョンダウンを簡単に行うことができます。

Full High Availability クラスタのプライマリ機のホスト名は変更できない

Check Point 機器のホスト名変更や IP アドレス変更は、管理サーバ(SmartConsole)上でのオブジェクトの設定にも影響するため慎重、かつマニュアルの手順に従って行う必要があります。

管理サーバとゲートウェイが分かれている分散構成の場合は、面倒ではあるもののホスト名の変更は可能です。

ただ、スタンドアロン構成における冗長化である Full High Availability クラスタ を構成している場合は、プライマリ機のホスト名変更ができません。

プライマリ機の「ホスト名変更ができない」の意味としては、SmartConsole 上でのオブジェクトの名前変更ができません。

Full High Availability クラスタにおける機器ホスト名変更は、SmartConsole 上ではクラスタオブジェクト配下のメンバーオブジェクトの名前変更になりますが、メンバーオブジェクトの名前変更をするためには、先に SIC 認証のリセットをする必要があります。

ここで、セカンダリ機に対しては SIC 認証のリセットができますが、プライマリ機に対しては SIC 認証のリセットができません。このためプライマリ機についてはホスト名変更ができません。

この仕様は、Full High Availability クラスタ構成の既存機器をリプレイスする際のキッティング方法に影響します。通常、Check Point 機器をリプレイスする際は、管理サーバデータベースを既存機器からエクスポートし、そのデータを新機器にインポートすることでデータを移行します。

この時、クラスタオブジェクト及びメンバーオブジェクトの名前は既存機器と同じになるため、新機器のホスト名は既存機器と同じにする必要があります。

この仕様から、プライマリ機のホスト名を新機器では変えたい場合、既存機器のエクスポートデータをインポートするという方法を採ることができません。

参考資料

cpca_client lscert


タイトルとURLをコピーしました