ที่อยู่ VPN กับการเช่า DHCP ใน LAN: ใครเป็นผู้กำหนด IP ของอุโมงค์

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

บนไคลเอนต์ทุกอย่างดูเหมือนกันหมด: ที่อยู่ IPv4 หนึ่งที่อยู่ มาสก์หนึ่งอัน บางครั้งมีเกตเวย์เริ่มต้น ความแตกต่างจะปรากฏก็ต่อเมื่อคุณถามว่าใครตอบแทนที่อยู่นั้นและใครเก็บบันทึกไว้

อ่านที่อยู่ของอุโมงค์จากฝั่งไคลเอนต์

Windows จะแสดงความแตกต่างหากคุณอ่านทั้งบล็อกไม่ใช่แค่บรรทัดแรก ipconfig /all พิมพ์คำอธิบายอะแดปเตอร์ ที่อยู่ทางกายภาพ และบรรทัด DHCP อะแดปเตอร์ Dial-up แบบ PPP หรือ IKEv2 มักรายงานว่า DHCP ถูกปิดใช้งาน เพราะการเชื่อมต่อได้เจรจาที่อยู่ของตนระหว่างการ dial-up แทนที่จะเช่าจากเซิร์ฟเวอร์ใน LAN อะแดปเตอร์อุโมงค์ที่เปิด DHCP ไว้นั้นพบได้น้อยและควรค่าแก่การตรวจสอบแยกต่างหาก

Linux แบ่งข้อมูลเดียวกันออกเป็นสองเครื่องมือ ip -4 addr show dev tun0 ให้ที่อยู่และความยาวพรีฟิกซ์ nmcli -f IP4 connection show work เผยว่าค่านั้นมาจากโปรไฟล์การเชื่อมต่อ จากการแลกเปลี่ยน DHCP บนลิงก์ หรือจากการกำหนดค่าที่ถูกส่งมา WireGuard เป็นกรณีที่ชัดที่สุด เพราะ wg-quick ใช้บรรทัด Address จากไฟล์กำหนดค่าเมื่ออินเทอร์เฟซปรากฏขึ้น และไม่มีเพียร์ใดจัดสรรสิ่งใดในเวลาที่เชื่อมต่อ

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

เพย์โหลดการกำหนดค่า IKEv2 บรรจุอะไร

IKEv2 มีกลไกเฉพาะสำหรับงานนี้ เพย์โหลดการกำหนดค่าที่อธิบายใน RFC 7296 หัวข้อ 3.15.1 บรรจุแอตทริบิวต์อย่าง INTERNAL_IP4_ADDRESS INTERNAL_IP4_NETMASK INTERNAL_IP4_DNS และคู่เทียบ IPv6 ของมัน ไคลเอนต์ส่งแอตทริบิวต์ที่มีค่าความยาวศูนย์เมื่อไม่มีความต้องการ และผู้ตอบจะส่งคืนค่าที่ต้องการให้ใช้ การแลกเปลี่ยนนั้นเดินทางภายใน IKE_AUTH ซึ่งเข้ารหัสไว้แล้ว ดังนั้นการออกอากาศ DHCP จะไม่ข้ามอุโมงค์เลย

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

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

จุดที่ขอบเขต DHCP ของ LAN กับพูล VPN ชนกัน

ปัญหาเริ่มเมื่อผู้จัดสรรทั้งสองชี้ไปที่ช่วงเดียวกัน เซิร์ฟเวอร์ DHCP สำหรับ 10.20.30.0/24 ไม่รู้อะไรเลยเกี่ยวกับพูล VPN ที่กำหนดค่าไว้สำหรับ 10.20.30.128/25 ดังนั้นจึงไม่มีอะไรหยุดมันไม่ให้ให้ 10.20.30.140 แก่เครื่องพิมพ์ ขณะที่เกตเวย์มอบที่อยู่เดียวกันให้ไคลเอนต์ระยะไกล การชนกันเงียบอยู่นานหลายวันแล้วจึงปรากฏเป็นการซ้ำเป็นครั้งคราว

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

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

ตรวจสอบว่ากระบวนการใดเป็นเจ้าของที่อยู่

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

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

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

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