สอง LAN บน NetBird: เพียร์ใดกำหนดเส้นทาง และใครคุยได้
การลงทะเบียนไม่ได้กำหนดเส้นทางให้ LAN เลือกเพียร์กำหนดเส้นทางหนึ่งตัวต่อไซต์ คงการมาส์คไว้ จำกัดนโยบาย แล้วสอนเกตเวย์ LAN แต่ละตัวถึงฮอปถัดไป
เวิร์กสเตชันบน LAN ฝั่งตะวันตกเปิดเบราว์เซอร์ พิมพ์ที่อยู่ของแอปพลิเคชันบน LAN ฝั่งตะวันออก แล้วรอจนหมดเวลา ทุกหน้าจอของ NetBird บอกว่าเพียร์เชื่อมต่อกันแล้ว ซึ่งเป็นความจริงแต่ไม่ใช่ประเด็น: การอยู่ในเครือข่ายโอเวอร์เลย์หนึ่งเดียวไม่เหมือนกับการมีสองซับเน็ตภายในเครือข่ายเดียว เส้นทางด้านล่างเริ่มจากเวิร์กสเตชันนั้นและจบด้วยคำขอที่การออกแบบปฏิเสธโดยเจตนา และทุกจุดหยุดคือสิ่งที่อ่านได้จากอุปกรณ์ ไม่ใช่การเดา คาดว่าส่วนที่ขาดหายไปคือเส้นทางหรือนโยบาย ไม่ใช่โอเวอร์เลย์
อ่านความล้มเหลวจากเวิร์กสเตชันก่อน
ก่อนเปิดคอนโซลจัดการ ให้พิสูจน์ว่าเวิร์กสเตชันส่งอะไรจริง ๆ ตารางเส้นทางของมันเองตัดสินว่าแพ็กเก็ตไปที่เกตเวย์ของไซต์ ไปที่อินเทอร์เฟซภายใน หรือไม่ไปที่ไหนเลย และการตัดสินนั้นเห็นได้โดยไม่ต้องมีเครื่องมือโอเวอร์เลย์ใด ๆ เครื่องที่ไม่มีเส้นทางสำหรับคำนำหน้าปลายทางไกลจะล้มเหลว ไม่ว่ารายการเพียร์จะดูแข็งแรงเพียงใด ช่วงโอเวอร์เลย์และคำนำหน้าของไซต์เองเป็นพื้นที่ที่อยู่คนละแบบ และการลงทะเบียนกำหนดค่าไว้เพียงอย่างเดียว
จากนั้นแยกการแก้ชื่อออกจากการเข้าถึง เพราะเบราว์เซอร์รายงานทั้งสองอย่างเป็นการหมดเวลาเดียวกัน ทำคำขอซ้ำตามที่อยู่จากเครื่องที่รันไคลเอนต์ NetBird แล้วจากเวิร์กสเตชันธรรมดาที่ไม่รัน หากเครื่องที่ลงทะเบียนสำเร็จและเครื่องธรรมดาล้มเหลว ช่องว่างอยู่ที่การกำหนดเส้นทางภายใน หากทั้งสองล้มเหลว ให้อ่านต่อก่อนเปลี่ยนเส้นทาง
เลือกเพียร์กำหนดเส้นทางหนึ่งตัวต่อไซต์
เพียร์กำหนดเส้นทางคือโฮสต์ที่แทน LAN ของตนบนโอเวอร์เลย์ ดังนั้นเลือกเครื่อง Linux ที่เข้าถึงซับเน็ตได้อย่างเสถียร แทนที่จะเป็นเวิร์กสเตชันบนโต๊ะของใครบางคน ลงทะเบียนตามกระบวนการปกติและใส่ไว้ในกลุ่มที่ตั้งชื่อตามบทบาท เพราะทั้งทรัพยากรเครือข่ายและนโยบายจะอ้างถึงกลุ่มนั้น ตัวแทนหนึ่งตัวต่อไซต์ยังอ่านได้ง่าย แต่ฝูงอาสาสมัครที่ประกาศคำนำหน้าเดียวกันจะเปลี่ยนทุกคำถามหลังจากนั้นให้เป็นเซสชันแก้จุดบกพร่อง ที่อยู่ของเพียร์บนเซกเมนต์ภายในสำคัญพอ ๆ กับตัวตนบนโอเวอร์เลย์ เพราะที่อยู่นั้นกลายเป็นฮอปถัดไปที่บอกกับทุกอุปกรณ์ธรรมดา
เขียนแผนก่อนแตะคอนโซล เพราะชื่อและคำนำหน้าคือจุดที่การออกแบบเหล่านี้คลาดเคลื่อน: คำนำหน้า เกตเวย์ ที่อยู่เพียร์ และกลุ่ม ต่อไซต์ ตะวันตกคือ 10.52.0.0/24 ที่ให้บริการโดย 10.52.0.5 และตะวันออกคือ 10.63.0.0/24 ที่ให้บริการโดย 10.63.0.5 สองกลุ่มคือ west-routers และ east-routers และไม่มีคำนำหน้าใดทับซ้อนกับอีกอัน ช่วงโอเวอร์เลย์ หรือปลายทางที่กำหนดเส้นทางอื่น
สร้างทรัพยากรและคงการมาส์คไว้
ในแดชบอร์ดที่ติดตั้งแล้ว สร้างทรัพยากรเครือข่ายหนึ่งรายการต่อไซต์และแนบกลุ่มเพียร์กำหนดเส้นทางของไซต์นั้นเข้ากับมัน ทรัพยากรคือคำนำหน้าและกลุ่มคือโฮสต์ที่ตอบแทน และทั้งสองต้องมีอยู่ก่อนจะประกาศสิ่งใด ยืนยันว่าเวอร์ชันโฮสต์เองที่ติดตั้งแล้วมีเวิร์กโฟลว์เครือข่ายหรือไม่ เพราะอินเทอร์เฟซเก่าที่มีออบเจกต์เส้นทางชื่อคล้ายกันเป็นคุณสมบัติอีกอย่าง
ปล่อยให้การมาส์คเปิดอยู่ คู่มือไซต์ถึงไซต์ของ NetBird กำหนดให้ใช้ในการจัดวางนี้ และการปิดเพื่อให้ทุกที่อยู่เดิมมองเห็นได้ไม่ใช่การออกแบบเดียวกันที่ลดฮอปหนึ่งครั้ง แต่เปลี่ยนสิ่งที่การตรวจสอบต้นทางและนโยบายของโอเวอร์เลย์มองเห็น ผลที่ตามมาควรพูดตรง ๆ: บริการปลายทางบันทึกเพียร์กำหนดเส้นทางเป็นต้นทาง ไม่ใช่เวิร์กสเตชันรายตัว หากรายการอนุญาตหรือการตรวจสอบของบริการนั้นคาดหวังที่อยู่เวิร์กสเตชัน ก็ต้องเปลี่ยนความคาดหวังหรือบังคับตัวตนที่ขอบไซต์ก่อนการแปลง
ให้อำนาจผู้เริ่มต้น ไม่ใช่คำนำหน้า
เส้นทางทำให้ที่อยู่เข้าถึงได้ และนโยบายตัดสินว่าใครใช้ได้ ทั้งสองเป็นออบเจกต์แยกกันที่มีเจ้าของแยกกัน เขียนนโยบายย้อนจากภาระงาน: กลุ่มใดเริ่มต้น ทรัพยากรใดเป็นเป้าหมาย และบริการ TCP ใดที่ต้องใช้ เครือข่ายที่ประกาศทั้งสองคำนำหน้าให้ทุกเพียร์ที่ลงทะเบียนได้สร้างการเข้าถึงแต่ไม่ได้ตัดสินสิ่งใด
จากนั้นอ่านว่ายังอนุญาตอะไรอยู่แล้ว เพราะกฎใหม่ที่แคบไม่เพิกถอนกฎเก่าที่กว้างซึ่งอยู่เหนือมัน เมื่อตะวันออกต้องเริ่มการเชื่อมต่อไปตะวันตกด้วย ให้เขียนทิศทางนั้นเป็นนโยบายของตัวเอง ทราฟฟิกตอบกลับของเซสชันที่ตะวันตกเปิดเป็นคำถามคนละข้อกับการอนุญาตเซสชันใหม่ไปตะวันออก หากมีเพียงเวิร์กสเตชันตะวันตกบางตัวที่ต้องเข้าถึงแอปพลิเคชันตะวันออก ให้คัดเลือกที่ขอบไซต์ก่อนการแปลงและคงการยืนยันตัวตนของแอปพลิเคชันไว้ เพียร์กำหนดเส้นทางขนส่งทราฟฟิก LAN เป็นทั้งไซต์ ไม่ใช่ตัวตนโอเวอร์เลย์รายผู้ใช้ การบัญชีรายผู้ใช้จึงต้องมาจากที่อื่น
สอนเกตเวย์แต่ละตัวถึงฮอปถัดไป แล้วทดสอบการปฏิเสธ
อุปกรณ์ธรรมดาไม่เคยเห็นโอเวอร์เลย์ เกตเวย์ของพวกมันจึงต้องมีเส้นทางแบบคงที่ที่ชี้คำนำหน้าปลายทางไกลไปยังที่อยู่ LAN ของเพียร์กำหนดเส้นทาง นี่คือขั้นตอนที่ผู้คนข้ามไป เพราะทุกอย่างที่มองเห็นได้ใน NetBird ทำงานอยู่แล้วในขณะที่เวิร์กสเตชันธรรมดายังหมดเวลา เกตเวย์คงเส้นทางเริ่มต้นไว้เหมือนเดิม คำนำหน้านี้เป็นการเพิ่ม ไม่ใช่การแทนที่
คำอธิบายเส้นทางทั้งสองอยู่ในคอนฟิกเกตเวย์ของแต่ละไซต์ ไม่ใช่การเขียนทับบนโฮสต์ ทั้งสองเป็นเส้นทางคงที่ธรรมดา และไม่มีอันใดแตะเส้นทางเริ่มต้น:
west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5ทดสอบด้วยแอปพลิเคชันที่โครงการต้องการจริง จากเวิร์กสเตชันธรรมดา และบันทึกสามอย่าง: ฮอปถัดไปที่เลือกฝั่งส่ง นโยบายที่ตรงกัน และที่อยู่ต้นทางที่บริการบันทึก ทดสอบการปฏิเสธด้วย เพราะการออกแบบที่ไม่เคยปฏิเสธสิ่งใดมีขอบที่ไม่รู้จัก และการปฏิเสธเป็นหลักฐานเดียวว่านโยบายทำงาน ไม่ใช่การกำหนดเส้นทาง เมื่อตะวันออกต้องเริ่มต้นด้วย ให้เริ่มการเชื่อมต่อใหม่จากด้านนั้นแทนที่จะถือว่าทิศทางที่สองจะตามมา วางแผนการรีสตาร์ต อัปเกรด และเปลี่ยนเพียร์กำหนดเส้นทางด้วย เพราะโฮสต์หนึ่งตัวกลายเป็นสิ่งที่ไซต์พึ่งพิง
| Test | A pass looks like | A failure points at |
|---|---|---|
| Ordinary workstation opens the east application | Next hop on west is the routing peer | Missing static route on the west gateway |
| A source outside policy is refused | No session in the service log | Policy too broad, or a route bypasses it |
| East starts a connection, if required | A fresh reverse session succeeds | No policy for the reverse direction |
ชื่อส่วนตัวต้องมีการออกแบบตัวแก้ชื่อของตัวเอง เพราะการเข้าถึงไม่ได้สร้างระเบียน DNS และเส้นทาง IP ที่ทำงานได้แต่ชื่อเสียอ่านได้เหมือนเส้นทางที่เสียทุกประการ หากเพียร์กำหนดเส้นทางทำงานในเครือข่ายคลาวด์ ให้ตรวจสอบกฎการส่งต่อและไฟร์วอลล์ของผู้ให้บริการด้วย เพราะการลงทะเบียนไม่ได้ข้ามกฎเหล่านั้น เก็บข้อสังเกตจากการทดสอบไว้ข้างแผน เพราะคนถัดไปที่แก้ปัญหานี้จะต้องการนโยบายที่ตรงกันและที่อยู่ต้นทางที่บันทึกไว้ ไม่ใช่คำอธิบายโทโพโลยี