FortiGate の SSL-VPN 廃止、設定を読んだら IPsec。止めるべきは別にあった

前回の記事（10月19日）で、「OS を上げると、今の FortiClient の VPN はつながらなくなる」と書いた。販売店の説明も、前任の資料も、社内の ID 管理にあるグループの名前も、そう読めた。

FortiGate の設定を API で読んだら、この会社の VPN は SSL-VPN ではなく IPsec で動いていた。SSL-VPN の廃止は、この会社の VPN には関係がなかった。代わりに出てきたのは、前の保守業者の担当者の VPN アカウントと、もう誰も使っていない VPN の入口だった。

ある会社（30名規模、オフィスに FortiGate 60F）で、設定を書き込めない権限で読み、見つかった残骸を「止めても業務が止まらないか」で仕分けて止めるまでを書く。終わっていないことは、終わっていないと書く。

▼前回の記事の前提が違っていた：VPN は SSL-VPN ではなく IPsec だった

前回の記事（FortiGate の購入先を変える話）の時点で、この会社の VPN が SSL-VPN だと思える材料は3つあった。設定を読んで、1つずつ答え合わせをした。

そう読めたもの	設定を読んだら
前任の引き継ぎ：「VPN の利用者は FortiGate の管理画面で作る」	合っていた。ただ、それが SSL-VPN か IPsec かは、説明に出てこなかった
社内の ID 管理（Entra ID）に、名前から SSL-VPN 用と読めるグループがあり、30人ほど入っていた	FortiGate からは参照されていなかった。昔の名残。当日、棚卸しの直前に、自分も入社のチェックリストに一度「このグループに入れる」と書いていた
販売店：「SSL-VPN がなくなるので、OS を上げると今の FortiClient の VPN が使えなくなる」	SSL-VPN を使っている 60F なら、その通り。この会社は使っていなかった
前回の記事：上の説明を前提に「いずれ IPsec などへの移行が要る」	前提が違った。前回の記事には訂正を追記した

実際の設定はこうだった。FortiClient の VPN は IPsec のダイヤルアップ。利用者は FortiGate のローカルユーザーとして作り、VPN 用のユーザーグループに入れる方式で、ID 管理側との連携（SAML や LDAP）はない。SSL-VPN の設定は残っていたが、待ち受けるインターフェースもポータルも認証のルールも空だった。外から使える状態ではなく、使われてもいなかった。

グループの名前も、資料も、人の説明も、間違ってはいない。ただ、どれも「昔そうだった」か「一般的にはそうだ」を語っている。今動いている設定は、機器の中にしかない。

60F は 7.6.0 から SSL-VPN がない（前回の記事の訂正）

だから何が変わったか

SSL-VPN の廃止は、機器を入れ替える理由にも、急いで移行する理由にもならなくなった。前回、機器ごと入れ替える提案を今は見送ると決めたが、その判断はむしろ強くなった。

宿題が消えたわけではない。「SSL-VPN からの移行」が、「VPN の認証をどう強くするか」に置き換わった。こちらは機器を替えなくても検討できる。

ついでに言うと、販売店から見積に必須だと言われていたシリアル番号も、前任の資料にはなく、同じ API の応答で取れた。

▼設定は、書き込めない API で読んだ

前任が設定した機器を初めて調べるときは、書き込めない権限で入る。調べている途中で、うっかり設定を変えてしまう事故を構造ごとなくせるからだ。

今回、設定を読んだのは自分ではなく AI エージェント（Claude）だった。だから、なおさら書き込めない鍵にした。画面を何枚もたどるより、同じ問いを一度に投げられて、答えがそのまま記録に残る。

用意したもの

• ▶ REST API 用の管理者を1つ：管理者プロファイルは全カテゴリ「読み取り」。API を受け付ける送信元は社内の LAN だけ
• ▶ 鍵の置き場所：Mac のキーチェーン。手順書・チャット・管理シートには値を書かない（シートには「API 用の管理者がある・読み取り専用・鍵の置き場所」だけ）
• ▶ 読むためのスクリプト：GET しかしない数十行の Python。呼び出しは、たとえばこういう形だ

