ไคลเอนต์ VPN เชื่อมต่อและได้รับที่อยู่ แต่โฮสต์ใน LAN ที่มันต้องการยังคงตอบกลับไม่ได้ ใน Windows Routing and Remote Access ที่อยู่ภายในของไคลเอนต์ VPN มาจากพูลที่กำหนดค่าแยกจากอะแดปเตอร์ LAN ของเซิร์ฟเวอร์ และฝั่ง LAN จำเป็นต้องมีเส้นทางกลับไปยังพูลนั้น มีสองการเปลี่ยนแปลงไม่ใช่หนึ่ง และล้มเหลวต่างกันไป ทำงานตามลำดับเพื่อให้แผนที่อยู่และเส้นทางกลับได้รับการพิสูจน์ก่อนเลิกใช้ช่วงเดิม

จองช่วงที่อยู่ก่อนเปิดคอนโซล

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

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

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

การเปลี่ยนวิธีการไม่ใช่การเพิ่มช่วง

RRAS มีวิธีการกำหนดและชุดของช่วง การย้ายจาก DHCP ไปยังพูลแบบคงที่ คือการเปลี่ยนวิธีการ การเพิ่มบล็อกอีกอันขณะที่พูลแบบคงที่ทำงานอยู่แล้วคือการเปลี่ยนช่วง

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

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

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

Get-VpnIPAddressRange

วิธีการ DHCP ที่มีรายการช่วงว่างหมายความว่าตัวอย่างแรกมีผล พูลที่อยู่แบบคงที่ที่มีช่วงอยู่แล้วหมายความว่าตัวอย่างที่สองมีผล

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

LAN จำเป็นต้องมีเส้นทางกลับ

สมมติว่า LAN คือ 10.60.0.0/24 และเซิร์ฟเวอร์ RRAS คือ 10.60.0.10 บนเครือข่ายนั้น โฮสต์ใน LAN นั้นที่ตอบกลับไคลเอนต์ใน 10.250.50.0/24 จำเป็นต้องมีเส้นทางไปยังพูลผ่านเซิร์ฟเวอร์ RRAS หากไม่มีเส้นทางนั้น คำขอจะมาถึงและคำตอบจะตาย

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

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

พิสูจน์พูลใหม่บนอุปกรณ์เดียวก่อนเลิกใช้พูลเดิม

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

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

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

ตรวจสอบผลลัพธ์ด้วยสามการสังเกต

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

จากไคลเอนต์ ยืนยันที่อยู่และเส้นทางไปยังโฮสต์ LAN หนึ่งเครื่อง:

ipconfig | findstr /i "IPv4"
route print -4

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

บทความที่เกี่ยวข้อง