ステータスランプを一つだけ信じずにルーター VPN を監視する

ステータスページは接続済みと表示し、ランプは緑なのに、オフィスはファイルサーバーに到達できません。その事実の一方はトンネルについて、もう一方はその中の経路について述べています。両方を監視することが、行動できるアラートと、無視することを覚えるアラートの違いです。

ピアから外側へ、順に五つの確認を行います。

確認 1: ピアまたは関連付けの状態

各プロトコルは独自の状態を公開します。WireGuard は wg show を通じて、ピアごとの最新のハンドシェイクと転送カウンターを表示します。OpenVPN はセッション状態をステータスファイルまたは管理インターフェースに書き込み、IPsec は ipsec statusall のようなツールでセキュリティ関連付けを公開します。罠は、タイムスタンプを判定として読むことであり、送るものがないアイドル状態の WireGuard ピアが最近ハンドシェイクしないからといって障害ではありません。

誰かを呼び出す前に、タイムスタンプを想定されるトラフィックと keepalive の設定と比較してください。

確認 2: 選択されたルート

トンネルインターフェースが存在しても、そこに何もルーティングされていないことがあります。気にしている宛先について転送テーブルを確認し、トンネル自身のサブネットを見ないようにします。プレフィックスがない、または別の場所を指しているなら、ピアの状態は関係ありません。

その確認は、ステータスランプが決して示さない障害を捕まえます。

有用な二つ目の確認は、送信元アドレスも比較します。ip route get 10.20.5.10 は次のホップ、インターフェース、優先送信元を返し、送信元が誤っていれば遠端での戻りトラフィックを壊すのに十分です。想定される三つ組を一度記録し、いずれかの要素が変わったらアラートを出します。この一行だけで、NAT の変更、インターフェースの変動、ポリシールーティングの誤りを捕まえられます。

確認 3: 許可されたアプリケーション経路

実際の要件を代表するものを試します。ルーター発の ping はルーター自身のアドレスとポリシーから出るため、転送される LAN トラフィックとは異なることがあり、多くのホストは ICMP を制限しています。要件がプライベートサービスなら、そのサービスを実際のポートで試します。

確認の量は控えめに保ちます。監視ループが、自ら測るトラフィックそのものになってはいけません。

確認 4: 何がいつ変わったか

WAN の変更、鍵の更新、ルートの撤回、アプリケーションの障害を一つのタイムライン上で関連付けます。トンネルの障害と、通常のインターネットアクセスを静かに復旧させるフォールバックルートは、同じユーザー報告と正反対の診断を生むため区別してください。タイムゾーンの誤りは順序を逆にするので、比較の前に正規化します。四つの確認を原因に変えるのは、このタイムラインです。

ログは遷移のために残し、ペイロードのために残しません。

確認 5: アラートは境界を名指しすべき

VPN が落ちたというアラートは、半分の確率で人を間違った場所へ送ります。ピアのハンドシェイクが十二分間古い、10.20.0.0/16 へのルートがない、ポート 445 への確認が失敗している、というアラートは特定の確認を指します。

ペイロードを閲覧するのではなく、運用カウンターを保持します。カウンターは、必要のない内容を収集せずに監視の問いに答えます。

そして、次に何が起きるかはフェイルオーバーポリシーに決めさせます。監視はどの境界が失敗したかを特定すべきで、確認が失敗するたびに広範な回避を許可すべきではありません。OpenVPN 2.6 のマニュアルは、最初の確認をスクリプト化可能にするステータスファイルと管理インターフェースを文書化しています。