ทำไม kill switch ตัดการรับส่งข้อมูลเมื่อคุณเปลี่ยนเซิร์ฟเวอร์
ทำไม kill switch บล็อกการรับส่งข้อมูลระหว่างการสลับเซิร์ฟเวอร์ ไคลเอนต์ทำอะไรในช่วงนั้น และจะแยกความล่าช้าปกติออกจากการบล็อกที่ค้างได้อย่างไร
คุณเลือกเซิร์ฟเวอร์ที่ดูใกล้กว่า กดเชื่อมต่อ แล้วเบราว์เซอร์ก็หยุดโหลดก่อนที่อุโมงค์ใหม่จะขึ้น ไอคอนเปลี่ยนเป็นสถานะกำลังเชื่อมต่อและค้างอยู่ตรงนั้นขณะที่ทุกแท็บหมดเวลา การหยุดชั่วคราวนี้มักเป็น kill switch ที่ทำงานตามที่ออกแบบไว้ คือบล็อกการรับส่งข้อมูลไว้ตราบใดที่ไคลเอนต์ยังไม่มีอุโมงค์ให้ส่ง ว่าการหยุดนี้ยอมรับได้หรือไม่ขึ้นอยู่กับสิ่งที่ไคลเอนต์ทำในไม่กี่วินาทีนั้น และขึ้นอยู่กับว่าบล็อกถูกยกเลิกเมื่อมันบอกว่ายกเลิกแล้วจริงหรือไม่
ไคลเอนต์ทำอะไรระหว่างสองเซิร์ฟเวอร์
การสลับปลายทางมีหลายขั้นตอน ไม่ใช่สวิตช์ตัวเดียว ไคลเอนต์รื้ออุโมงค์ปัจจุบัน อัปเดตกฎการบล็อกของตน แปลงและไปถึงปลายทางใหม่จากนอกอุโมงค์ แล้วติดตั้งเส้นทางใหม่และยกเลิกการบล็อก ช่องว่างที่คุณรู้สึกได้อยู่ระหว่างขั้นแรกกับขั้นสุดท้าย
ลำดับสำคัญกว่าความเร็วในที่นี้ หากกฎการบล็อกมีผลก่อนข้อยกเว้นสำหรับปลายทางใหม่ ไคลเอนต์จะจับมือไม่สำเร็จและค้างในสถานะกำลังเชื่อมต่อจนหมดเวลา หากข้อยกเว้นเป็นสำเนาที่อยู่ของเซิร์ฟเวอร์เก่า การจับมือใหม่จะดูเหมือนแพ็กเก็ตขาออกอื่น ๆ และถูกทิ้ง ทั้งสองกรณีดูเหมือนกันจากเบราว์เซอร์ จึงเป็นเหตุให้การสลับที่ฟื้นตัวภายในหกวินาทีกับการสลับที่ไม่ฟื้นเลยอาจมีสาเหตุเดียวกัน
ปลายทางใหม่ต้องมีรูในบล็อก
ในการสร้างอุโมงค์ ไคลเอนต์ต้องส่งแพ็กเก็ตไปยังที่อยู่และพอร์ตของเซิร์ฟเวอร์ใหม่ผ่านอินเทอร์เฟซจริง เช่น UDP 51820 สำหรับโปรไฟล์ WireGuard ทั่วไป หรือ 1194 และ 443 สำหรับ OpenVPN ตามที่โปรไฟล์ของคุณกำหนด การรับส่งข้อมูลนั้นไม่ได้อยู่ในอุโมงค์ที่กำลังจะสร้าง ดังนั้นการบล็อกทั้งเครื่องจะกลืนมันไว้ เว้นแต่จะมีกฎอนุญาตที่ตรงกัน
โปรไฟล์ที่อิงชื่อโฮสต์เพิ่มเงื่อนไขที่สอง คือการค้นหานั้นเอง หากไคลเอนต์แปลงปลายทางก่อนที่บล็อกจะขึ้น มันสามารถใช้ที่อยู่ที่แคชไว้ได้ แต่เมื่อโปรไฟล์หมุนที่อยู่หรือรายการแคชเก่า การจับมือจะมุ่งไปยังที่อยู่ที่กฎอนุญาตไม่ครอบคลุม IPv6 ทำให้เห็นชัด เพราะปลายทางแบบสองสแตกสามารถประกาศทั้งระเบียน A และ AAAA และกฎอนุญาตที่ครอบคลุมเฉพาะที่อยู่ v4 จะทำให้ไคลเอนต์ลองใหม่กับที่อยู่ v6 ที่ถูกบล็อกต่อไป
ชื่อตัวเลือกและค่าเริ่มต้นแตกต่างกันตามไคลเอนต์และเวอร์ชัน ดังนั้นอ่านรายการที่มีเอกสารสำหรับของคุณแทนการเดาจากภาพหน้าจอ เอกสารอ้างอิงการตั้งค่า OpenVPN Connect ที่ openvpn.net/connect-docs/app-settings-windows เป็นตัวอย่างหนึ่งว่าตัวเลือกการบล็อกและอุโมงค์แบบแยกส่วนของไคลเอนต์ถูกอธิบายอย่างไร
Fail-closed คือเครื่องสถานะ ไม่ใช่สวิตช์
ไคลเอนต์ส่วนใหญ่แสดงการบล็อกเป็นนโยบายไฟร์วอลล์ในสามสถานะ คือ อุโมงค์ขึ้น โดยมีการรับส่งข้อมูลผ่านอุโมงค์และไม่มีการบล็อก อุโมงค์ลง โดยการบล็อกทำงานอยู่ และช่วงเปลี่ยนผ่าน ที่การบล็อกทำงานอยู่พร้อมข้อยกเว้นชั่วคราวสำหรับปลายทาง บั๊กอาศัยอยู่ในสถานะที่สาม เพราะมันต้องเปลี่ยนสองครั้งภายในไม่กี่วินาที และการออกจากสถานะนั้นไม่ได้ดูเหมือนการบล็อกถาวรทุกประการ
กลไกแตกต่างกันตามแพลตฟอร์ม และความล้มเหลวก็เช่นกัน ตัวกรองของ Windows Filtering Platform มีน้ำหนัก ดังนั้นตัวกรองบล็อกที่เหนือกว่าการอนุญาตของคุณยังคงทิ้งแพ็กเก็ตแม้การอนุญาตจะมีอยู่ และ ตัวกรองที่โปรเซสไคลเอนต์ที่ถูกฆ่าทิ้งไว้ อาจทำให้เครื่องออฟไลน์หลังจากแอปหายไป ไคลเอนต์ macOS มักเขียนกฎ pf ลงในแองเคอร์ ซึ่งลำดับกฎและการตัดสินใจเร็วเป็นตัวกำหนดว่ากฎใดมีผล ไคลเอนต์ Linux มักจัดการเชน nftables หรือ iptables ด้วยนโยบาย drop และการอนุญาตที่ชัดเจนสำหรับปลายทาง อินเทอร์เฟซอุโมงค์ และ loopback โหมด always-on VPN ของ Android พร้อมตัวเลือกบล็อกการเชื่อมต่อที่ไม่มี VPN เป็นตัวที่เข้มงวดที่สุดในกลุ่ม เพราะระบบปฏิบัติการใช้การบล็อกกับทั้งเครื่องไม่ใช่รายแอป
WireGuard ต้องมีหมายเหตุของตัวเอง เพราะ AllowedIPs เป็นตัวเลือกเส้นทาง ไม่ใช่ตัวบล็อก มันตัดสินว่าปลายทางใดเข้าอุโมงค์ ไม่ได้ทำอะไรเพื่อกันไม่ให้แพ็กเก็ตที่ยังไม่มีอุโมงค์ออกผ่าน Wi-Fi ในการตั้งค่าเฉพาะ WireGuard และไม่มีกฎไฟร์วอลล์ kill switch จริง ๆ แล้วคือการไม่มีเส้นทาง และหลังจากการจับมือที่ถูกทิ้ง แพ็กเก็ตจริงอาจออกผ่านอินเทอร์เฟซจริงได้
วัดช่องว่างแทนการดูไอคอน
เฝ้าดูแพ็กเก็ต ไม่ใช่ไฟสถานะ บน Linux เริ่ม ping ช้าไปยังที่อยู่สาธารณะในเทอร์มินัลหนึ่ง และดักพอร์ตขนส่งของอุโมงค์บนอินเทอร์เฟซจริงในอีกอันหนึ่ง:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
สลับเซิร์ฟเวอร์ในไคลเอนต์ขณะที่ทั้งสองทำงาน สามสิ่งสำคัญ คือ ping หยุดนานเท่าใด การดักจับแสดงว่าการจับมือไปถึงปลายทางใหม่หรือไม่ และการรับส่งข้อมูลกลับมาก่อนหรือหลังสถานะไคลเอนต์เปลี่ยนเป็นเชื่อมต่อแล้ว หากช่องว่างของ ping จบก่อน แสดงว่าบล็อกถูกยกเลิกเร็วเกินไปหรืออุโมงค์ขึ้นก่อนที่ตัวบ่งชี้จะยอมรับ หากช่องว่างจบช้ากว่า ตัวบ่งชี้มองโลกในแง่ดีเกินไป
บน Windows netsh wfp show state เขียนสแนปช็อตที่คุณค้นหาตัวกรองบล็อกที่ยังคงอยู่ได้ขณะที่ไคลเอนต์อ้างว่าตัดการเชื่อมต่อแล้ว บน macOS sudo pfctl -sr แสดงรายการกฎที่โหลดและลำดับของกฎ จับคู่สแนปช็อตใดก็ได้กับบันทึกของไคลเอนต์เอง ไทม์ไลน์จาก ping ของคุณบอกว่าการบล็อกสิ้นสุดช้าหรือไม่เคยสิ้นสุด
การมืดปกติกับการบล็อกที่ค้าง
การหยุดชะงักบางส่วนคือจุดประสงค์ของฟีเจอร์นี้ ดังนั้นคัดแยกก่อนที่จะเปลี่ยนการตั้งค่าใด ๆ:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
หากคุณตกอยู่ในแถวที่สองหรือห้า อย่าปิด kill switch เพื่อทดสอบ เพราะนั่นเปลี่ยนบั๊กเส้นทางให้กลายเป็นการรั่วไหล รีสตาร์ทบริการของไคลเอนต์ หรือรีบูตเครื่องในที่ที่ตัวกรองอยู่รอดจากการฆ่าโปรเซส แล้วดูว่าบล็อกหายไปหรือไม่ หากหาย แสดงว่าข้อบกพร่องอยู่ที่การทำความสะอาดระหว่างการสลับ ไม่ใช่ที่ตัวบล็อกเอง
ก่อนการสลับครั้งถัดไป ให้ยืนยันสี่สิ่ง การอนุญาตของปลายทางครอบคลุมทุกตระกูลที่อยู่ที่โปรไฟล์ของคุณแปลง บันทึกไคลเอนต์แสดงว่าการเปลี่ยนผ่านเสร็จสมบูรณ์ การทดสอบ ping ของคุณวัดช่องว่างไม่ใช่ไอคอน และการปิดไคลเอนต์คืนการเชื่อมต่อปกติ kill switch ที่ยึดไว้ระหว่างการสลับแล้วปล่อยหลังจากนั้นทำหน้าที่ของมัน ตัวที่ปล่อยเร็วเกินไปหรือไม่เคยปล่อยควรได้รับการดีบัก