VPN สองแอปพร้อมกัน: kill switch ตัวไหนที่ใช้จริง?
ไคลเอนต์ VPN ตัวที่สองไม่เคยสืบทอด kill switch ของตัวแรก มีสามเงื่อนไขที่กำหนดว่านโยบายใดมีผล และวิธีตรวจสอบของคุณ
ไคลเอนต์ VPN สองตัวทำงานเคียงกันได้ แต่ kill switch ของทั้งสองไม่หลอมรวมเป็นนโยบายเดียว ไคลเอนต์แต่ละตัวติดตั้งกฎสำหรับอุโมงค์ของตัวเอง และไม่มีตัวไหนรู้ว่าอีกตัวมีอยู่ ฉันเจอกรณีนี้กับไคลเอนต์ของงานที่เชื่อมต่อก่อน: แอปที่สองจับมือไม่สำเร็จ ค้างที่ „Connecting“ สิบนาที และอุโมงค์แรกพาทุกอย่างไปอย่างเงียบ ๆ การที่แอปที่สองจะได้รับการป้องกันหรือไม่ขึ้นอยู่กับสามเงื่อนไข ไม่ใช่ขึ้นกับว่าไอคอนทั้งสองขึ้นว่าเชื่อมต่อแล้ว
kill switch จำกัดขอบเขตไว้ที่อะไรจริง ๆ
ไม่มีธง kill switch ตัวเดียวในระบบปฏิบัติการ ไคลเอนต์ที่โฆษณาคุณสมบัตินี้จะติดตั้งชุดกฎ: ทิ้งทุกอย่างที่ไม่ผ่านอุโมงค์ของฉัน และมัก fail closed เมื่ออุโมงค์หายไป บน Linux มักเป็นเชน nftables หรือ iptables บน Windows เป็นชุดตัวกรอง Windows Filtering Platform บน Android และ iOS เป็นการกำหนดเส้นทางของบริการอุโมงค์เองพร้อมการตั้งค่าระบบที่บล็อกการเชื่อมต่อเมื่อไม่มี VPN คู่มือ VPN ของ Android อธิบายรูปแบบบริการนั้นหากคุณต้องการมุมมองของแพลตฟอร์ม
ขอบเขตคือส่วนที่สำคัญ กฎอย่าง „อนุญาตเฉพาะแพ็กเก็ตบนอินเทอร์เฟซขาออก wg0“ ไม่สนใจว่ามีอุโมงค์ที่สองหรือไม่ ถ้าไคลเอนต์อื่นยก wg1 ขึ้นมา กฎของไคลเอนต์แรกจะถือแพ็กเก็ตเหล่านั้นเป็นทราฟฟิกธรรมดา: มักถูกทิ้ง บางครั้งถูกอนุญาต ไม่ว่าอย่างไรก็เป็นไคลเอนต์แรกที่ตัดสิน และมันไม่รู้เลยว่ามีแอปที่สองรออยู่
สามเงื่อนไขที่กำหนดว่าใครจะได้รับการคุ้มครอง
คุณไม่จำเป็นต้องไล่ทุกกรณีที่เป็นไปได้ สามคำถามตัดสินเรื่องนี้ได้ในไม่กี่นาที
- แพลตฟอร์มอนุญาตอุโมงค์ที่สองหรือไม่ โทรศัพท์ Android และ iPhone ส่วนใหญ่รับบริการ VPN ที่ใช้งานได้เพียงหนึ่งบริการต่อโปรไฟล์ผู้ใช้ แอปที่สองจึงไม่เคยมีอุโมงค์และไม่เคยบังคับใช้อะไร คุณได้นโยบายเดียวจากแอปที่ได้ที่นั่งไป
- โปรเซสใดเป็นเจ้าของเส้นทางเริ่มต้น Windows, macOS และ Linux รองรับสองอุโมงค์ได้สบาย ๆ เส้นทางเริ่มต้นเป็นของไคลเอนต์ที่ตั้งค่าไว้ล่าสุดหรือมีเมตริกดีกว่า และอีกไคลเอนต์เชื่อมต่ออยู่แต่ไม่ได้ทำงาน บน Linux โหมดเส้นทางเริ่มต้นของ wg-quick ใช้การกำหนดเส้นทางตามนโยบายพร้อมตารางส่วนตัวและกฎ fwmark ดังนั้นอุโมงค์ wg-quick ที่สองจึงเพิ่มกฎที่แข่งขันกันแทนที่จะแทนที่อันแรก
- ไคลเอนต์ที่สองเข้าถึงเซิร์ฟเวอร์ของตัวเองได้หรือไม่ ถ้า kill switch แรกเป็นแบบปฏิเสธโดยปริยาย จุดปลายภายนอกของแอปที่สองก็เป็นเพียงปลายทางที่ถูกทิ้งอีกแห่ง มันลองใหม่เงียบ ๆ และไม่เคยรายงานข้อผิดพลาด
เวอร์ชันสั้น สำหรับกระทู้สนับสนุน
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
สองในแถวเหล่านั้นดูเหมือนกันจากไอคอนในถาดระบบ จึงเป็นเหตุผลที่ไอคอนเป็นหลักฐานที่แย่ที่สุดที่หาได้ตรงนี้
อะไรล้มเหลวก่อน และหน้าตาเป็นอย่างไร
ไคลเอนต์ที่ค้างอยู่ที่ „Connecting“ ขณะที่อีกตัวแข็งแรงมักหมายถึงการขาดแคลนจุดปลาย: kill switch ที่ทำงานอยู่ทิ้งการจับมือของไคลเอนต์ที่สองไปยังเซิร์ฟเวอร์ของมันเอง ตรวจสอบได้ถูกด้วยการหยุดกฎบล็อกของไคลเอนต์แรกชั่วคราวหนึ่งครั้ง ถ้าตัวที่สองเชื่อมต่อได้ทันที คำถามก็มีคำตอบ
DNS คือความล้มเหลวที่สอง ไคลเอนต์ตั้งค่าตัวแก้ชื่อสำหรับอินเทอร์เฟซของตัวเอง และบางตัวเขียนทับรายการส่วนกลางทั้งรายการ เมื่ออุโมงค์ทั้งสองขึ้นอยู่ คำถามอาจออกไปทางด้านหนึ่งขณะที่ตัวแก้ชื่อเป็นของอีกด้าน ตัดการเชื่อมต่อแอปใดแอปหนึ่งแล้วตัวที่เหลือจะยังมีเนมเซิร์ฟเวอร์ที่เข้าถึงไม่ได้: หน้าค้างหนึ่งนาทีแล้วจึงแก้ได้อีกครั้ง ขณะที่ VPN ยังแสดงว่าเชื่อมต่ออยู่
อย่างที่สามคือเส้นทางกระพริบ การเชื่อมต่อใหม่จัดลำดับเส้นทางเริ่มต้นใหม่ และ kill switch ที่ผูกกับอินเทอร์เฟซไม่ตามไปด้วย ทราฟฟิกที่เพิ่งอยู่ในอุโมงค์เมื่อครู่ตอนนี้ตรงกับกฎทิ้ง ซึ่งฝั่งผู้ใช้ตีความว่าเป็น VPN ที่หยุดทำงานเป็นครั้งคราว
ตรวจสอบว่านโยบายใดมีผลจริง
ทำสิ่งนี้กับทราฟฟิกที่ไม่เป็นอันตราย ไม่ใช่กับสิ่งที่คุณจะเสียดาย
บน Linux ถามเคอร์เนลว่าใครชนะและไฟร์วอลล์ผูกกับอะไร ip -4 route show default บอกชื่ออุโมงค์ที่เป็นเจ้าของทางออก ip rule show แสดงว่าการกำหนดเส้นทางตามนโยบายเกี่ยวข้องหรือไม่ sudo nft list ruleset | grep -n oifname แสดงว่าการทิ้งผูกกับชื่ออินเทอร์เฟซ เครื่องหมาย หรือเชนขาออกทั้งหมด
บน Windows เรื่องเดียวกันอยู่ในเมตริกเส้นทางและรายการตัวกรอง: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric และ Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN" บน macOS netstat -rn -f inet | head -5 และ scutil --dns | head -20
จากนั้นทำขั้นตอนที่คนมักข้าม: หยุดอุโมงค์โดยเจตนาและยืนยันว่าทราฟฟิกที่คุณคาดว่าจะล้มเหลวนั้นล้มเหลวจริง ไอคอนที่เชื่อมต่อคือสถานะของอินเทอร์เฟซ ไม่ใช่การบังคับใช้
เมื่อไหร่ที่สองไคลเอนต์เป็นการออกแบบที่ผิด
ถ้าข้อกำหนดเดียวเบื้องหลังแอปที่สองคือการป้องกันที่มากขึ้น ให้เอามันออก สองนโยบายบล็อกที่โต้ตอบกันคาดเดาได้น้อยกว่าหนึ่ง และทุกครั้งที่เชื่อมต่อใหม่คือโอกาสที่จะไปจบในสถานะที่ไม่มีผู้จำหน่ายรายใดทดสอบ
ถ้าคุณต้องการการเชื่อมต่อเป็นทอดจริง ๆ เช่นเกตเวย์องค์กรที่เข้าถึงผ่าน hop เชิงพาณิชย์ ให้เลือกการออกแบบที่มีจุดบังคับใช้เพียงจุดเดียว ซึ่งปกติหมายถึงเราเตอร์หรือไคลเอนต์ตัวเดียวที่รองรับทอดเหล่านั้น ไม่ใช่แอปเดสก์ท็อปสองตัวแย่งเส้นทางเริ่มต้นเดียวกัน บนอุปกรณ์ที่ถูกจัดการ ให้เก็บไคลเอนต์ที่ได้รับอนุญาตและถือว่าอย่างอื่นอยู่นอกขอบเขต ไม่ว่ามันจะแสดงอะไรในถาด
รายการตรวจสอบก่อนเก็บทั้งสองตัว
ไล่รายการตามลำดับ ข้อแรกที่ล้มเหลวคือข้อที่ต้องแก้
- ยืนยันว่ามีไคลเอนต์เพียงตัวเดียวที่เป็นเจ้าของเส้นทางเริ่มต้นและตัวแก้ชื่อ
- ถ้าต้องการให้ไคลเอนต์ที่สองทำงาน อนุญาตจุดปลายเซิร์ฟเวอร์ของมันอย่างชัดเจนและตรวจซ้ำหลังทุกครั้งที่อัปเดตไคลเอนต์
- จดผลลัพธ์ที่คาดไว้เมื่ออุโมงค์ใดอุโมงค์หนึ่งล่ม แล้วทดสอบกรณีนั้นโดยเฉพาะ
- ตรวจเส้นทางความล้มเหลวหลังรีบูต เมื่อลำดับการเริ่มต่างออกไป
- บนโปรไฟล์ที่ถูกจัดการ ให้หยุดและถามเจ้าของก่อนเพิ่มอะไร
ถ้าขั้นตอนที่สามล้มเหลว คำตอบที่ซื่อสัตย์คือมีเพียงไคลเอนต์เดียวที่ให้นโยบายกับคุณ ตัดสินใจว่าจะเชื่อตัวไหนและปล่อยอีกตัวไป