แมปไดรฟ์ก่อน VPN พร้อมหรือไม่? ผูกเงื่อนไขกับเซิร์ฟเวอร์

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

ทำไมการแมปจึงทำงานเร็วเกินไป

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

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

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

สถานะเชื่อมต่อไม่ใช่เส้นทาง

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

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

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

ผูกเงื่อนไขกับเซิร์ฟเวอร์ ไม่ใช่ไคลเอนต์

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

@echo off
set server=fileserver.corp.example
rasdial "Office VPN" /disconnect
rasdial "Office VPN"
:wait
ping -n 1 -w 1000 %server% >nul || (
  timeout /t 5 /nobreak >nul
  goto wait
)
net use Z: \\%server%\share /persistent:no

Ping เป็นการตรวจสอบความพร้อม ไม่ใช่การทดสอบสิทธิ์ หากเครือข่ายของคุณกรอง ICMP ให้ตรวจสอบบริการที่คุณใช้จริงแทน: net view \\%server% สำหรับการตรวจสอบอย่างรวดเร็ว หรือการทดสอบ TCP สั้น ๆ ไปยังพอร์ต 445 ใน PowerShell ทั้งสองอย่างผูกเงื่อนไขกับสิ่งที่สำคัญ

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

ทำให้รันซ้ำได้และตระหนักถึงเซสชัน

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

ตรวจสอบก่อนแมป และลบเฉพาะรายการที่เก่าเท่านั้น net use Z: /delete คืนค่าข้อผิดพลาดเมื่อตัวอักษรไม่ได้ใช้งาน และข้อผิดพลาดนั้นปลอดภัยที่จะเพิกเฉย ไม่ใช่เหตุผลที่จะละทิ้งสคริปต์ส่วนที่เหลือ เก็บ /persistent:no ไว้เพื่อให้ความพยายามที่ล้มเหลวไม่กลายเป็นการเชื่อมต่อใหม่ถาวรในภายหลัง

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

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

บันทึกให้พอที่จะพิสูจน์ว่าครึ่งไหนมาสาย

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

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

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