FortiClient のフルトンネル:オフィスのサブネットだけをルーティングする
VPN がデフォルトルートをインストールし、ローカルネットワークが消えます。テーブルを読み、LAN のデフォルトルートを戻し、オフィスのプレフィックスを追加してから DNS を修正します。
トンネルが上がり、アイコンが緑になり、ローカルネットワークが消えます。プリンター、NAS、オフィスのルーターがすべて応答しなくなります。FortiClient はプロファイルが要求したとおりに動いているだけです。ゲートウェイがデフォルトルートを送り、クライアントがそれをインストールし、すべてのパケットにトンネルへ入る経路ができました。修復はルーティングテーブルの編集と、その背後にある DNS の編集であり、この二つの編集の順序が、マシンがより良い状態で終わるか悪い状態で終わるかを決めます。
クライアントがインストールしたもの、そして LAN が消えた理由
クライアントの画面ではなく、テーブルを読むことから始めます。macOS ではnetstat -rnがテーブル全体を出力し、route -n get defaultが現在勝っているインターフェースとメトリックを示します。Linux ではip route showとip route get 8.8.8.8の組です。どちらも一つの問いに答えます。より具体的なものに一致しないパケットを、どのエントリが運ぶのかという問いです。
トンネルデバイスの名前は固定ではありません。macOS の IKEv2 プロファイルは通常、番号付きのutunを示し、SSL VPNクライアントはppp0を、OpenVPN はtun0を示します。メトリックの異なる二つのデフォルトが同時に存在することもあり、クライアントのエントリは、現れた瞬間ではなく再接続後に初めて引き継ぐことがあります。だからこそ、五分間隔で取得した二つのテーブルダンプが異なる話をすることがあるのです。
トンネルのデフォルトを先に消すべき理由
カーネルは最も長く一致するプレフィックスを選び、複数のルートが同じくらい具体的な場合はメトリックが最も低いものを選びます。そのため0.0.0.0/0をより良いメトリックでインストールするクライアントは、元のデフォルトを削除せずにすべての宛先を勝ち取り、物理ルートが今もテーブルに残って障害を説明し続けるのです。トンネルのデフォルトを先に削除すると、以前の動作が戻ります。そうして初めて、トンネルを通るプレフィックスルートが作者の意図どおりに機能します。
この手順の前にプレフィックスを追加するのが、半分しか動かないマシンを生む間違いです。新しいプレフィックスの通信はトンネルを通り、一覧にないものもトンネルのデフォルトを通るので、誰も追加していないサービスを誰かが開くまで、壊れて見えるものはありません。削除し、戻し、それから追加すれば、中間状態は予測可能なままです。
macOS と Linux での手順
macOS では、この手順でトンネルのデフォルトを削除し、物理デフォルトを戻し、オフィスのプレフィックスを一つトンネルへ戻します。ここに示したインターフェース名は、自分のテーブルのものに置き換えてください。
sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4Linux では同じ順序で別のツールを使い、デフォルトには LAN のゲートウェイ、オフィスのプレフィックスにはトンネルデバイスを指定します。古いrouteコマンドも古い構文を受け付けますが、現在のドキュメントに合うのはip routeの形式です。
sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0ルートがデバイスではなく次のホップを必要とする場合は、クライアントの出力から peer を取ります。推測すると 二つのエラーのどちらかになり、意味は異なります。誤ったゲートウェイは即座に network unreachable を返し、誤ったトンネル先はタイムアウトを返します。コマンドを再び変える前に、どちらが出たのかを読んでください。
プレフィックス、リゾルバー、そして暗いままの DMZ
一つのプレフィックスで作業全体を覆えることはまれです。アプリケーションサーバー、管理ネットワーク、DMZ、DNS サーバー自体がそれぞれ別の範囲にあることがあるので、始める前に名前を挙げられる範囲をすべて列挙し、各 ping の隣で名前解決も試してください。テストの途中で見つかった宛先こそ、変更記録から漏れるものです。アドレスでは応答するのに名前では失敗するルートは、たいていルーティングの衣装を着たリゾルバーの問題です。
リゾルバーは別の判断です。プロファイルが内部 DNS サーバーを送ってきた場合、デフォルトを外すと、それらのアドレスが公開名に対して到達不能になったり、トンネル経由でしか到達できなくなったりし、どちらの状態も紛らわしい部分的な結果を生みます。リゾルバーのアドレスをトンネル経由でルーティングするか、ドメインごとの解決を設定して、公開名の問い合わせがローカルのリゾルバーを使うようにしてください。
Linux の SSL クライアントには、知っておく価値のあるフィールド固有の障害があります。トンネルは接続し、オフィスの LAN は応答するのに、DMZ の一つの範囲だけが暗いままです。足りないのはその範囲をトンネルゲートウェイ経由で通すルートで、ゲートウェイはマシンごとに異なるため、ハードコードしたアドレスは次のノート PC が壊れる原因になります。クライアントの状態から導き出し、コマンドを自己文書化しておきます。
PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"実行する前に 二つの値を読んでください。peerはポイントツーポイントトンネルの遠端であり、DMZ のルートが必要とするアドレスです。ルーティングされたトンネルでは、同等のものはクライアントが報告するインターフェースまたはゲートウェイです。どちらも現れない場合、クライアントは想定したモードではありません。
次の接続のあと、そしていつローカルでの作業をやめるか
FortiClient はスリープやネットワークの変更のあとに再接続し、プロファイルが指定するものを再インストールします。そのため手動のルートは次の接続までしか持ちません。そしてそれは、一度の成功したテストが修正に見えてしまう、まさにその間隔です。一晩で消えるルートは想定された動作であり、新しい障害ではありません。
永続的な答えは二つあります。接続のたびに修正を再実行するスクリプトは、作者より長生きしうる回避策です。一方、ゲートウェイ管理者からのスプリットトンネルプロファイルが本当の修正です。クライアントは業務に必要な範囲だけをインストールするようになるからです。二つ目を依頼し、一つ目は待っている間だけ使ってください。フルトンネルをローカルで分割する前に、同意したポリシーも確認してください。リモートネットワークが、あなたの通信すべてが見えることに依存しているかもしれません。
チェックリストは短いです。テーブルを読み、トンネルのデフォルトを削除し、LAN のデフォルトを戻し、すべてのプレフィックスを追加し、名前解決を別に直し、再接続でルートが戻ることを想定しておきます。