「さっき API のアカウントを作ったから、見てきて」と頼んで、VPN の仕組みと気になる点4つが返ってくるまで約2分だった。その最初の返答で、エージェント自身が「さっき（SSL-VPN の廃止の）影響があるかもと書いたのは訂正する」と直していた。人も AI も、設定を読む前は同じところで間違える。

読めたもの・読めなかったもの

対象	読み取り専用の権限で
機器の状態（型番・シリアル・版）、インターフェース、VPN の設定と接続の状態、ユーザーとグループ、ログ	読めた
設定のバックアップ	403 で拒否された。バックアップは今まで通り管理画面から取る
管理者の一覧	空で返ってきた

あとで止めると決めたときも、最初の書き込みは 403 で弾かれた。読み取り専用はちゃんと効いていた。止めるものを決めてから、そのときに権限を上げて変えた。

API を使わないなら、管理画面で何を見るか

API でなくても、見るものは同じだ。

知りたいこと	見るもの
VPN の方式	IPsec のトンネルの一覧に、FortiClient 向けのダイヤルアップ（リモートアクセス）のものがあるか
SSL-VPN を本当に使っているか	「有効」の表示だけで決めない。ポータル・待ち受けのインターフェース・認証のルールに中身があるか
誰が VPN に入れるか	「ユーザーと認証」のユーザー定義とユーザーグループ。VPN の設定がどのグループを参照しているか

▼VPN を見に行ったら、前の業者のアカウントと、使っていない VPN の入口が出てきた

VPN だけを見に行っても、VPN の周りのものが一緒に出てくる。その場で全部直そうとせず、まず並べた。

• ▶ 前の保守業者の担当者の VPN アカウントが3件、有効のままだった。VPN のローカルユーザー約40件を ID 管理側の社員と突き合わせて見つかった
• ▶ Windows 標準の VPN 機能でつなぐ、古い L2TP の入口と、そこからの通信を通す設定が有効のまま残っていた。今つないでいる人はゼロ
• ▶ クラウド上の基幹システムへの経路は2本ある設計だが、予備の2本目が止まっていた

▼何から止めるか：止めても業務が止まらないかを先に確かめた

前任の残骸を見つけると、「危ないから今すぐ消す」に流れやすい。消す前に、止める候補ごとに「誰に影響するか」「今わかっていること」「戻し方」を1行ずつ書いた。

止めるもの	誰に影響するか	今わかっていること	戻し方
前の業者の VPN アカウント3件（無効化。削除はしない）	前の業者。社外から社内のネットワークに入れなくなる	今つながっていない。残っていたログにも出てこない。ヘルプデスクの契約は8月末で終わっている	有効に戻すだけ
L2TP の入口（通信を通す設定を先に、本体はあとで）	Windows 標準の VPN でつないでいる人がいれば、その人	今つないでいる人ゼロ、残っていたログにもゼロ。前任の手順書でも「廃止」扱い。FortiClient の VPN とは別の設定	設定を有効に戻すだけ

「消す」ではなく「無効化」にしたのには理由がある。機器に残っていたログは、ごく短い期間の分だけだった。「最近使われていない」と言えるのは、ログが残っていた範囲だけだ。それより前に誰かが使っていたかは分からない。分からないなら、戻せる形で止める。

前の業者の VPN アカウント3件

ヘルプデスクの契約は8月末で終わっていた。ただ、年内に少しだけ追加のフォローが残っていて、そこで VPN が要る可能性はゼロではない。だから無効化にとどめ、削除はフォローが終わってからにした。

使っていない L2TP の入口

入口の本体と、そこからの通信を通す設定は別物だ。先に通す設定だけを無効化した。本体の設定は、1週間様子を見て、誰からも声が上がらなければ消す予定だ。

変更の前後で比べた

