พูล VPN ของคุณไม่ใช่ช่วง DHCP ของ LAN: ทำไมมันพัง

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

ผู้จัดสรรสองราย พื้นที่ที่อยู่เดียว

เซิร์ฟเวอร์ DHCP ของ LAN รู้ว่าให้เช่าที่อยู่ใดแก่ MAC ใด และป้องกันด้วย ARP ส่วนเซิร์ฟเวอร์ VPN มีพูลของตัวเองและไม่รู้อะไรเกี่ยวกับสัญญาเช่าเหล่านั้น ทั้งสองฝ่ายไม่ได้ผิด เพียงแต่ไม่เคยถูกแนะนำให้รู้จักกัน

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

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

ทำไมเราเตอร์ไม่แจกที่อยู่ VPN

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

ดังนั้นเซิร์ฟเวอร์ VPN จึงกำหนดที่อยู่เอง: พูลในการตั้งค่าเซิร์ฟเวอร์, ที่อยู่ต่อเพียร์ในการตั้งค่า WireGuard หรือที่อยู่ที่ชั้นการพิสูจน์ตัวตนผลักออกมาในการติดตั้ง IKEv2 กลไกเหล่านี้เป็นอิสระจากฐานข้อมูลสัญญาเช่าของ LAN และนั่นคือเหตุผลที่ต้องมีช่วงของตัวเอง

เหตุผลเดียวกันอธิบายว่าทำไมการเปลี่ยนขอบเขต DHCP ไม่แก้ไขไคลเอนต์ VPN ที่ไม่เคยได้รับที่อยู่ ไคลเอนต์ไม่ได้ถามเซิร์ฟเวอร์ LAN และไม่มีการแก้ไขขอบเขตใดทำให้มันถาม

การทับซ้อนปรากฏเป็นความขัดแย้ง ไม่ใช่เครือข่ายที่ช้า

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

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

เส้นทางย้อนกลับเป็นปัญหาอีกเรื่อง

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

อ่านเส้นทางทั้งสองทิศทางก่อนเปลี่ยนแปลงสิ่งใด บนเกตเวย์ให้ถามว่าเคอร์เนลจะใช้อินเทอร์เฟซใดสำหรับที่อยู่ไคลเอนต์ บนไคลเอนต์ให้ถามว่าใช้เส้นทางใดสำหรับที่อยู่ใน LAN

คำสั่งเหล่านี้แสดงการตัดสินใจส่งต่อบนเกตเวย์และรายการเพื่อนบ้านที่เผยให้เห็นรายการซ้ำ:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

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

มีการออกแบบแบบบริดจ์อยู่ แต่ต้องเลือกใช้

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

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

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