Nebula: ตั้งค่า relay แล้วแต่ไม่ได้ใช้ — สามค่าที่ต้องตรวจ

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

ทำแผนที่สามบทบาทก่อนแก้ไขไฟล์กำหนดค่า

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

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

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

ยืนยันว่าแต่ละโฮสต์โหลดไฟล์กำหนดค่าใดจริง ๆ ก่อนแก้ไขอย่างอื่น หน่วยที่อ่านเส้นทางอื่นจากไฟล์ที่คุณแก้ไขเป็นสาเหตุทั่วไปและน่าอายของข้อความ 'การเปลี่ยนแปลงไม่ได้ทำอะไรเลย':

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

บรรทัดเวอร์ชันสำคัญในฝูงเครื่องแบบผสม การจัดการ relay พฤติกรรมการเจาะ และคีย์กำหนดค่าที่รับได้ไม่เหมือนกันในแต่ละรุ่น ดังนั้นอย่าถือว่ารุ่นเก่าเข้าใจส่วนที่ไม่ได้เขียนไว้สำหรับมัน ปรับโฮสต์ให้อยู่ในซีรีส์ minor เดียวกัน จากนั้นรัน nebula -test -config /etc/nebula/config.yml บนทุกโฮสต์และเปรียบเทียบผลลัพธ์ก่อนแก้ปัญหาการรับส่งที่โค้ดไม่ได้รองรับ

เปิดบทบาทส่งต่อบนโฮสต์ relay

บทบาท relay คือแฟล็กเดียวบนโฮสต์ส่งต่อ และแยกจากบทบาทประภาคาร โฮสต์ที่เปิดการค้นพบแต่ปิดการส่งต่อผ่าน relay ยังคงเป็นเพียงบริการค้นพบ บน relay:

relay:
  am_relay: true

แฟล็กนี้ประกาศเจตนา แต่ไม่ได้สร้างการเข้าถึง relay ต้องเข้าถึงได้จาก peer ทั้งสอง ซึ่งในทางปฏิบัติหมายถึงที่อยู่สาธารณะ UDP ขาเข้าบนพอร์ต Nebula ที่เปิดในไฟร์วอลล์ของโฮสต์และในกลุ่มความปลอดภัยของคลาวด์ใด ๆ และไม่มี NAT ซ้อนสองชั้นอยู่ข้างหน้า ตรวจซ็อกเก็ตที่รอรับ แล้วเฝ้าดูแพ็กเก็ตของ peer ที่มาถึง:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

ประกาศ relay จากฝั่งปลายทาง ไม่ใช่จากไคลเอนต์

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

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

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

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

อนุญาตให้ peer ที่เชื่อมต่อใช้ relay

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

relay:
  use_relays: true

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

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

ตรวจสอบกับคู่ที่ล้มเหลว แล้วโหลดใหม่

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

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

โหลดใหม่แทนการรีสตาร์ต และยืนยันว่ากระบวนการที่กำลังทำงานรับไฟล์ที่คุณแก้ไขแล้ว การรีสตาร์ตตัดทุกอุโมงค์และทำให้การทดสอบครั้งถัดไปอ่านยากขึ้น ขณะที่ SIGHUP รักษากระบวนการไว้และบังคับให้อ่านค่ากำหนดใหม่:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload ทำงานเฉพาะเมื่อยูนิตภายในเครื่องกำหนด ExecReload และยูนิตที่มาพร้อมโปรเจกต์ไม่ได้กำหนดไว้ ดังนั้นขั้นที่สำเร็จในการติดตั้งมาตรฐานคือ systemctl kill -s HUP หลังโหลดใหม่ ให้อ่านบันทึกสำหรับเส้นทางไฟล์กำหนดค่าที่กระบวนการเปิด เพื่อให้รู้ว่าไฟล์ใหม่ถูกอ่าน ไม่ใช่ไฟล์ที่คุณคิดไว้

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

จากนั้นยืนยันว่าคำประกาศแต่ละข้ออยู่ในไฟล์ที่มันเป็นเจ้าของ:

• am_relay: true บนโฮสต์ส่งต่อ และโฮสต์นั้นเข้าถึงได้ด้วย UDP จากทั้งสองฝั่ง
• relays: ที่ระบุที่อยู่ Nebula ของโฮสต์นั้นบนปลายทาง
• use_relays: true บน peer ที่เริ่มการเชื่อมต่อ
• กฎขาเข้าบนปลายทางยังอนุญาตต้นทางจริงหลังจากเส้นทางเปลี่ยน