ไม่มีอินเทอร์เน็ตบน VPN ของ Windows? ตัวน่าสงสัยคือพูลแอดเดรส

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

อ่านลีสก่อนเปลี่ยน

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

สามรูปแบบตรงกับสามความผิดพลาด แอดเดรสในช่วง 169.254.0.0/16 หมายความว่าไคลเอนต์ไม่ได้รับอะไรเลยและตั้งแอดเดรสลิงก์โลคอลให้ตัวเอง แอดเดรสที่ดูสมเหตุสมผลแต่ไม่มีเกตเวย์หมายความว่าพูลถูกให้บริการโดยไม่มีออปชันที่ให้เส้นทางเริ่มต้นแก่ไคลเอนต์ ลีสที่สมบูรณ์แต่ยังไปไม่ถึงไหนบ่งชี้การส่งต่อหรือการแปลที่ฝั่งเซิร์ฟเวอร์

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

ทำไมการกำหนดอัตโนมัติจึงอาจทิ้งไว้โดยไม่มีเกตเวย์

รายการ Incoming Connections มีคุณสมบัติ IPv4 ของตัวเอง แยกจากอะแดปเตอร์จริง ค่าเริ่มต้นตรงนั้นเสนอให้กำหนดแอดเดรสอัตโนมัติ ซึ่งพึ่งพาตัวจัดสรรในตัวของการเชื่อมต่อเพื่อให้แอดเดรส มาสก์ เกตเวย์ และ DNS

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

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

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

ตั้งช่วงที่ชัดเจนซึ่งเซิร์ฟเวอร์เราเตอร์ได้

เลือกบล็อกเล็กๆ ภายในซับเน็ตที่เซิร์ฟเวอร์เข้าถึงได้ นอกช่วงที่เราเตอร์ LAN แจก และนอกพูลอื่นใดในเครือข่าย ถ้าเซิร์ฟเวอร์อยู่บน 172.20.10.0/24 และเราเตอร์ถือ 172.20.10.1 บล็อกสั้นๆ ใกล้ด้านบนของซับเน็ตนั้น เช่น 172.20.10.201 ถึง 172.20.10.209 จะทำให้ลีสของทันเนลห่างจากการแจกที่เราเตอร์จัดการอยู่แล้ว

ป้อนในคุณสมบัติ IPv4 ของ Incoming Connection เชื่อมต่อไคลเอนต์ใหม่ แล้วอ่านอะแดปเตอร์อีกครั้งก่อนเปลี่ยนอย่างอื่น การอ่านครั้งที่สองคือสิ่งที่บอกว่าพูลเป็นความผิดพลาดหรือเป็นเพียงหนึ่งในหลายๆ

คำสั่งเหล่านี้พิมพ์การกำหนดค่าที่ได้และเส้นทางที่ไคลเอนต์มีตอนนี้:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

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

แอดเดรสไม่ใช่เส้นทางอินเทอร์เน็ต

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

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

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

ตัดเส้นทางภายนอกออกก่อน

ไม่มีพูลใดช่วยได้ถ้าทันเนลไม่เคยเกิดขึ้น โปรโตคอลกำหนดว่าเส้นทางต้องพาอะไร: PPTP ต้องการ TCP 1723 และ GRE ซึ่งเป็นโปรโตคอล IP 47 ไม่ใช่พอร์ต L2TP/IPsec ต้องการ UDP 1701 พร้อม 500 และ 4500 SSTP ต้องการ TCP 443

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

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