รายการบล็อกของ Nebula: แจกจ่ายมันเอง ประภาคารจะไม่ทำ

การบังคับใช้รายการบล็อกเป็นคุณสมบัติของโฮสต์ที่ตรวจสอบ ไม่ใช่ของคุณสมบัติของใบรับรองที่ถูกตรวจสอบ เครื่องที่ไม่เคยโหลดรายการจะยังคงยอมรับตัวตนนั้น และไม่มีอะไรในการจับมือแจ้งเตือนคุณว่าเพียร์สองตัวเห็นไม่ตรงกัน วิธีแก้ราคาถูกกับวิธีแก้ราคาแพงสำหรับข้อมูลรับรองที่รั่วไหลหนึ่งรายการแตกต่างกันทั้งขอบเขตและความสามารถในการย้อนกลับ จึงต้องเลือกอย่างตั้งใจ หัวข้อด้านล่างครอบคลุมว่ารายการทำอะไร ต้องส่งไปที่ไหน เมื่อใดการหมุนจึงเป็นคำตอบที่ดีกว่า และจะพิสูจน์ได้อย่างไรว่าวิธีใดวิธีหนึ่งได้ผล

รายการบล็อกทำอะไรจริง ๆ

การกำหนดค่า PKI ระบุลายนิ้วมือที่โฮสต์ต้องปฏิเสธ แม้ใบรับรองจะลงนามอย่างถูกต้องและยังไม่หมดอายุ การบังคับใช้เกิดขึ้นในเครื่อง เทียบกับรายการที่โฮสต์โหลดตอนเริ่มบริการ ไม่มีข้อมูลใดของรายการเดินทางอยู่ในใบรับรอง เพียร์จึงเรียนรู้การตัดสินใจจากข้อมูลรับรองที่ถูกแสดงให้ดูไม่ได้ นี่คือเหตุผลที่ประภาคารไม่มีบทบาทตรงนี้ ประภาคารช่วยให้เพียร์ค้นหากันและส่งต่อทราฟฟิกในที่ที่เส้นทางตรงล้มเหลว มันเป็นชั้นการค้นพบและการส่งต่อ ไม่ใช่ช่องทางแจกจ่ายการกำหนดค่า

การอัปเดตเครื่องหนึ่งเปลี่ยนการตัดสินใจของเครื่องนั้นและปล่อยเพียร์อื่นทุกตัวไว้เหมือนเดิม เพียร์ที่เชื่อถือผู้ออกใบรับรองและไม่เคยเห็นรายการไม่มีเหตุผลจะปฏิเสธอะไร การทดสอบการเพิกถอนด้วยการดูประภาคารจึงไม่พิสูจน์อะไร เพราะส่วนประกอบที่คุณดูอยู่ไม่เคยถูกขอให้บังคับใช้รายการ

ระบุใบรับรอง ไม่ใช่อุปกรณ์

ใช้ลายนิ้วมือของข้อมูลรับรองที่คุณตั้งใจจะปฏิเสธ เพราะชื่อโฮสต์ ป้ายอุปกรณ์ หรือที่อยู่ปัจจุบันระบุเครื่องหนึ่งวันนี้และอีกอย่างในเดือนหน้า ไม่มีสตริงเหล่านั้นปรากฏในรายการบล็อก และไม่มีอันใดอยู่รอดหลังการติดตั้งใหม่ พิมพ์ใบรับรอง อ่านลายนิ้วมือ และตรวจสอบว่ามันเป็นของข้อมูลรับรองที่กำลังจะเลิกใช้ ไม่ใช่ของตัวแทน การอ่านทั้งสองไฟล์สำคัญเมื่อตัวแทนถูกออกให้แล้ว เพราะใบรับรองเก่าและใหม่ใช้ชื่อร่วมกันและต่างกันในฟิลด์อื่นทั้งหมด

บันทึกลายนิ้วมือที่ถูกบล็อกและเวลาไว้ เพื่อให้การตรวจสอบภายหลังแยกการเปลี่ยนแปลงที่เสร็จสิ้นออกจากที่ตั้งใจไว้ สังเกตด้วยว่ารายการไม่ได้ทำอะไร มันไม่เพิกถอนผู้ออกใบรับรอง และไม่หยุดใบรับรองในอนาคตจากผู้นั้นไม่ให้ได้รับการยอมรับ การบล็อกใบรับรองโฮสต์กับการเปลี่ยนผู้ออกที่ถูกบุกรุกเป็นการดำเนินการต่างกันซึ่งมีผลต่างกัน

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

แจกจ่ายเหมือนการกำหนดค่าอื่น ๆ

มองรายการเป็นการกำหนดค่าที่มีกลไกการจัดส่ง ไม่ใช่ไฟล์ที่ใครแก้เมื่อนึกได้ ผลักรายการทั้งหมดแทนเดลตา เพื่อให้โฮสต์ที่พลาดการอัปเดตก่อนหน้ามาบรรจบกันแทนที่จะสะสมช่องว่าง เอกสาร PKI ของ Nebula แนะนำเช่นนั้น และคำแนะนำนี้ควรทำตามอย่างตรงตัวมากกว่าจะแปลงเป็นกระบวนการด้วยมือ

