VPN แบบกำหนดเส้นทางหรือ LAN แบบบริดจ์สำหรับลิงก์ระหว่างสาขากับห้องแล็บ

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

สองวิธีเชื่อมต่อ หนึ่งการแลกเปลี่ยนที่ชัดเจน

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

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

การกำหนดเส้นทางให้อะไรคุณ

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

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

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

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

ต้นทุนของการบริดจ์

การบริดจ์ต้อง ขนส่งเฟรมเลเยอร์ 2 ผ่านอุโมงค์ ซึ่งหมายถึงการห่อหุ้มเช่น GRE หรือ VXLAN บน IPsec แทนอุโมงค์แบบอิงนโยบายธรรมดา เมื่อมีสิ่งนี้ ทั้งสองไซต์ใช้โดเมนความล้มเหลวร่วมกัน Spanning tree มองอุโมงค์เป็นลิงก์ ทราฟฟิกการออกอากาศกินแบนด์วิดท์ของอุโมงค์ และอุปกรณ์ใดที่ถือว่าเซกเมนต์มีความหน่วงต่ำจะทำงานผิดพลาดในลักษณะที่ยากต่อการระบุจากปลายทางใด

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

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

ชื่อโดยไม่มีการออกอากาศ

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

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

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

ทำให้การออกแบบที่กำหนดเส้นทางทดสอบได้

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

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

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