止めたあと、同じ API で状態を読み直した。FortiClient でつながっている人は変更の直前が3人、直後も3人。基幹システムへの経路も、つながったままだった。業務に影響がないことを、感覚ではなく数字で確かめてから次に進んだ。

▼すぐには触らなかったもの：前任が止めていた2本目の経路

基幹システムへの経路は、2本ある設計だった。2本目は通信量がゼロだった。調べると、故障で落ちていたのではなく、FortiGate の設定で手で止められていた。1年以上前の設定の控えでも、すでに止まっていた。

止めた理由は、前任の資料にも引き継ぎの記録にも出てこない。見立てはある。2本とも同じ優先度で設定されていて、そのまま両方を動かすと通信が2本に振り分けられる。行きと帰りが別の経路を通ると、通信が不安定になることがある。それを嫌って1本にしたのではないか。ただ、これは推測だ。

案もある。2本目の優先度を下げて、普段は使わない予備として動かす。それでも、前任が意図して止めたものは、理由が分かるまで戻さない。理由を知らずに戻して基幹システムへの通信が不安定になれば、業務が止まる。触るなら、理由を確かめ、クラウド側の状態も見てから、業務時間外にやる。

▼手順書にして、新しく入る社員の分で「VPN を通ったか」まで確かめた

棚卸しは、手順書にして初めて次の人に渡せる。そして手順書は、実際に1人追加してつないでみるまで、正しいかどうか分からない。

書いたこと・直したこと

• ▶ VPN の利用者の追加：FortiGate でローカルユーザーを作り、VPN 用のユーザーグループに入れる。前任が設定していたが、手順書には載っていなかった
• ▶ 退職のとき：同じ画面で無効化し、グループから外す
• ▶ 入社のチェックリストと退職の手順を直した：「ID 管理のグループに入れる／外す」と書いてあったのを消した。そのグループは VPN の認証に使われていない

PC 側の FortiClient の設定値は手順書にだけ書いた。ここには載せない。

確認の落とし穴：「つながった」と「VPN を通った」は別

新しく入る社員の分を1件作り、入社する社員に渡す前の PC で、FortiClient の接続を作ってつないだ。つながって、VPN 用のアドレスも配られた。基幹システムを開くと、ログイン画面まで出た。

ただ、このとき FortiClient の受信は 0KB のままだった。画面が出ただけでは、その通信が VPN を通ったのかどうか分からない。

そこで2つで確かめた。

• ▶ 基幹システムに確認用の ID でログインして、メニューまで出るか
• ▶ FortiClient の受信バイトが増えるか（今回は 0KB から約10KB に増えた）

両方そろって、初めて「VPN を通って届いた」と言える。

もう1つ、社内の Wi-Fi につないだまま試すと、VPN を通らなくても社内のシステムに届いてしまう。手順書には、スマホのテザリングなど社外の回線から試す、と書いた。

▼今の状態と、まとめ

項目	状態
VPN の方式を設定で確かめ、利用者の追加・停止の手順書を書いた	済
ID 管理側の使われていないグループを、入社・退職の手順から外した	済
新しく入る社員の分を作り、VPN を通って基幹システムに届くことを確かめた	済
前の業者の VPN アカウント3件	無効化済み。削除は年内のフォローが終わってから
使っていない L2TP の入口	通信を通す設定は無効化済み。本体は1週間様子を見てから消す予定

• ▶ VPN の方式は、資料・グループ名・販売店の説明で決めない。機器の設定を読む。今回は SSL-VPN ではなく IPsec だった
• ▶ 前任が設定した機器には、まず書き込めない権限で入る。AI に読ませるなら、なおさら。書き込める権限は、止めると決めたときだけ上げて、終わったら戻す
• ▶ 見つけた残骸は「誰に影響するか・今わかっていること・戻し方」で仕分け、無効化で止める。削除はあと
• ▶ 前任が意図して止めたものは、理由が分かるまで戻さない
• ▶ 棚卸しは手順書にして、1人つないで「VPN を通ったか」を受信バイトで確かめるまでが一組