เรียกใช้งาน เมื่อ VPN เชื่อมต่อ: เหตุการณ์ การตรวจสอบ หรือข้อมูลรับรอง?
สคริปต์ลงชื่อเข้าใช้ทำงานก่อนอุโมงค์จะมีอยู่ เปรียบเทียบตัวกระตุ้นเหตุการณ์เครือข่าย การตรวจสอบทรัพยากร และข้อมูลรับรองที่จัดเก็บไว้ตามสิ่งที่แต่ละอย่างรับประกัน
สคริปต์ลงชื่อเข้าใช้ที่แมปไดรฟ์หรือเริ่มงานซิงค์ทำงานก่อนที่อุโมงค์จะได้รับที่อยู่ จึงล้มเหลวอย่างเงียบ ๆ และผู้ใช้ต้องซ่อมด้วยมือทุกเช้า Windows ไม่มี callback ต่อการเชื่อมต่อ VPN ให้ไคลเอนต์ส่วนใหญ่ แต่บันทึกการเปลี่ยนแปลงเครือข่ายไว้ และบันทึกนั้นสามารถเริ่มงานได้ในจังหวะที่ถูกต้อง ทางเลือกอยู่ระหว่างการตอบสนองต่อบันทึกนั้น การตรวจสอบทรัพยากร และการลบข้อความแจ้งที่ทำให้ความล้มเหลวมองเห็นได้
การเปรียบเทียบกลไกทั้งสามตามสิ่งที่รับประกันดีกว่าการจัดอันดับตามความสง่างาม แต่ละอย่างล้มเหลวต่างกัน และรูปแบบความล้มเหลวคือสิ่งที่คุณอยู่กับมันหลังจากนั้น
ทำไมการลงชื่อเข้าใช้จึงเริ่มเร็วเกินไป
การลงชื่อเข้าใช้และการเริ่มระบบทำงานก่อนที่อะแดปเตอร์ VPN จะได้รับที่อยู่ ดังนั้นการแมปไดรฟ์ URL ภายใน หรือการเชื่อมต่อฐานข้อมูลที่ลองในจังหวะนั้นจึงไม่มีทั้งเส้นทางและตัวแปลงชื่อ การร้องขอจึงล้มเหลว และเซสชันถูกทิ้งไว้ในสถานะที่ผู้ใช้ต้องซ่อมเอง การย้ายสคริปต์เดิมไปยังโฟลเดอร์เริ่มระบบไม่เปลี่ยนอะไร เพราะปัญหาเรื่องลำดับเดินทางไปด้วย ตัวกระตุ้นต้องเป็นการเปลี่ยนแปลงเครือข่าย ไม่ใช่เหตุการณ์ของเซสชัน
งานที่ตั้งเวลาไว้ตอนลงชื่อเข้าใช้ด้วยความหน่วงตามอำเภอใจดูเหมือนการแก้ไข แต่จริง ๆ คือการเดา มันได้ผลบนลิงก์เร็วและล้มเหลวบนลิงก์ช้า ซึ่งเป็นความน่าเชื่อถือแบบที่ไร้ประโยชน์ที่สุด
ตะขอสามแบบเปรียบเทียบ
กลไกต่างกันที่สิ่งที่สังเกต ความเร็วในการตอบสนอง และสิ่งที่ทำเมื่อเชื่อมต่อใหม่ในภายหลังของวัน ตารางเปรียบเทียบทั้งสามจุดนั้น ไม่ใช่เปรียบเทียบว่าอันไหนฟังดูฉลาดกว่า
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
อ่านตารางทีละแถว ตะขอเหตุการณ์เร็วที่สุดและมีเสียงรบกวนมากที่สุด เพราะ Windows บันทึกทุกเครือข่ายรวมถึง Wi-Fi ของร้านกาแฟ การกระทำจึงต้องตรวจสอบทรัพยากรก่อนทำอะไร การตรวจสอบช้ากว่าและแม่นยำกว่า เพราะสำเร็จเมื่อการแชร์หรือชื่อโฮสต์ตอบสนอง และไม่จำเป็นต้องรู้ว่าไคลเอนต์ใดถูกติดตั้ง ข้อมูลรับรองที่จัดเก็บไว้ไม่ใช่ตัวเลือกที่แข่งขันเลย: มันลบข้อความขอรหัสผ่าน ซึ่งเป็นเหตุผลที่สองและเป็นอิสระว่าทำไมการแมปตอนลงชื่อเข้าใช้จึงล้มเหลว
การเลือกระหว่างสองอย่างแรกขึ้นอยู่กับว่ามีเหตุการณ์ที่ใช้ได้บนไคลเอนต์หรือไม่ หากมี เหตุการณ์พร้อมการตรวจสอบทรัพยากรคือค่าเริ่มต้นที่ดีกว่า
สร้างตัวกระตุ้นเหตุการณ์ให้ถูกต้อง
บันทึกอยู่ในล็อก Microsoft-Windows-NetworkProfile/Operational และ ID 10001 ทำเครื่องหมายเครือข่ายที่เพิ่งเชื่อมต่อ สร้างงานด้วยตัวกระตุ้นเมื่อมีเหตุการณ์ที่ชี้ไปยังล็อกนั้น ชื่อผู้ให้บริการนั้น และตัวระบุนั้น ทุกเครือข่ายที่เครื่องเข้าร่วมจะกระตุ้นมัน การกระทำจึงต้องมีเงื่อนไขป้องกันไม่ใช่การสันนิษฐาน และควรทำงานเฉพาะขณะผู้ใช้ลงชื่อเข้าใช้หากงานแตะไดรฟ์ที่แมปไว้
เงื่อนไขป้องกันควรทดสอบสิ่งที่งานต้องการจริง เช่น เส้นทางการแชร์หรือพอร์ตบริการ และออกอย่างเงียบ ๆ เมื่อเข้าถึงไม่ได้ การทดสอบชื่ออะแดปเตอร์ไม่เพียงพอ เพราะไคลเอนต์อาจใช้อะแดปเตอร์ตัวเดียวซ้ำในหลายโปรไฟล์ การออกอย่างเงียบ ๆ ทำให้ล็อกอ่านได้และป้องกันพายุการลองซ้ำกับเครือข่ายที่จะไม่ให้ทรัพยากรนั้นเลย
ทดสอบว่างานทำงานในจังหวะที่ถูกต้อง
พิสูจน์จังหวะ ไม่ใช่การกำหนดค่า คำสั่งด้านล่างแสดงคำจำกัดความของงาน เหตุการณ์โปรไฟล์เครือข่ายล่าสุด และทรัพยากรเข้าถึงได้จากบัญชีที่งานทำงานอยู่หรือไม่ เรียกใช้หลังจากเชื่อมต่อใหม่จริง ไม่ใช่หลังเริ่มด้วยมือ
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiรายการในประวัติงานที่มีอยู่ขณะไม่มีเหตุการณ์เครือข่ายตรงกันหมายความว่าตัวกระตุ้นผิด ไม่ใช่การกระทำ หากเหตุการณ์ปรากฏแต่งานไม่ทำงาน งานอาจ ทำงานภายใต้บัญชีที่ไม่เห็นทรัพยากร และเอาต์พุตของบัญชีคือเบาะแส การตรวจสอบทรัพยากรที่ผ่านขณะยังขาดการแมปชี้ไปที่บริบทของเซสชัน ไม่ใช่การเชื่อมต่อ แต่ละข้อสังเกตทั้งสามนี้นำคุณไปสู่การแก้ไขที่ต่างกัน
เขียนบันทึกหนึ่งบรรทัดต่อการทำงานหนึ่งครั้งพร้อมที่อยู่ ผลลัพธ์ของทรัพยากร และผลลัพธ์สุดท้าย ความล้มเหลวครั้งถัดไปจะแสดงว่างานทำงานเร็วเกินไป ทำงานบนเครือข่ายผิด หรือไม่ทำงานเลย