วิธีทดสอบสวิตช์ตัดการเชื่อมต่อของ VPN โดยไม่ใช้บัญชีจริง
ทดสอบสวิตช์ตัดการเชื่อมต่อด้วยหน้าล่อและโปรไฟล์สำรอง: ครอบคลุมการขัดข้องทุกแบบ อ่านรหัสออกของ curl และแยกการบล็อกจริงออกจากความล้มเหลวของ DNS
คุณไม่จำเป็นต้องใช้บัญชีจริงเพื่อดูว่าสวิตช์ตัดการเชื่อมต่อจะยึดอยู่หรือไม่ เพราะสิ่งที่การทดสอบนำไปเสี่ยงคือบัญชีนั้นเอง การตรวจสอบสร้างช่วงเวลาสั้น ๆ ที่ทราฟฟิกอาจออกนอกอุโมงค์หรือไม่ออกก็ได้ ดังนั้นเพย์โหลดควรเป็นสิ่งที่คุณยอมเสียได้ ตอนนี้ผมทำสิ่งนี้ด้วยหน้าล่อและโปรไฟล์เบราว์เซอร์สำรอง และได้คำตอบชัดเจนกว่าวิธีเบราว์เซอร์กับเว็บเมลที่เคยใช้ ด้านล่างผมทำตามลำดับเดียวกับที่ไคลเอนต์แสดง: การตั้งค่า ปลายทาง การเปลี่ยนผ่าน แล้วจึงหลักฐาน
การทดสอบตอบคำถามแคบ ๆ ข้อเดียว: ในช่วงการเปลี่ยนผ่านนี้ แอปพลิเคชันนี้เข้าถึงเครือข่ายนอกอุโมงค์ได้หรือไม่ มันไม่ได้บอกอะไรเลยว่านโยบายที่เหลือสมเหตุสมผลหรือไม่ ให้ขอบเขตเล็กขนาดนั้นแล้วผลลัพธ์ก็คุ้มค่าที่จะบันทึก
หาสวิตช์และขอบเขตของมันในไคลเอนต์
เปิดไคลเอนต์และหาการตั้งค่าการบล็อกก่อนที่คุณจะเปลี่ยนสถานะเครือข่ายใด ๆ ผู้ผลิตเรียกมันต่างกัน: สวิตช์ตัดการเชื่อมต่อ โหมดล็อกดาวน์ ล็อกเครือข่าย บล็อกทราฟฟิกนอกอุโมงค์ ป้ายบอกได้น้อยกว่าตัวเลือกที่อยู่ข้างใน สิ่งที่สำคัญคือการบล็อกใช้ตลอดเวลาหรือเฉพาะเมื่อแอปตัดสินว่าอุโมงค์เพิ่งล้มเหลว และครอบคลุมทุกแอปหรือรายการที่เลือกไว้
จากนั้นเขียนรายการการเปลี่ยนผ่านที่ไคลเอนต์ของคุณทำได้จริง การตัดการเชื่อมต่อที่ผู้ใช้เริ่ม การออกจากแอป และการสูญเสียการติดต่อกับเซิร์ฟเวอร์เป็นเส้นทางโค้ดสามแบบที่แตกต่างกันในไคลเอนต์ส่วนใหญ่ และพวกมันไม่ได้ใช้้นโยบายการบล็อกร่วมกัน บางตัวปล่อยการบล็อกเมื่อแอปปิด บางตัวปล่อยกฎตัวกรองไว้จนกว่าอะไรบางอย่างจะลบมันออก อ่านเอกสารอ้างอิงการตั้งค่าของผู้ผลิตสำหรับบิลด์ที่คุณใช้แทนการเดา แล้วเขียนว่าคุณกำลังทดสอบอันไหนในสามอย่าง
บันทึกโปรไฟล์ด้วย: โปรโตคอล ตระกูลที่อยู่ และเปิดใช้อุโมงค์แบบแบ่งหรือไม่ ข้ออ้างว่าครอบคลุมทั้งอุปกรณ์นั้นไม่มีความหมายถ้าโปรไฟล์จงใจยกเว้นแอปบางตัว และการยกเว้นที่คุณตั้งค่าเองไม่ใช่การรั่วไหล เอกสารอ้างอิงการตั้งค่าของ OpenVPN Connect เป็นหน้าที่บอกว่าสวิตช์ตัวไหนเปลี่ยนพฤติกรรมไหน แม้ว่าป้ายจะต่างกันตามไคลเอนต์
เลือกปลายทางล่อที่ทำงานได้แม้ไม่มีอุโมงค์
หน้าล่อต้องมีสองคุณสมบัติ และการข้ามอย่างใดอย่างหนึ่งทำให้ผลอ่านไม่ได้ ต้องเข้าถึงได้โดยตรงเมื่ออุโมงค์ลงและปิดการบล็อก ไม่อย่างนั้นการที่มันหยุดตอบอาจหมายความว่าโฮสต์หายไปเท่านั้น และต้องไม่ต้องใช้ล็อกอิน คุกกี้ หรือการชำระเงิน เพื่อให้การรั่วไหลมีค่าใช้จ่ายเป็นบรรทัดล็อกหนึ่งบรรทัดไม่ใช่เซสชัน
หน้าแบบคงที่บนโฮสต์ที่คุณควบคุมเป็นตัวเลือกที่สะอาดที่สุด เครื่องเสมือนสำรองที่รันเซิร์ฟเวอร์ HTTP ธรรมดาก็เกือบดีเท่า และหน้าเช็กการเชื่อมต่อสาธารณะก็ใช้ได้ถ้าคุณยอมรับว่าความพร้อมใช้ของมันอยู่นอกการควบคุมของคุณ บันทึกที่อยู่ พอร์ต ตระกูลที่อยู่ และคำขอต้องค้นหาชื่อหรือไม่ เพราะแต่ละอย่างจะกลายเป็นตัวแปรที่คุณอาจต้องแยกออกในภายหลัง
สร้างเส้นฐานก่อนแตะสวิตช์ เมื่ออุโมงค์ขึ้น หน้าล่อต้องตอบผ่านอุโมงค์ ซึ่งพิสูจน์ว่าเส้นทางตามนโยบายทำงาน เมื่ออุโมงค์ลงและปิดการบล็อก มันต้องตอบโดยตรง ซึ่งพิสูจน์ว่าปลายทางยังมีชีวิต หลังจากนั้นความล้มเหลวในสถานะที่ถูกบล็อกจึงบอกอะไรคุณได้
ทำการเปลี่ยนผ่านตามลำดับที่กำหนด
ทำการเปลี่ยนผ่านทีละอย่างและให้เวลาสักสองสามวินาทีให้เข้าที่ เพราะไคลเอนต์มักรื้อและสร้างกฎใหม่ในช่วงนั้น การรันการตรวจสอบสั้น ๆ แบบเดิมทุกครั้งทำให้การสังเกตเทียบกันได้:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
แถวการออกจากแอปสมควรได้รับการรันแยก แม้คุณจะไม่เคยปิดไคลเอนต์ในการใช้งานปกติ ถ้าการบล็อกถูกปล่อยเมื่อออก การแครชหรือการอัปเดตแบบบังคับก็ให้การเปิดเผยแบบเดียวกัน และนั่นเป็นข้อเท็จจริงเกี่ยวกับการติดตั้ง ไม่ใช่เกี่ยวกับความอดทนของคุณ บน Windows ตัวตรวจสอบที่เทียบเท่าคือ Resolve-DnsName decoy.example และ curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/
แยกการบล็อกออกจากตัวแก้ไขชื่อที่เสีย
หน้าที่โหลดไม่ขึ้นมีหลายสาเหตุ และมีเพียงสาเหตุเดียวเท่านั้นที่คือสวิตช์ทำงาน ถ้าชื่อแก้ไม่ได้ คุณได้เรียนรู้ว่า DNS ถูกบล็อกหรือเสีย ไม่ใช่เส้นทางข้อมูลถูกบล็อก ทดสอบที่อยู่แบบตัวอักษรด้วย เพื่อให้คำตอบไม่ขึ้นกับการแก้ชื่อเลย
รหัสออกของ curl แยกกรณีเหล่านั้นออกจากกัน 6 คือการแก้ชื่อล้มเหลว 7 หมายถึงการเชื่อมต่อถูกปฏิเสธ 28 คือหมดเวลา เส้นทางที่ถูกบล็อกมักปรากฏเป็นการหมดเวลาหรือการปฏิเสธต่อที่อยู่แบบตัวอักษร ขณะที่การบล็อกเฉพาะ DNS จะเหลือ 6 ไว้และซ่อนอย่างอื่นทั้งหมด หน้าที่แคชไว้หรือพอร์ทัลกักขังหลอกตา ดังนั้นหลักฐานคือรหัสออก ไม่ใช่หน้าจอ
ทำการทดสอบซ้ำบน IPv6 ด้วยที่อยู่แบบตัวอักษร การบล็อกที่ครอบ IPv4 แต่เพิกเฉย IPv6 นั้นพบได้บ่อยพอที่จะได้บรรทัดของตัวเองในบันทึกของคุณ และไคลเอนต์ที่ปิด IPv6 นอกอุโมงค์ควรล้มเหลวอย่างสะอาดบนทั้งสองตระกูล
บันทึกขอบเขตที่ผลลัพธ์ครอบคลุม
เมื่ออุโมงค์กลับมา ยืนยันการฟื้นตัว: หน้าล่อตอบผ่านอุโมงค์ ตัวแก้ไขชื่อคืนคำตอบ และนโยบายอยู่ที่เดิมที่คุณวางไว้ จากนั้นย้อนการทดลอง กฎไฟร์วอลล์ชั่วคราว เส้นทางดีบัก หรือโปรไฟล์ทดสอบที่ทิ้งไว้จะทำให้การรันครั้งถัดไปสับสนและอาจอยู่ได้นานกว่าแอป
การวนหนึ่งรอบครอบคลุมบิลด์ไคลเอนต์หนึ่ง โปรไฟล์หนึ่ง การเปลี่ยนผ่านหนึ่ง และตระกูลที่อยู่หนึ่ง ดังนั้นเขียนสี่อย่างนั้นพร้อมผลลัพธ์:
- บิลด์ไคลเอนต์และแพลตฟอร์ม และการตั้งค่าเป็นรายโปรไฟล์หรือทั้งระบบ
- โปรไฟล์ โปรโตคอล และการยกเว้นทันเนลแบบแบ่งใด ๆ
- การเปลี่ยนผ่านที่ทดสอบ และวิธีที่คุณกระตุ้นมัน
- ตระกูลที่อยู่และ DNS พร้อมรหัสออกของ curl สำหรับสถานะที่ถูกบล็อกและไม่ถูกบล็อก
ถ้ามีบรรทัดใดว่าง การทดสอบยังไม่จบ การโรมมิ่งหมายถึงการทำแถวการเปลี่ยนเครือข่ายซ้ำ การรีบูตโดยไม่มีคนเฝ้าหมายถึง การตรวจสอบว่ากฎกลับมาหรือไม่ และนั่นเป็นคำถามเกี่ยวกับลำดับการคืนสภาพ ไม่ใช่เกี่ยวกับสวิตช์ ทำซ้ำลำดับหลังการอัปเดตไคลเอนต์ เพราะสวิตช์ แทบไม่เปลี่ยน ขณะที่พฤติกรรมข้างหลังเปลี่ยน เก็บหน้าล่อไว้: ไม่มีอะไรต้องหมุน และการตรวจครั้งต่อไปใช้เวลาห้านาที