デバイスの時計がずれているとVPNが止まる：まず時刻を確認する

VPNが接続しなくなり、ログに証明書の文字が見え、最初の反応はプロファイルの差し替えになる。数分や数時間ずれた端末の時計はまさにそのエラーを生む。証明書の有効性はローカルの瞬間を基準に判定されるからだ。画面のタイムゾーン表示は問題ではない。問題はその下の時刻である。証明書関連の作業に触れる前に、まず時計を確認する。

エラーは時計ではなく証明書の問題に見える

TLSハンドシェイクは、相手の証明書が検証側の時計に対して有効期間の外に出ると失敗する。この検査はクライアントで走るので、クライアントの時計がずれていると正常な証明書が拒否される。エラー文には証明書の名前が出るため、人はそれを交換し、同じ失敗を再び見る。時計のほうが安い仮説であり、先に試すべきだ。

実時刻より進んだ時計は現在の証明書を期限切れとして拒否し、遅れた時計は新しい証明書をまだ有効でないとして拒否する。どちらのメッセージも日付を指し、どちらも認証局との接触なしに生成される。これが手がかりだ。本当の期限切れはすべてのクライアントに影響するが、時計の問題は誤った時刻を持つ一台だけに影響する。

瞬間を読み、それから証明書を読む

何かを変える前に、UTCの時計と証明書自身の日付を出力する。二つの絶対的な瞬間を比べれば、タイムゾーンの問題は調査から完全に消える。証明書の有効期間に現在の瞬間が入っていれば、証明書は原因ではない。

date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

ローカルの時計がずれているなら、同期しているか、何と同期しているかを確認する。同期が無効な端末、または到達できない時刻ソースを持つ端末は、どこかが壊れるまでずれ続ける。状態の出力にはソースと最後に成功した調整が出るので、現在のずれだけより役に立つ。ソース未設定の大きなずれは、動作するソースに対する小さなずれとは別の問題だ。

timedatectl timesync-status
chronyc tracking

すべてのクライアントで証明書が本当に期限切れなら、そこで止める。時計は正常で、証明書は調整ではなく更新が必要だ。

ログインコードは関連するが別の理由で失敗する

時刻ベースのワンタイムパスワードは現在の時間ステップから値を導く。通常は三十秒だ。時計が一、二ステップ以上ずれた端末は、利用者が正しい数字を入力してもサーバーが受け付けないコードを生成する。エラーはパスワード誤りに見えるため、時計を直せない再設定ループに人を追い込む。

どの構成要素が試行を拒否したかを見極める。VPNクライアント、ゲートウェイ、IDプロバイダーは別の段階を報告する。コードだけ拒否されてパスワードが通るなら、アカウントはおそらく正常で、疑わしいのは時計だ。両方拒否されるなら、アカウントがロックされている可能性があり、時計は誤った手がかりだ。自分が開始していない要求を承認するのではなく、プロバイダーの復旧手順に従う。

コードを通すために時計を戻してはいけない。原因を隠し、次の時刻ベースの検査を壊す。

表示された時刻ではなくソースを直す

同期はネットワークサービスであり、トンネルは時刻ソースに到達できるかを変えうる。社内ソースはトンネルを必要とすることがあり、公開ソースはポリシーで遮断されることがある。時刻サービスの経路だけが失敗してもブラウジングは動くので、この依存は見落としやすい。NTPは調整の背後にあるプロトコルで、他のサービスと同じく独自の経路を必要とする。

sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20

起動順序の問題もある。大きくずれた時計は認証済みトンネルを妨げることがあり、使える唯一の時刻ソースがそのトンネルの向こうにあることがある。管理された端末群にはその状態の文書化された手順が必要で、証明書検証の迂回はその手順ではない。個人の端末ではOS自身の時刻設定を使い、シャットダウンや復元の後に時計が失われる理由を突き止める。起動のたびにずれる機械はハードウェアか設定の問題であり、VPNの問題ではない。

修理の後、元の接続を再試行し、新しいエラーを別に読む。サーバー識別の不備、本当に期限切れの証明書、拒否されたアカウントは三つの別の失敗であり、これを混同することが、単純な時計修正を一週間のプロファイル交換に変えてしまう。