ที่อยู่ L2TP นั้นคือ IPCP ไม่ใช่สัญญาเช่า DHCP บน LAN

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

สองที่อยู่ในหนึ่งการเชื่อมต่อ

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

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

IPCP ทำอะไรกันแน่

IPCP คือโปรโตคอลควบคุม IPv4 สำหรับ PPP แต่ละฝ่ายส่งข้อความ Configure-Request ที่อธิบายตัวเลือกที่ต้องการ และตัวเลือกที่อยู่เป็นหนึ่งในนั้น ไคลเอนต์ที่ยังไม่มีที่อยู่มักถามด้วย 0.0.0.0 และเซิร์ฟเวอร์ตอบด้วย Configure-Nak ที่บรรทุกที่อยู่ซึ่งต้องการให้ไคลเอนต์ใช้ จากนั้นไคลเอนต์ขอที่อยู่นั้น และเซสชันขึ้นมาพร้อมที่อยู่ท้องถิ่นและที่อยู่ระยะไกล

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

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

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

ทำไม LAN ตอบกลับคุณไม่ได้

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

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

ตรวจสอบเซสชันก่อน แล้วจึงตรวจเส้นทาง

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

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

แยกสามขั้นตอนออกจากกัน

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

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