VPN บล็อก LAN ภายในบน Windows: เส้นทางหรือนโยบายไคลเอนต์?
การเข้าถึง LAN ภายในบน Windows แตกได้จากสองสาเหตุที่ต่างกัน: เส้นทางที่หายไป หรือนโยบายเกตเวย์ที่ทิ้งซับเน็ต สามการตรวจบอกว่าอันไหน
เครื่องพิมพ์ NAS หรือเครื่องพัฒนาบนโต๊ะของคุณเองหยุดตอบสนองในวินาทีที่ VPN ของงานเชื่อมต่อ บางครั้งคำสั่งเส้นทางเดียวแก้ได้ในไม่กี่วินาที บางครั้งเส้นทางเดิมถูกต้องแต่แพ็กเก็ตยังหายไป ซึ่งหมายความว่าคุณกำลังดูปัญหาอื่นที่มีอาการคล้ายกัน การตัดสินใจลงเอยที่สามคำถาม และการถามผิดลำดับคือเหตุผลที่ผู้คนใช้เวลาทั้งเย็นลบและเพิ่มเส้นทางซ้ำ
สามคำถามก่อนคำสั่งใด ๆ
ข้อแรก มีรายการสำหรับคำนำหน้าท้องถิ่นหรือไม่ และชี้ไปที่อะแดปเตอร์กายภาพหรือไม่ ข้อสอง ไคลเอนต์ได้รับอนุญาตหรือถูกปฏิเสธเครือข่ายท้องถิ่นจากเกตเวย์ตอนเชื่อมต่อหรือไม่ ข้อสาม คุณต้องการเพียงการเข้าถึงขาออกไปยัง LAN หรือมีบางอย่างบนอินเทอร์เน็ตต้องไปถึงบริการที่รันบนเครื่องของคุณด้วย
คำถามแรกแยกความผิดพลาดของการกำหนดเส้นทางออกจากความผิดพลาดของการกรอง คำถามที่สองบอกว่าการแก้เส้นทางได้รับอนุญาตให้ทำงานหรือไม่ คำถามที่สามเปลี่ยนการซ่อม: เส้นทางแก้การรับส่งขาออก ขณะที่บริการขาเข้าที่เข้าถึงไม่ได้มักเป็นปัญหาการผูกตัวรับฟังและเส้นทางกลับซึ่งเส้นทางทำให้แย่ลง
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
คำถามหนึ่ง: เส้นทาง ตัวกรอง หรือชื่อ
อ่านตารางก่อนเพิ่มอะไรลงไป ดัชนีอินเทอร์เฟซสำคัญ เพราะทุกคำสั่งเส้นทางด้านล่างผูกกับมัน:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricซับเน็ตที่เชื่อมต่อโดยตรงมักคงเส้นทาง on-link ไว้แม้ทันเนลจะขึ้น ดังนั้นรายการอาจมีอยู่และการรับส่งยังล้มเหลวได้ การรวมกันนั้นคือลายเซ็นของตัวกรองที่ทำงานหลังการกำหนดเส้นทาง และเป็นกรณีที่เส้นทางที่สองซึ่งเฉพาะเจาะจงกว่าจะไม่เปลี่ยนอะไรเลย
ทดสอบแยกตามที่อยู่และตามชื่อ หาก ping 192.168.1.50 ตอบและ net view 192.168.1.50 ไม่ตอบ ตารางกำหนดเส้นทางไม่เคยเป็นปัญหา ทันเนลเปลี่ยนตัวแก้ชื่อและชื่อท้องถิ่นไม่ถูกแก้แล้ว การเพิ่มเส้นทางเพื่อสิ่งนั้นเป็นงานเปล่า
คำถามสอง: เกตเวย์อนุญาตให้เข้าถึง LAN ภายในหรือไม่
ไคลเอนต์เชิงพาณิชย์ติดตั้งมากกว่าเส้นทาง มันได้รับนโยบายตอนเชื่อมต่อ และนโยบายนั้นอาจมีการอนุญาตเครือข่ายท้องถิ่นอย่างชัดเจน ในการติดตั้ง Cisco IPsec นโยบายกลุ่มมีทั้งการตั้งค่า split-tunneling และแฟล็กแยกสำหรับการเข้าถึง LAN ภายใน กล่องทำเครื่องหมายในไคลเอนต์เป็นคำขอที่เกตเวย์อาจปฏิเสธ ใน AnyConnect โปรไฟล์ควบคุมรายการรวมและยกเว้นของ split และการอนุญาตเดียวกัน บน Windows RRAS สิ่งที่เทียบเท่าคือตัวเลือกเกตเวย์เริ่มต้นในโปรไฟล์บวกเส้นทางสถิติที่เซิร์ฟเวอร์กำหนด
เมื่อแฟล็กปิด พฤติกรรมที่บันทึกไว้คือไคลเอนต์บล็อกการรับส่งไปยังซับเน็ตที่เชื่อมต่อโดยตรงแม้มีเส้นทางที่ถูกต้องและเฉพาะเจาะจงกว่าอยู่ นั่นคือเหตุผลที่เส้นทางที่ไคลเอนต์ไม่ได้เป็นเจ้าของอาจหายไปไม่กี่วินาทีหลังคุณเพิ่ม ไคลเอนต์กำลังสร้างสถานะที่ถูกสั่งให้สร้างใหม่ ไม่ได้ต่อสู้กับคุณ
บันทึกของไคลเอนต์บันทึกการตัดสินใจตอนเชื่อมต่อ และการอ่านมันเร็วกว่าการทดลองใดบนเครื่อง หากบันทึกบอกว่าการเข้าถึงท้องถิ่นถูกบล็อก ให้หยุด ไม่มีการแก้ด้วยบรรทัดคำสั่งใดรอดพ้นสิ่งนั้น และทางที่เหลือคือการเปลี่ยนนโยบาย การเข้าถึงทรัพยากรผ่านทันเนล หรือการกักไคลเอนต์ไว้ในเครื่องเสมือนและปล่อยโฮสต์ไว้บนเครือข่ายท้องถิ่น
คำถามสาม: คุณต้องการทิศทางใด
การรับส่งขาออกไปยังอุปกรณ์ใกล้เคียงเป็นคำถามเรื่องการกำหนดเส้นทาง ชี้คำนำหน้า LAN ไปที่เกตเวย์ท้องถิ่นด้วยเมตริกที่ต่ำพอจะชนะเส้นทางเริ่มต้นของทันเนล:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pรูปแบบที่สองตรึงอุปกรณ์เดียว ซึ่งเป็นสิ่งที่คุณต้องการเมื่อที่อยู่เดียวคือความต้องการทั้งหมด netsh ที่เทียบเท่าบันทึกการตัดสินใจเดียวกันด้วยชื่ออินเทอร์เฟซแทนดัชนี:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentคำสั่งเส้นทางล้มเหลวด้วย พารามิเตอร์ไม่ถูกต้อง เมื่อที่อยู่และมาสก์ไม่ตรงกัน เช่น ที่อยู่โฮสต์ที่มีมาสก์ /24 ใช้ที่อยู่เครือข่ายสำหรับเส้นทางซับเน็ตและมาสก์โฮสต์สำหรับโฮสต์เดียว
ขาเข้าแตกต่างออกไป เซิร์ฟเวอร์ VNC หรือ SSH บนเครื่องเดียวกันจะเข้าถึงไม่ได้เมื่อคำตอบของการเชื่อมต่อขาเข้าออกจากเกตเวย์ VPN และไม่เคยกลับมา ตรวจสอบว่าบริการฟังอะไรอยู่ก่อนแตะเส้นทาง:
netstat -ano | findstr :5900ตัวรับฟังที่ผูกกับที่อยู่เฉพาะหนึ่งจะไม่ตอบบนอินเทอร์เฟซอีกอัน การผูกกับทุกอินเทอร์เฟซเป็นการตัดสินใจโดยเจตนา ทำร่วมกับกฎไฟร์วอลล์ที่จำกัดเฉพาะเครือข่ายที่คุณไว้ใจ หลังจากนั้นการซ่อมเส้นทางจึงคืนเส้นทางกลับ
ใช้การเปลี่ยนแปลงที่เล็กที่สุดที่เข้ากัน
อีกการเคลื่อนไหวที่พบบ่อยคือยกเลิกทำเครื่องหมาย “ใช้เกตเวย์เริ่มต้นบนเครือข่ายระยะไกล” ในคุณสมบัติขั้นสูงของ IPv4 ซึ่งรักษาการรับส่งอินเทอร์เน็ตให้อยู่ท้องถิ่น แต่ทำสองอย่างพร้อมกัน: VPN หยุดเป็นเส้นทางเริ่มต้น และไคลเอนต์หยุดรับเส้นทางสำหรับเครือข่ายระยะไกลรวมถึง multicast ยกเลิกแล้ว LAN ระยะไกลจะหายไปเว้นแต่เซิร์ฟเวอร์จะดันคำนำหน้าระยะไกลเฉพาะที่ไคลเอนต์ทุกตัวต้องการ
ความไม่สมมาตรนั้นกำหนดลำดับงาน หากฝั่งระยะไกลต้องเข้าถึงได้เต็มที่ ให้ดันซับเน็ตระยะไกลจากเซิร์ฟเวอร์และปล่อยค่าเริ่มต้นท้องถิ่นไว้ หากเปลี่ยนเซิร์ฟเวอร์ไม่ได้ ให้เพิ่มเส้นทางถาวรไปยังคำนำหน้าระยะไกลผ่านที่อยู่ที่ทันเนลกำหนด และตรวจด้วย route print ว่าคำนำหน้าชี้ไปที่อินเทอร์เฟซ VPN ขณะที่ค่าเริ่มต้นยังชี้ไปที่เกตเวย์กายภาพ
จากนั้นยืนยันว่าการซ่อมอยู่รอดหลังเชื่อมต่อใหม่ เพราะเส้นทางที่ไม่ถาวรตายไปกับอะแดปเตอร์ และสคริปต์ที่รันหลังการเชื่อมต่อทุกครั้งคือที่ที่ซื่อสัตย์สำหรับมัน ทดสอบอุปกรณ์ท้องถิ่นหนึ่งและทรัพยากรระยะไกลหนึ่งในเซสชันเดียวกัน ตัดการเชื่อมต่อ เชื่อมต่อใหม่ และทดสอบอีกครั้ง หากอุปกรณ์ท้องถิ่นยังล้มเหลวขณะเส้นทางดูถูกต้อง ให้กลับไปที่คำถามสอง: ไคลเอนต์กำลังกรอง และคำตอบคือการเปลี่ยนนโยบายไม่ใช่เส้นทางที่สองที่แข่งขัน