ยืนยันว่าบริการที่กำลังทำงานโหลดเนื้อหาใหม่แล้ว ไม่ใช่แค่ว่าไฟล์บนดิสก์เปลี่ยน ติดตามว่าเครื่องใดนำการเปลี่ยนแปลงไปใช้ และทำให้รายการที่ค้างอยู่มองเห็นได้จนกว่าจะว่าง แล็ปท็อปที่ปิดหนึ่งสัปดาห์คือเพียร์ที่ไม่เคยรู้การตัดสินใจ และอาจเชื่อมต่อใหม่จากเครือข่ายที่ไม่มีใครคาด บันทึกวิธีการจัดส่งไว้ข้างลายนิ้วมือ เพราะการเพิกถอนครั้งหน้าจะใช้มันซ้ำ และครั้งแรกคือที่ที่กระบวนการถูกแก้จุดบกพร่อง

รายการบล็อกหรือการหมุนผู้ออก

รายการบล็อกแคบ: ตัวตนหนึ่งหยุดทำงานและทุกอย่างยังดำเนินต่อ การหมุนผู้ออกใบรับรองกว้าง: ใบรับรองทุกใบที่ออกโดยผู้นั้นไม่น่าเชื่อถือ และทุกโฮสต์ต้องการข้อมูลรับรองใหม่และสมอความเชื่อถือใหม่ อย่างแรกคือการเพิกถอนแบบเจาะจง อย่างที่สองคือการย้ายระบบ จึงต้องมีการอนุมัติและหน้าต่างบำรุงรักษาที่ต่างกัน ตารางวางทั้งสองเคียงกันในด้านขอบเขต ความพยายาม และการย้อนกลับ

แล็ปท็อปที่หายต้องการรายการบล็อก เพราะรัศมีผลกระทบคือตัวตนเดียวและการเปลี่ยนแปลงย้อนกลับได้ถ้าคุณบล็อกลายนิ้วมือผิด กุญแจผู้ออกที่รั่วต้องการการหมุน เพราะรายการบล็อกช่วยกับใบรับรองที่ยังไม่ออกไม่ได้ ระหว่างสองขั้วนั้น ให้ถามว่าข้อมูลรับรองที่เปิดเผยอาจลงนามสิ่งอื่นได้หรือไม่ เพราะผู้ออกคือมากกว่าโฮสต์เดียว

เขียนการตัดสินใจไว้ก่อนเกิดเหตุ เพราะการเลือกภายใต้แรงกดดันมักให้ตัวเลือกที่กว้างกว่าโดยปริยาย ไม่ว่าคุณจะเลือกทางใด งานที่เหลือก็เหมือนกัน: พิสูจน์ว่าการบังคับใช้เกิดขึ้นบนโฮสต์ที่สำคัญ การบันทึกลายนิ้วมือและวันที่ในขณะนั้นคือสิ่งที่ทำให้การพิสูจน์เป็นไปได้ในภายหลัง

ตรวจสอบการปฏิเสธและส่วนที่เหลือ

เชื่อมต่อจากตัวตนที่ถูกบล็อกและยืนยันความล้มเหลว จากนั้นเชื่อมต่อจากเพียร์ที่ได้รับอนุญาตและยืนยันว่ายังเข้าถึงสิ่งที่ต้องการได้ การเปลี่ยนแปลงที่ทำให้ทุกคนพังไม่ใช่การเพิกถอนที่สำเร็จ ทำทั้งสองจากเซสชันใหม่ เพราะสถานะที่แคชไว้อาจซ่อนผลลัพธ์

ตรวจสอบว่าเซสชันที่ตั้งไว้สิ้นสุดหลังการเปลี่ยนแปลงหรือไม่ และบันทึกพฤติกรรมสำหรับเวอร์ชันและการกำหนดค่าของคุณ แทนที่จะถือว่าการแก้ไฟล์จะยุติอะไร disconnect_invalid ครอบคลุมไคลเอนต์ที่ใบรับรองหมดอายุหรือไม่ถูกต้อง ดังนั้นตรวจสอบว่ามันใช้กับกรณีของคุณอย่างไรก่อนพึ่งพา ถ้าการยุติทันทีเป็นข้อกำหนด ให้ทดสอบเรื่องนั้นโดยเฉพาะและบันทึกสิ่งที่คุณสังเกต จากนั้นทำการทดสอบซ้ำหลังรีสตาร์ท เพราะโฮสต์ที่บังคับใช้รายการเพียงจนถึงรีสตาร์ทครั้งถัดไปมีปัญหาการจัดส่งที่การทดสอบครั้งแรกซ่อนไว้ ประภาคารที่แข็งแรงบอกคุณว่าการค้นพบทำงาน ไม่ใช่ว่าเพียร์ใดนำนโยบายไปใช้