Fortinet Linux クライアント：修理の前にゲートウェイを確認する

アーカイブされたガイドは、32 ビットのライブラリをインストールし、GTK テーマにパッチを当て、ターミナルからインストーラーを実行するよう指示している。その助言の一部は特定のクライアントリリースには正しかったが、ゲートウェイがもう提供していないトンネルモードを戻せるものは何もない。パッケージを変更する前に、最初に失敗した段階を見つける。これは、答えが安く手に入るのがそこであり、誤ったローカル修正が最も多くの時間を奪うという理由で、ゲートウェイから内側へ進む。

確認 1：失敗した段階を名指しする

三つの段階はそれぞれ違う形で失敗する。プログラムが起動しない、起動してサーバーの身元を拒否する、接続はできるが必要な種類のサービスがゲートウェイにない、のいずれかだ。どの失敗にも、ローダーのエラー、証明書のメッセージ、利用できないモードを名指しするゲートウェイの応答という固有の証拠が残る。

何かに触れる前にそれを書き留める。この時点以降のすべては、どの段階を名指ししたかによって決まり、三つの修正に共通点はない。

確認 2：ゲートウェイのリリースとトンネルモード

現在のゲートウェイではトンネルモードが廃止されており、FortiClient 7.4.4 の Linux 統合表にそれが書かれている：FortiOS 7.6.3 以降は SSL VPN のトンネルモードを提供せず、管理者を IPsec へ導く。その文を繰り返すときは、製品、リリース、モードをその文に結び付けたままにすること。すべての Fortinet 製品について語っているわけでも、今も残るウェブアクセス機能について語っているわけでもない。一般的なバージョン互換性と、一つのトンネルモードの可用性は別の確認である。

ゲートウェイの所有者に二つ尋ねる：ゲートウェイがどのリリースで動いているか、今日どのアクセス方式が有効か。回答は書面で求め、リリース文字列と、それが由来する設定ページまたは設定行を添えてもらうべきであり、その理由は、口頭の保証こそが人をアーカイブされたガイドへ戻すからだ。そのうえで、その回答をゲートウェイのリリースノートまたはベンダーのマトリックスの、まさにそのリリースと突き合わせる。ウェブポータルを表示するブラウザーが証明するのは、ポータルが応答することだけである。

確認 3：所有者が承認するクライアントのエディション

承認済みの Linux クライアントのエディションとバージョンを入手し、対応するオペレーティングシステム、アーキテクチャ、デスクトップ、認証フローを確認する。7.4.4 のマトリックスはバージョンに縛られた例であり、最新クライアントへの推奨でも、すべての派生版への約束でもない。所有者が実際にどれをサポートするかを尋ねるべきであり、その回答は移行の一部であって後付けの考慮ではない。最初のパケットがゲートウェイに届く前に落ちるクライアントは、ノート PC について何かを示すのであって、サービスについては何も示さない。

32 ビットのライブラリとパッチを当てたテーマは、バイナリーが読み込めるものを変えるが、ベンダーがサポートするものは変えない。オペレーティングシステムや認証フローがマトリックスの外にあるなら、適格性の問いにはすでに答えが出ている。

確認 4：代替プロファイルを要求する

組織が SSL VPN のトンネルモードから IPsec へ移ったなら、新しいプロファイルと登録手順を同じ会話の中で要求する。SSL の設定を名前ごと変えて、項目が引き継がれると仮定してはいけない：IPsec のプロファイルは IKE のバージョン、リモートゲートウェイとその身元、認証方式、双方が受け入れるトラフィックセレクターを指定する。アカウントとデバイスのポリシーも別の形で適用されうる。名前の変更が生むのは、設定済みに見えて何も折衝しないクライアントである。

プロファイルを信じる前に読むこと。IKE のバージョンと提案、認証が証明書か事前共有鍵か、どのローカルとリモートのサブネットが選ばれるか、ゲートウェイが自分の身元として何を期待するかが書かれているべきだ。移行文書はすべてのクライアントリリースについて機能の同等性を述べたものではないため、承認済みの Linux クライアントがその構成に対応することを確認すること。openfortivpn のような独立系クライアントは OpenVPN のインタープリターではないので、名前に SSL を持つ他のものは、所有者がこのモード、このログイン方式、このデバイスポリシーについて別段のことを言うまで未承認として扱うこと。

確認 5：ローカルの依存関係、そして検証と記録

ゲートウェイとクライアントが片付いたなら、起動の失敗はパッケージングの問題であり、保守されているパッケージ自身の手順が従うべき参照点となる。TLS の身元の失敗は運用者に属する：信頼のアンカーと期待される名前は運用者の設定であり、ローカルで回避するものではない。アーカイブされたガイドがかつて役に立ったのは、この二つの段階だけである。

どちらも、未知の証明書を受け入れたり、状態チェックを切ったりして解決するものではない。MFA とデバイスのチェックはそのままにしておくべきであり、それらを弱めて接続を取り戻すのは障害をインシデントに取り替えることになる。モードが廃止されたなら、ローカルのフラグでは戻せない。

承認された変更の後、目的のプライベートリソースに到達し、DNS 解決を確認し、一度だけ再接続する。クライアント、プラットフォーム、ゲートウェイのリリース、トンネルモードを、次の担当者が四つとも必要とするのだから、まとめて記録すること。プログラムが正常に開いたということは、ローカルの起動段階を通過したということであり、それ以上の何でもない。