อะแดปเตอร์ VPN แสดง /32 ไม่ได้หมายความว่ามีปลายทางเดียว

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

ตำนาน: มาสก์โฮสต์หมายถึงโฮสต์เดียวที่เข้าถึงได้

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

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

อ่านที่อยู่และเส้นทางเป็นวัตถุแยกจากกัน

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

ip addr show tun0
ip route show
ip route get 10.60.5.10

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

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

หยุดถ้าการค้นหาชี้ไปที่อินเทอร์เฟซผิด นี่คือปัญหาเส้นทางของไคลเอนต์ และแก้ไขที่ไคลเอนต์

ทำไมการขยายมาสก์จึงมักทำให้แย่ลง

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

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

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

เมื่อเส้นทางถูกต้องแต่การไหลยังล้มเหลว

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

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

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

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