Nebula の証明書を再読み込みしても IP が変わらなかった理由
再読み込みでホスト資格情報が読み直されるのは、オーバーレイアドレスが変わらない場合だけです。アドレスの変更は再起動とネットワーク変更であり、再試行ではありません。
別のオーバーレイアドレスで新しいホスト証明書を発行し、古いファイルに上書きし、再読み込みを送っても、ホストは以前のアドレスで応答し続けます。反射的には、再読み込みが失敗したか、誤ったファイルが読まれたと考えます。通常はどちらでもありません。実行中のプロセスが、すでに持っている識別情報を意図的に維持したのです。置き換えによって、再読み込みでは適用できないものが変わったからです。
Nebula の PKI 再読み込みサポートはこの境界とともに文書化されており、同じ文書が他の変更では再読み込みが機能すると示していると、見落としやすくなります。
再読み込みが実際に読み直すもの
ホスト証明書は、SSH 鍵のような単なる資格情報ではありません。オーバーレイアドレス、ホスト名、グループ所属、有効期間を保持し、それらはすべて CA の署名で結び付けられています。デーモンはその署名済みの内容を使って、自分をどう提示するか、どのルールが適用されるかを決めます。
再読み込みを使うと、プロセスはトンネルを落とさずに更新された資格情報を取り込めます。これは定期的なローテーションに有用です。同じアドレス、同じ名前、同じグループ、より遅い失効です。制約は、識別情報が同じままでなければならないことです。オーバーレイアドレスを変えると、再読み込みの経路では適用できません。アドレスは実行中のインスタンスがすでに確定した内容の一部だからです。
つまり、目にした動作は文書化された制限が正しく働いている結果であり、無言の失敗ではありません。ディスク上のファイルは新しく、メモリ上の識別情報は古く、プロセスには再起動なしにその差を解消する支持された方法がありません。
アドレス・名前・グループは一つの識別情報
証明書は、個別に編集できるフィールドの集まりではなく、一つのレコードと考えると理解しやすくなります。アドレスの移動は設定変更とは違います。アドレスは他のホストのピア設定、サービスのバインド、その識別情報に対して書かれたポリシーに現れるからです。
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
グループは独自の行に値します。同じ混乱のより静かな版を引き起こすからです。アドレスを保ったままグループを移したホストは、再起動後に別のサービスへ到達できることがあり、古いアドレスに ping するだけのテストは完全に健全に見える一方で、その下のアクセス判断は変わっています。到達性だけでなく、ルールで制御されたサービスを一つ確認してください。トンネルを確認することとポリシーを確認することの違いはそこにあります。
読み込まれた証明書と置き換えを比較する
デーモンがファイルを無視したと決めつける前に、両方を読んでください。読み込むつもりの証明書を表示し、変更したと思っているフィールドを確認し、実行中の設定がそのパスを指していること、別の場所のコピーを指していないことを確認します。
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)プロセスの引数は、人が思う以上に重要です。-config /etc/nebula/config.yml を渡しているユニットは、そのファイルの pki.cert エントリを読んでいます。ステージング用ディレクトリに置いた証明書は何にも影響しません。実行中のコマンドラインのパスを確認し、従った文書のパスを確認しないでください。両者が違えば、証明書にまったく触れずに問題を見つけたことになります。
新しい証明書が別のアドレスを持ち、プロセスが古いアドレスを保っているなら、謎ではなく説明が手に入ったことになります。許容できるなら再起動し、アドレス変更を偶発的なものではなく計画されたネットワーク変更として扱ってください。
アドレスの変更はネットワークの変更
マシンを移す計画と同じように計画してください。他のホストが古いアドレスを設定に固定しているかもしれませんし、サービスが明示的にバインドしているかもしれませんし、ファイアウォールルールがそれを前提に書かれているかもしれません。証明書を変えるとホストが移り、ホストが移ると他の場所の前提が無効になります。
作業中は第二の管理経路を確保してください。中断しているのがオーバーレイ接続そのものである可能性があるからです。これから壊すトンネルの上で作業するのは、五分の変更を現地訪問に変える古典的なやり方です。
再起動が許容できるかはホストが何をしているか次第で、これは技術的な問題ではなく日程の問題です。省略できないのは、再読み込みを五度目に送るのではなく、再起動が必要だと認めることです。
古い資格情報は別に退役させる
一台のマシンに代替を入れるだけでは、各ピアはすでに知っている資格情報を依然として信頼しています。変更の理由が侵害だったなら、古い識別情報は 信頼またはブロックリストの手順で退役させる必要があり、そうして初めてピアはそれを拒否します。
これは独自の検証を伴う別の手順です。新しいファイルが仕事をしたと決めつけるのではなく、別のホストから古い識別情報がもう機能しないことを確認してください。Nebula の PKI 設定ドキュメントは、再読み込み可能な設定とここで説明したアドレスの制限を扱っており、本番向けのものをローテーションする前に全文を読む価値があります。