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

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

วิธีแรก: อนุญาตโปรแกรมบนโปรไฟล์เดียวเท่านั้น

ไฟร์วอลล์ของ Windows จำกัดกฎไว้ที่โปรไฟล์ Domain, Private และ Public กลเม็ดคือให้อะแดปเตอร์ของอุโมงค์อยู่ในหมวดหนึ่งและอะแดปเตอร์จริงอยู่อีกหมวดหนึ่ง จากนั้นเขียนกฎขาออกที่อนุญาตโปรแกรมที่ได้รับการป้องกันบนโปรไฟล์ของอุโมงค์และบล็อกมันทุกที่อื่น ไฟร์วอลล์อ่านหมวดหมู่ ไม่ใช่ชื่ออะแดปเตอร์

ตั้งค่าการเชื่อมต่อ VPN เป็น Private และเครือข่ายจริงเป็น Public ก่อน จากนั้นเพิ่มกฎบล็อกสำหรับโปรแกรมที่ใช้กับโปรไฟล์ที่ไม่ต้องการ หลังจากนั้นยืนยันการกำหนดด้วย Get-NetConnectionProfile เพราะกฎจะตามการกำหนดนั้น

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

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

วิธีที่สอง: ลบเส้นทางเริ่มต้นของอะแดปเตอร์จริง

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

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

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

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

วิธีที่สาม: ไม่มีเกตเวย์ มีเส้นทางโฮสต์ถาวรเพียงเส้นเดียว

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

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

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

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

ทำไมไอคอนลูกโลกจึงไม่ได้พิสูจน์อะไร

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

ทดสอบด้วยการฆ่าโปรเซสของไคลเอนต์ แล้วลองเข้าถึงที่อยู่สาธารณะด้วยตัวเลข การค้นหาชื่ออาจได้คำตอบจากแคช ดังนั้นทั้งไอคอนและคำตอบ DNS จึงไม่ใช่หลักฐาน

สิ่งที่ควรบันทึกหลังการขาดจริง

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

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

ทำลำดับซ้ำหลังการหลับ หลังเปลี่ยน Wi-Fi และหลังย้ายจากสายไปไร้สาย ช่วงเปลี่ยนผ่านเหล่านี้คือที่ที่ทั้งวิธีโปรไฟล์และพฤติกรรมของ DHCP ล้มเหลว กฎที่อยู่บนโต๊ะทำงานไม่จำเป็นต้องอยู่รอดในโรงแรม

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

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