ทำไม RDP ค้างเมื่อคอมพิวเตอร์ระยะไกลเชื่อมต่อ VPN

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

บันทึกปลายทางที่เซสชันของคุณใช้จริง

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

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

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

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

อ่านเส้นทางที่ตอบกลับปลายทางนั้น

Windows เลือกอินเทอร์เฟซตามปลายทาง และ Find-NetRoute แสดงการตัดสินใจที่มันจะทำตอนนี้ รันกับที่อยู่เพียร์ก่อนเชื่อมต่อ แล้วรันอีกครั้งเมื่ออุโมงค์ขึ้น เปรียบเทียบดัชนีอินเทอร์เฟซและฮอปถัดไปในสองคำตอบ การเปลี่ยนอินเทอร์เฟซคือบั๊กทั้งหมดในเอาต์พุตบรรทัดเดียว

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

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

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

จับตาการเปลี่ยนโปรไฟล์ไฟร์วอลล์

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

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

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

ทดสอบการเปลี่ยนผ่านจากจุดที่คุณกลับมาได้

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

วางแผนการย้อนกลับก่อนเริ่ม เช่น งานตามกำหนดเวลาที่รัน rasdial "Work VPN" /disconnect หลังจากช่วงเวลาที่ตั้งไว้ สิ่งนี้เปลี่ยนเซสชันที่หายไปให้เป็นการหยุดห้านาทีแทนการเดินทางไปหน้างาน และเป็นการประกันที่ถูกที่สุดในขั้นตอนทั้งหมด

กลับเข้าไปเมื่อเซสชันหายไปแล้ว

ถ้าโฮสต์เข้าถึงไม่ได้แล้ว ให้หยุดลองเชื่อมต่อ RDP ใหม่จากไคลเอนต์เดิม และใช้ช่องทางกู้คืนที่สภาพแวดล้อมมีอยู่แล้ว เช่น RD Gateway คอนโซลไฮเปอร์ไวเซอร์ หรืออินเทอร์เฟซจัดการนอกแบนด์ ขอให้ผู้ที่มีสิทธิ์เข้าถึงคอนโซลรันคำสั่งเดิม Find-NetRoute และ Get-NetConnectionProfile เพื่อให้หลักฐานอยู่รอดหลังการกู้คืน

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