Nebula static_host_map: ที่อยู่ที่ประภาคารให้ไม่ได้

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

สองที่อยู่กับสองหน้าที่

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

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

อัตลักษณ์ไปที่ที่คาดหวังอัตลักษณ์ ความเข้าถึงได้ไปในแผนที่

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

โครงสร้างของรายการในแผนที่

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

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

พอร์ตผิดให้ความเงียบแทนข้อผิดพลาด เพราะ UDP ไม่มีการจับมือให้ปฏิเสธ ดังนั้นรูปแบบรายการจึงควรตรวจกับ เอกสารอ้างอิง static_host_map ของ Nebula ไม่ใช่ความจำ เอกสารอ้างอิงยังครอบคลุมรายการปลายทางและพฤติกรรมการรีเฟรช DNS

การบูตสแตรปต้องทำงานก่อน overlay

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

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

รายการแบบคงถูกหมุนหมายโดยตรงและไม่เคยถามประภาคาร นี่คือเหตุที่ความล้มเหลวตรงนี้ดูเหมือนการหมดเวลาปกติโดยไม่มีเพียร์เกี่ยวข้อง

เกิดอะไรขึ้นหลังแฮนด์เชกครั้งแรก

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

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

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

เมื่อการค้นหาทำงานแต่เพียร์ตัวหนึ่งไม่

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

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

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