เชื่อมต่อ VPN อยู่แต่เข้าถึงเครือข่ายภายในไม่ได้? สี่จุดที่ต้องตรวจ

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

ข้อแรก ดูตารางเส้นทางที่ไคลเอนต์ติดตั้งไว้

เปิดตารางเส้นทางของไคลเอนต์ขณะที่ VPN เชื่อมต่ออยู่ บน Linux ใช้ ip route บน Windows ใช้ route print หรือ Get-NetRoute และบน macOS ใช้ netstat -rn คุณกำลังมองหาเส้นทางเริ่มต้นที่ผ่านอุโมงค์ และสิ่งที่เกิดขึ้นกับเส้นทางเริ่มต้นจริง

ไคลเอนต์แบบอุโมงค์เต็มมักเพิ่มเส้นทางครึ่งเริ่มต้นสองเส้น คือ 0.0.0.0/1 และ 128.0.0.0/1 แทนการแทนที่ 0.0.0.0/0 เส้นทางเริ่มต้นเดิมยังมองเห็นได้แต่แพ้ทุกการค้นหา นั่นคือเหตุผลที่ตารางอาจดูสมบูรณ์ทั้งที่ทราฟฟิกทั้งหมดนอกซับเน็ตย้ายไป ถ้าไคลเอนต์ VPN มีตัวเลือกอุโมงค์แยกและนโยบายอนุญาต นั่นคือการซ่อมที่สะอาดที่สุด

ถ้าอุโมงค์ต้องเป็นเส้นทางเริ่มต้นต่อไป ให้ตรึงซับเน็ตภายในแทน บน Linux เส้นทางระบุอินเทอร์เฟซจริงและเกตเวย์ บน Windows ให้เพิ่ม -p เพื่อให้คงอยู่ถาวร และอ่านหมายเลขอินเทอร์เฟซจาก route print แทนการเดา:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

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

ข้อสอง ยืนยันว่าที่อยู่นั้นเป็นภายในตั้งแต่แรก

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

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

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

ข้อสาม ดูว่าตอนนี้ใครตอบชื่อ

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

บน Linux resolvectl query nas.local แสดงว่าตัวแปลงชื่อใดตอบ บน Windows nslookup nas.local ระบุเซิร์ฟเวอร์ และ ipconfig /all แสดงลำดับของตัวแปลงชื่อ ถ้าคำต่อท้ายภายในถูกจัดการโดยตัวแปลงชื่อขององค์กรแล้ว ให้ส่งคำต่อท้ายนั้นกลับไปยังตัวแปลงชื่อภายใน หรือใช้ที่อยู่ IP สำหรับอุปกรณ์

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

ข้อสี่ ตรวจว่าเครื่องอีกเครื่องหนึ่งอยู่ใน VPN ด้วยหรือไม่

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

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

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

ใช้การซ่อมที่ตรงกับจุดตรวจที่ล้มเหลว

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

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

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