การรีโหลดใบรับรอง Nebula ไม่ได้เปลี่ยน IP: นี่คือสาเหตุ
การรีโหลดจะอ่านข้อมูลรับรองของโฮสต์ใหม่ก็ต่อเมื่อแอดเดรส overlay ยังคงเดิม การเปลี่ยนแอดเดรสหมายถึงการรีสตาร์ตและการเปลี่ยนเครือข่าย ไม่ใช่การลองใหม่
คุณออกใบรับรองโฮสต์ใหม่ที่มีแอดเดรส overlay ต่างออกไป คัดลอกทับไฟล์เดิม ส่งคำสั่งรีโหลด และโฮสต์ก็ยังตอบบนแอดเดรสเดิม ปฏิกิริยาตามสัญชาตญาณคือคิดว่าการรีโหลดล้มเหลวหรืออ่านไฟล์ผิด ปกติแล้วไม่เกิดขึ้นทั้งสองอย่าง กระบวนการที่กำลังทำงานอยู่ได้เก็บรักษาตัวตนที่มีอยู่เดิมไว้โดยเจตนา เพราะไฟล์แทนที่เปลี่ยนบางสิ่งที่มีการรีโหลดไม่สามารถนำไปใช้ได้
การรองรับการรีโหลด PKI ของ Nebula มีเอกสารกำกับขอบเขตนี้ไว้ และเป็นเรื่องง่ายที่จะมองข้ามเมื่อเอกสารเดียวกันแสดงว่าการรีโหลดใช้ได้กับการเปลี่ยนแปลงอื่น
การรีโหลดอ่านอะไรใหม่จริง ๆ
ใบรับรองโฮสต์ไม่ใช่แค่ข้อมูลรับรองแบบกุญแจ SSH มันบรรจุแอดเดรส overlay ชื่อโฮสต์ การเป็นสมาชิกกลุ่ม และช่วงเวลาที่ใช้ได้ และทั้งหมดนี้ผูกเข้าด้วยกันด้วยลายเซ็นของ CA เดมอนใช้เนื้อหาที่ลงนามแล้วนั้นในการตัดสินว่าจะนำเสนอตัวเองอย่างไรและมีกฎใดใช้บังคับ
การรีโหลดทำให้กระบวนการรับข้อมูลรับรองที่ต่ออายุแล้วโดยไม่ต้องทิ้งทันเนลของตน ซึ่งมีค่าสำหรับการหมุนเวียนตามปกติ: แอดเดรสเดิม ชื่อเดิม กลุ่มเดิม และวันหมดอายุที่ช้าลง ข้อจำกัดคือตัวตนต้องคงเดิม หากเปลี่ยนแอดเดรส overlay เส้นทางรีโหลดจะนำไปใช้ไม่ได้ เพราะแอดเดรสเป็นส่วนหนึ่งของสิ่งที่อินสแตนซ์ที่กำลังทำงานได้ผูกพันไว้แล้ว
ดังนั้นพฤติกรรมที่คุณเห็นคือขีดจำกัดที่มีเอกสารกำกับกำลังทำหน้าที่ของมัน ไม่ใช่ความล้มเหลวแบบเงียบ ไฟล์บนดิสก์เป็นของใหม่ ตัวตนในหน่วยความจำเป็นของเก่า และกระบวนการไม่มีวิธีที่รองรับในการปรับความต่างนี้ให้เข้ากันโดยไม่รีสตาร์ต
แอดเดรส ชื่อ และกลุ่มคือตัวตนเดียวกัน
การมองใบรับรองเป็นเรกคอร์ดเดียวช่วยได้ มากกว่ามองเป็นชุดฟิลด์ที่แก้ไขแยกกันได้ การย้ายแอดเดรสไม่เหมือนการเปลี่ยนค่ากำหนด เพราะแอดเดรสปรากฏในการตั้งค่าเพียร์ของโฮสต์อื่น ในการผูกบริการ และในนโยบายที่เขียนขึ้นต่อต้านตัวตนนั้น
| 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 ของไฟล์นั้น และใบรับรองที่ติดตั้งในไดเรกทอรีชั่วคราวไม่มีผลอะไร ตรวจเส้นทางในบรรทัดคำสั่งที่กำลังทำงาน ไม่ใช่เส้นทางในเอกสารที่คุณทำตาม หากสองอย่างต่างกัน คุณพบปัญหาโดยไม่ต้องแตะใบรับรองเลย
หากใบรับรองใหม่มีแอดเดรสต่างและกระบวนการเก็บของเก่าไว้ ตอนนี้คุณมีคำอธิบายแทนปริศนา รีสตาร์ตหากยอมรับได้ และถือว่าการเปลี่ยนแอดเดรสเป็นการเปลี่ยนเครือข่ายที่วางแผนไว้ ไม่ใช่เรื่องบังเอิญ
การเปลี่ยนแอดเดรสคือการเปลี่ยนเครือข่าย
วางแผนเหมือนวางแผนย้ายเครื่อง โฮสต์อื่นอาจปักแอดเดรสเก่าไว้ในการตั้งค่าของตน บริการอาจผูกกับแอดเดรสนั้นอย่างชัดเจน และกฎไฟร์วอลล์อาจเขียนขึ้นต่อแอดเดรสนั้น การเปลี่ยนใบรับรองคือการย้ายโฮสต์ และการย้ายโฮสต์ทำให้สมมติฐานที่อื่นใช้ไม่ได้
ให้มีเส้นทางบริหารจัดการที่สองพร้อมใช้ระหว่างทำ เพราะการเชื่อมต่อ overlay อาจเป็นสิ่งที่คุณกำลังตัดขาด การทำเรื่องนี้ผ่านทันเนลที่คุณกำลังจะทำให้ขาดเป็นวิธีคลาสสิกในการเปลี่ยนการแก้ไขห้านาทีให้กลายเป็นการเดินทางไปหน้างาน
การรีสตาร์ตยอมรับได้หรือไม่ขึ้นกับว่าโฮสต์กำลังทำอะไร และนั่นเป็นคำถามเรื่องตารางเวลาไม่ใช่เทคนิค สิ่งที่ไม่ใช่ทางเลือกคือการยอมรับว่าจำเป็นต้องรีสตาร์ต แทนที่จะส่งคำสั่งรีโหลดเป็นครั้งที่ห้า
ปลดระวางข้อมูลรับรองเก่าแยกต่างหาก
การติดตั้งไฟล์แทนที่บนเครื่องเดียวทำให้ทุกเพียร์ยังคงเชื่อถือข้อมูลรับรองที่มันรู้จักอยู่แล้ว หากเหตุผลของการเปลี่ยนคือการถูกบุกรุก ตัวตนเดิมต้อง ถูกปลดระวางผ่านขั้นตอนความเชื่อถือหรือบัญชีดำ เพื่อให้เพียร์ปฏิเสธจริง ๆ
นั่นเป็นขั้นตอนแยกที่มีการตรวจสอบของตัวเอง: ยืนยันจากโฮสต์อื่นว่าตัวตนเดิมใช้ไม่ได้แล้ว แทนที่จะถือว่าไฟล์ใหม่ทำงานเสร็จแล้ว เอกสารการตั้งค่า PKI ของ Nebula ครอบคลุมการตั้งค่าที่รีโหลดได้และข้อจำกัดเรื่องแอดเดรสที่อธิบายไว้ที่นี่ และควรอ่านให้ครบก่อนหมุนเวียนสิ่งใดที่หันหน้าเข้าสู่โปรดักชัน