หนึ่ง VPN สองบัญชี Windows: ทำไมอีกเซสชันจึงเสีย
เส้นทางและตัวแก้ไขชื่ออยู่ในขอบเขตทั้งเครื่อง อุโมงค์ของบัญชีหนึ่งจึงเปลี่ยนเส้นทางของบัญชีอื่น จากนั้นหานโยบายหรือโมดูลลงชื่อเข้าใช้ที่ลบรายการ 'สลับผู้ใช้'
สองคนลงชื่อเข้าใช้อยู่ คนหนึ่งเชื่อมต่ออุโมงค์ของบริษัท และเบราว์เซอร์ของอีกบัญชีก็หยุดโหลดหน้าที่เพิ่งใช้งานได้ดีเมื่อนาทีที่แล้ว บนเครื่องเดียวกัน รายการ 'สลับผู้ใช้' ก็หายไปจากหน้าจอลงชื่อเข้าใช้ด้วย คนที่สองจึงกลับเข้าสู่เซสชันของตัวเองไม่ได้ การไล่ดูเรื่องนี้จากเซสชันที่สองออกไปด้านนอกเป็นวิธีที่เร็วที่สุดในการทำความเข้าใจ เพราะไม่มีอะไรถูกซ่อนไว้ในการเชื่อมต่อของผู้ใช้คนแรก และไม่มีอะไรเป็นปริศนาในปัญหาของผู้ใช้คนที่สองเมื่อเห็นว่าวัตถุใดถูกแชร์ร่วมกัน
เริ่มจากเซสชันที่เสีย
ไปที่เดสก์ท็อปของบัญชีที่สอง ไม่ใช่บัญชีแรก เปิดเทอร์มินัลที่นั่นและดูตารางเส้นทางกับรายการตัวแก้ไขชื่อ ขณะที่อีกเซสชันเชื่อมต่ออยู่ ทุกสิ่งที่เห็นเป็นของเครื่อง ไม่ใช่ของผู้ใช้คนอื่น และนั่นคือเบาะแสแรก
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 DestinationPrefix,NextHop,InterfaceAlias
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,ServerAddresses
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivityหากเส้นทางค่าเริ่มต้นชี้ไปที่อินเทอร์เฟซของอุโมงค์ ทราฟฟิกของผู้ใช้คนที่สองก็ตามไปด้วย หากรายการตัวแก้ไขชื่อมีเซิร์ฟเวอร์ส่วนตัวเพิ่มเข้ามา การค้นหาของพวกเขาก็ไปยังที่ที่เข้าถึงไม่ได้เมื่ออุโมงค์หลุด ทั้งสองอย่างไม่ใช่บั๊กในไคลเอนต์ แต่เป็นผลจากสแต็กเครือข่ายเดียวที่ใช้ร่วมกัน
คำสั่งที่สามอธิบายข้อร้องเรียนอีกประเภทหนึ่ง เมื่ออะแดปเตอร์เปลี่ยนเครื่องจากหมวดเครือข่ายสาธารณะเป็นส่วนตัว กฎไฟร์วอลล์ที่ผูกกับโปรไฟล์จะเปลี่ยนสำหรับทุกบัญชีพร้อมกัน แอปพลิเคชันที่ได้รับอนุญาตตอนเช้าจึงอาจถูกบล็อกตอนบ่ายโดยไม่มีใครแตะต้องกฎ
การเชื่อมต่อเป็นรายผู้ใช้ แต่เครือข่ายไม่ใช่
Windows เก็บออบเจ็กต์การเชื่อมต่อไว้ในโปรไฟล์ของผู้ใช้ที่สร้างมัน อะแดปเตอร์เสมือนที่มันสร้าง เส้นทางที่มันติดตั้ง และ เซิร์ฟเวอร์ DNS ที่มันลงทะเบียนอยู่ในขอบเขตของทั้งเครื่อง การแยกส่วนนี้คือต้นตอของอาการทั้งสองในหัวข้อ
นี่อธิบายด้วยว่าทำไมการลงชื่อออกของผู้ใช้คนแรกมักแก้ปัญหาของคนที่สอง การลบการเชื่อมต่อลบอะแดปเตอร์และเส้นทางไปด้วย สถานะระดับเครื่องกลับไปเป็นเหมือนก่อนมีใครเชื่อมต่อ นั่นเป็นการวินิจฉัยที่มีประโยชน์ หากการลงชื่อออกซ่อมบัญชีอื่นได้ แสดงว่าคุณกำลังดูสถานะที่แชร์ร่วมกัน ไม่ใช่โปรไฟล์ที่พัง
สิ่งที่ทำไม่ได้คือให้เซสชันที่สองมีตารางเส้นทางคนละตาราง มีตารางเดียว และสองเซสชันใดก็แชร์ตารางนั้น นี่เป็นคุณสมบัติของระบบปฏิบัติการ ไม่ใช่ข้อจำกัดของไคลเอนต์ใดไคลเอนต์หนึ่ง ยังหมายความว่าการออกแบบใดที่สมมติตรงกันข้ามจะล้มเหลวต่อไป และความล้มเหลวนั้นจะดูเหมือนบั๊กแอปพลิเคชันที่ไม่เกี่ยวข้องกัน
ค้นหาว่าอะไรลบรายการ 'สลับผู้ใช้' ตามลำดับนี้
การสลับผู้ใช้แบบเร็วหายไปด้วยเหตุผลที่ต่างกันโดยสิ้นเชิง และวิธีแก้ไม่เกี่ยวกับการกำหนดเส้นทางเลย ลองไล่ผู้ต้องสงสัยทั้งสี่ตามลำดับ เพราะสองข้อแรกย้อนกลับได้ในไม่กี่วินาที ส่วนข้อหลังมีค่าใช้จ่าย
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name HideFastUserSwitching
gpresult /h $env:TEMP\gp.html
Get-Service | Where-Object { $_.DisplayName -match 'Logon|Access|Credential' } | Select-Object Status,Name,DisplayNameค่าทะเบียนรีจิสทรีเป็นคำอธิบายที่ง่ายที่สุด หากมีอยู่และอ่านว่า 1 รายการนั้นถูกซ่อนด้วยนโยบาย และเส้นทางนโยบายกลุ่มคือ Computer Configuration, Administrative Templates, System, Logon และการตั้งชื่อสำหรับซ่อนจุดเข้าสู่การสลับผู้ใช้แบบเร็ว ตั้งเป็น Not Configured แล้วรีเฟรชด้วย gpupdate /force
คำสั่งที่สองบอกว่านโยบายนั้นถูกส่งมาจากโดเมนหรือเขียนไว้ในเครื่อง หากปรากฏในรายงานพร้อม GPO ที่ชนะ การแก้ไขค่าในเครื่องเป็นการแก้ชั่วคราวที่จะย้อนกลับในการรีเฟรชครั้งถัดไป และเรื่องนี้ต้องคุยกับเจ้าของนโยบาย
คำสั่งที่สามครอบคลุมกลไกอีกอย่าง ผู้ให้บริการข้อมูลรับรองหรือการเข้าถึงเครือข่ายที่ติดตั้งโมดูลลงชื่อเข้าใช้อาจกดรายการนั้นไว้ขณะทำงาน และไคลเอนต์บางตัวยังลงทะเบียนคอมโพเนนต์ที่เริ่มก่อนการลงชื่อเข้าใช้และยึดสิทธิ์บนหน้าจอลงชื่อเข้าใช้ การปิดบริการนั้นคืนการสลับ แต่ก็ลบฟังก์ชันก่อนการลงชื่อเข้าใช้หรือ posture ที่โมดูลมีไว้ให้บริการด้วย
| Cause | How to confirm | Cost of the fix |
|---|---|---|
| HideFastUserSwitching policy | Registry value present and set to 1 | None; remove the policy |
| Logon module service | Service running under a vendor name | Loses pre-logon and posture behaviour |
| GINA-era assumption | Only relevant on very old Windows | Nothing to fix; the mechanism is gone |
เปลี่ยนโดยไม่ล็อกตัวเองออก
เปิดเซสชันผู้ดูแลระบบไว้หนึ่งเซสชันขณะทำงาน และอย่าเปลี่ยนการตั้งค่าหน้าจอลงชื่อเข้าใช้บนเครื่องที่เข้าถึงได้ทางหน้าจอนั้นเท่านั้น ลงชื่อออกจากเซสชันอื่นก่อน ใช้การเปลี่ยนแปลง รีเฟรช แล้วทดสอบด้วยการสลับผู้ใช้แทนการรีบูต
บันทึกว่าปิดฟังก์ชัน posture ใดไปบ้าง การอัปเดตไคลเอนต์อาจติดตั้งหรือเปิดโมดูลลงชื่อเข้าใช้อีกครั้ง และอาการจะกลับมาโดยไม่มีสาเหตุชัดเจน มักเกิดกลางหน้าต่างการสนับสนุนเมื่อไม่มีใครจำการเปลี่ยนแปลงก่อนหน้าได้
บนอุปกรณ์ที่ได้รับการจัดการ ให้ถือว่าการตั้งค่าถูกส่งมาจากด้านบน การตรวจรายงานนโยบายก่อนจะประหยัดเวลาหนึ่งชั่วโมงจากการแก้ในเครื่องที่ย้อนกลับ ยังบอกด้วยว่าควรถามใครเมื่อคำตอบคือไม่ ตั๋วที่ระบุนโยบายที่ชนะจะได้รับการแก้เร็วกว่าตั๋วที่อธิบายคีย์รีจิสทรีที่ใครบางคนเปลี่ยนไปแล้วถึงสองเท่า
ตรวจสอบทั้งสองบัญชีและเลือกโมเดล
ทดสอบผลลัพธ์ตามลำดับที่ผู้ใช้ทั้งสองสัมผัส ลงชื่อเข้าใช้ด้วยบัญชีที่สองขณะที่บัญชีแรกตัดการเชื่อมต่อ ยืนยันการเข้าถึงปกติ จากนั้นเชื่อมต่ออุโมงค์ของบัญชีแรกและยืนยันว่าเส้นทางที่คาดหวังของบัญชีที่สองยังเป็นอย่างที่ตั้งใจ
qwinsta
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias,NextHop,RouteMetric
Test-NetConnection -ComputerName intranet.example.internal -Port 443หากทั้งสองบัญชีต้องการเส้นทางเครือข่ายต่างกันในเวลาเดียวกันจริง คำตอบที่ตรงไปตรงมาคือสองเครื่อง สองเครื่องเสมือน หรือนโยบายที่ต้องการเพียงเส้นทางเดียว อุโมงค์แบบแยกบนการเชื่อมต่อที่แชร์กันสามารถจำกัดสิ่งที่วิ่งผ่านได้ แต่ไม่สามารถให้แต่ละเซสชันมีตารางของตัวเอง การยอมรับแต่เนิ่นๆ ถูกกว่าการค้นพบหลังจากลองทางอ้อมไปสามครั้ง
นี่คือการตัดสินใจที่ต้องทำอย่างชัดเจนแทนการปะรอบๆ ตารางเส้นทางหนึ่ง ตารางรายการตัวแก้ไขชื่อหนึ่ง โปรไฟล์ไฟร์วอลล์หนึ่ง สิ่งอื่นทั้งหมดตามมาจากสิ่งนี้ และวิธีแก้ที่เคารพสิ่งนี้จะยังทำงานได้ในเดือนหน้า