ให้โฮสต์ใน LAN มีเส้นทางกลับ VPN ด้วยตัวเลือก 121 ของ DHCP

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

ตั้งชื่อที่อยู่ทั้งสามก่อน

ยกตัวอย่าง LAN จริง: 192.168.50.0/24 โดยมีเราเตอร์เริ่มต้นปกติที่ 192.168.50.1 และเกตเวย์ VPN แยกต่างหากที่ 192.168.50.2 ไคลเอนต์ระยะไกลที่ผ่านการรับรองจะครอบครอง 10.90.0.0/24

เส้นทางที่ทุกโฮสต์ที่เข้าร่วมต้องมีคือ 10.90.0.0/24 via 192.168.50.2 ปลายทางคือพูลไคลเอนต์ และฮอปถัดไปคือที่อยู่ LAN ของเกตเวย์ ไม่ใช่ที่อยู่ทันเนลของมัน

เข้ารหัสเป็นเส้นทางคงที่แบบไม่มีคลาส

ตัวเลือก 121 บรรทุกคู่ของพรีฟิกซ์และฮอปถัดไป และ RFC 3442 กำหนดทั้งการเข้ารหัสและพฤติกรรมไคลเอนต์ที่ตามมา สำหรับอินสแตนซ์ dnsmasq ที่มีอยู่ซึ่งให้บริการเฉพาะ LAN ตัวอย่างนี้ รูปแบบของคอนฟิกคือ:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

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

อย่าทำเส้นทางเริ่มต้นหาย

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

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

ตรวจสอบว่าไคลเอนต์จะยอมรับอะไร

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

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

ตรวจสอบสัญญาเช่า แล้วจึงตรวจสอบการค้นหา

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

บนไคลเอนต์ Linux ให้อ่านเส้นทางจริงและยืนยันทั้งสองรายการ:

ip -4 route
ip -4 route get 10.90.0.23

การค้นหาตามบริบทควรแสดงเส้นทางของพูลผ่าน 192.168.50.2 และค่าเริ่มต้นผ่าน 192.168.50.1 หากค่าเริ่มต้นหายไป แสดงว่าคุณจำลองกับดักข้างต้นแล้ว

จากนั้นทดสอบการแลกเปลี่ยนจริง

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

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