Linux の FortiGate IPsec：実際につながるクライアントはどれか

Windows を使う同僚は FortiGate のウィザードのプロファイルを読み込み、一分でオンラインになる。同じベンダーのパッケージを Ubuntu に入れて IPsec タブを探すと、出てくるのは SSL VPN のポータルを開くことしかできないクライアントだ。そこから導く結論はたいてい二重に間違っている。ゲートウェイはあなたを拒否しておらず、Linux 版が壊れているわけでもない。Fortinet はそのクライアントを SSL VPN 対応だけで出荷しているので、モバイル IPsec プロファイルの居場所はなく、IKEv1 を話す場所で作り直すしかない。

まず、実際にどちらのプロトコルを渡されたのかを決める

ベンダーのクライアントを参照実装とみなすのをやめれば、この作り直しは機械的な作業だ。

FortiGate は SSL VPN と IPsec の両方を公開しており、引き継ぎのメールにどちらが付与されたかはほとんど書かれていない。ポータルの URL とブラウザ風のログイン画面があれば SSL VPN で、Linux での答えは openfortivpn であり、以下のフィールド対応表ではない。グループ識別子と事前共有鍵があればモバイル IPsec で、これは vpnc と strongSwan が扱うものだ。

ここを間違えるのが、Linux での試みが第一フェーズを終える前に失敗する最大の理由だ。クライアントが HTTPS ポータルに IKEv1 を提示しているか、その逆か。何かをインストールする前に、管理者へプロトコル名を書面で確認しよう。

四つの資格情報は四つの異なるフィールドを旅する

password という語は多くの引き継ぎで二度現れ、二つの別の意味を持つ。事前共有鍵はピア自体を認証するもので、管理者がゲートウェイの設定から読み取るマシンの秘密だ。アカウントのパスワードは別の資格情報で、そのピアの背後にどの人間がいるかを証明する。

残り二つの値は見落としやすい。グループ識別子はウィザードが IPsec グループオブジェクトに書き込んだ文字列で、0 は空欄ではなく正当な値だ。提案は各フェーズの暗号化・ハッシュ・Diffie-Hellman グループと PFS 設定を覆い、そのどの項目もゲートウェイと一致しなければならない。接続がフェーズ 1 で失敗するとき、原因はほぼ必ずこの四つのうちの一つなので、一つのダイアログに詰め込まず別々に書き留めておく。

各 vpnc フィールドに何を入れるか

エディタのフロントエンドと一緒にクライアントをインストールし、VPNC 接続を作る。

sudo apt install vpnc network-manager-vpnc network-manager-vpnc-gnome

ゲートウェイには FortiGate の公開アドレスを、グループ名にはゲートウェイの識別子をそのまま、裸のゼロも含めて設定する。Group password には事前共有鍵を、ユーザー名とパスワードには自分のアカウントを入れ、トークンがあればゲートウェイの想定どおりに付ける。詳細ダイアログでは提案が示す Diffie-Hellman グループを選び、PFS を同じグループに合わせ、クライアントが家庭用ルータの背後にあるときは NAT トラバーサルを有効にし、デッドピア検出はゲートウェイと同じ歩調にしておく。

グループ名は飛ばされがちなフィールドだ。任意に見えるうえ、既定のゼロがプレースホルダのように見えるからだ。空のまま送ると、クライアントはゲートウェイが検証する識別子とは別のものを送ってしまう。それでもプロファイルが通らなければ、詳細設定の値を、別サイト向けのフォーラム投稿ではなく動作中の Windows クライアントと比べる。

同じプロファイルを strongSwan 向けに書く

これらの値の長期的な入れ物としては strongSwan が優れている。設定がテキストファイルなので見直して保管できる。

conn office-fw
    keyexchange=ikev1
    aggressive=yes
    left=%any
    leftauth=psk
    leftauth2=xauth
    xauth_identity=YOUR_USER
    right=GATEWAY_ADDRESS
    rightauth=psk
    rightsubnet=OFFICE_SUBNET
    ike=aes128-sha1-modp1536!
    esp=aes128-sha1-modp1536!

ブロックの前に提案の行を読もう。末尾の感嘆符が意味を変えるからだ。その一つの提案を固定し、そうでなければクライアントが提示する代替案を取り除く。一つの変換ペアだけに設定されたゲートウェイは、リストで始まるクライアントを拒否する。だからこそ固定が交渉を一致に変える。アルゴリズム名は動作中のゲートウェイのプロファイルから正確に取り、プレースホルダは自分の値に置き換える。

二つの認証行は重複ではない。PSK がピアを、XAuth ブロックがユーザーを証明し、どちらを落としてもゲートウェイが終わらせないフェーズが残る。

別のフィールドを変える前に失敗を読む

ダイアログをでたらめにやり直すのではなく、症状から逆にたどる。アドレスが割り当てられずに上がる IKE SA は、ユーザー認証の交換が失敗したか一度も走っていないということなので、アカウントとトークンの扱いを確認する。決して終わらないフェーズ 1 は提案・グループ識別子・アグレッシブモードを指し、いずれも Windows クライアントだけでなくゲートウェイと突き合わせる。

確立してから数分ごとに落ちるトンネルは、両端のデッドピア検出の不一致だ。どこでも keepalive を切るのではなく、ゲートウェイのタイマーに合わせる。確立しても社内ホストに届かないトンネルは、押し出されたサブネットがローカルのルーティングテーブルに入っていないことが多く、サードパーティのクライアントはそれを自分でやらないかもしれない。

終わったら、動作する値をゲートウェイの持ち主に返そう。プロトコル、グループ識別子、事前共有鍵、提案、PFS、DPD の判断だ。そうすれば次の Linux マシンは一晩ではなく数分で済み、グループ名がゼロだったことを誰も再発見せずに済む。