ตรวจสอบ VPN แบบไม่มีหน้าจอ: ทีละโฟลว์ พร้อมหลักฐาน
กล่องที่ไม่มีหน้าจอต้องมีคำขอที่อ่านคำตอบได้ ทดสอบแต่ละตระกูลแอดเดรส บริบท และปลายทาง แล้วบันทึกว่าผลลัพธ์ไม่ได้ครอบคลุมอะไร
บนกล่องที่ไม่มีหน้าจอไม่มีเบราว์เซอร์ให้เปิดและไม่มีกุญแจให้ดู ดังนั้นการตรวจสอบต้องเป็นคำขอที่คุณอ่านคำตอบได้ ฟังดูไม่สำคัญจนกว่าคุณจะสังเกตว่า ผลลัพธ์แอดเดรสขาออกเพียงผลเดียว ถูกใช้รับรองอุปกรณ์ที่รันบริการเป็นสิบ สองตระกูลแอดเดรส และพร็อกซี วิธีด้านล่างสร้างหลักฐานจำกัดทีละชิ้น ในบริบทเดียวกับที่เวิร์กโหลดทำงานจริง
ตัดสินใจว่าการทดสอบต้องพิสูจน์อะไร
ก่อนรันอะไร เขียนความคาดหวังไว้หนึ่งบรรทัด: โฟลว์ใด ผ่านอินเทอร์เฟซใด ไปยังปลายทางใด และควรเห็นอะไรที่อีกฝั่ง การทดสอบที่ไม่มีความคาดหวังที่ประกาศไว้ให้ตัวเลขที่ไม่มีใครตีความได้
รูปแบบที่มีประโยชน์ที่สุดระบุปลายทางที่ได้รับอนุมัติซึ่งรายงานแอดเดรสต้นทางที่มันเห็น
ปลายทางนั้นเป็นส่วนเดียวที่คุณต้องจัดเตรียม ที่เหลือคือการสังเกตฝั่งไคลเอนต์ และการสังเกตฝั่งไคลเอนต์ล้มเหลวในแบบที่น่าสนใจ
รันการสังเกตในบริบทที่ถูกต้อง
เชลล์ของผู้ดูแลระบบไม่ใช่สภาพแวดล้อมของเวิร์กโหลด อาจมีตัวแปรพร็อกซีอื่น ตารางเส้นทางอื่นในเนมสเปซอื่น หรือไฟล์สภาพแวดล้อมของผู้ใช้อื่น รันการทดสอบในบริบทโฮสต์ คอนเทนเนอร์ เนมสเปซ หรือบริการเดียวกับสิ่งที่คุณตรวจสอบ มิฉะนั้นคุณกำลังวัดเชลล์ของคุณเอง
บนโฮสต์ปกติหมายถึงผู้ใช้คนเดียวกันและยูนิตเดียวกัน ในสภาพแวดล้อมคอนเทนเนอร์หมายถึงการเข้าเนมสเปซเครือข่ายของคอนเทนเนอร์แทนการทดสอบจากโฮสต์ บนบริการ systemd อาจหมายถึงยูนิตชั่วคราวที่มีการตั้งค่าเดียวกัน
คำขอที่ตามมาจะมีความหมายก็ต่อเมื่อคุณอยู่ในบริบทที่ถูกต้อง
ตรวจสอบตระกูลแอดเดรสแยกกัน
ขอแต่ละตระกูลอย่างชัดเจน เพราะคำขอ IPv4 ที่สำเร็จไม่ได้ฝึกเส้นทาง IPv6 เลย ตัวเลือก --ipv4 และ --ipv6 บังคับการเลือก และความแตกต่างระหว่างผลลัพธ์ทั้งสองก็เป็นข้อมูลในตัว
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceคำขอ IPv6 ที่ล้มเหลวไม่ใช่หลักฐานของการบล็อกที่มีประสิทธิผล อาจหมายถึงปลายทางไม่มีแอดเดรส IPv6 DNS ไม่ได้ส่งอะไรที่ใช้ได้กลับมา หรืออุปกรณ์ไม่มีเส้นทาง IPv6 เลย อ่านความล้มเหลวก่อนสรุป คำขอ IPv6 ที่สำเร็จผ่านอุโมงค์เป็นผลลัพธ์เดียวที่พิสูจน์ว่าเส้นทาง IPv6 ถูกครอบคลุม
บันทึกคำตอบทั้งสองข้างเคียงกัน อย่างใดอย่างหนึ่งเพียงอย่างเดียวคือครึ่งหนึ่งของข้อเท็จจริง
เพิ่มสี่สิ่งซึ่งการตรวจสอบขาออกมองข้าม
แอดเดรสขาออกตอบคำถามหนึ่งข้อ อีกสี่ข้อกำหนดว่าอุโมงค์ทำงานตามที่ออกแบบหรือไม่
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
นโยบายปลายทางมาก่อน: ทดสอบโฟลว์ที่ควรถูกรวมและโฟลว์ที่ควรถูกตัดออก เมื่อการออกแบบมีการแบ่ง จากนั้น DNS ซึ่งคุณตรวจเส้นทางตัวแก้จริงแทนค่าที่กำหนดไว้ เพราะคำตอบที่แคชไว้หรือการตั้งค่าที่พิมพ์ออกมาไม่ได้บอกอะไรเกี่ยวกับที่ที่คำถามใหม่ไป
พฤติกรรมเมื่อล้มเหลวต้องมีแผนและเส้นทางกู้คืนที่เก็บไว้ สังเกตคำขอใหม่ขณะอุโมงค์ไม่พร้อมใช้งาน และจำไว้ว่าการเชื่อมต่อที่เปิดอยู่เดิมไม่ใช่หลักฐานเกี่ยวกับนโยบายเมื่อล้มเหลว วงจรชีวิตมาสุดท้าย: ทำการสังเกตซ้ำหลังการเชื่อมต่อใหม่หรือรีสตาร์ตบริการหากเหตุการณ์เหล่านั้นส่งผลต่อข้อกำหนด
บันทึกหลักฐาน ไม่ใช่คำตัดสิน
สำหรับแต่ละผลลัพธ์ เก็บบริบทของโพรเซส ปลายทาง ตระกูลแอดเดรส เวลา และต้นทางที่สังเกตได้ ชุดนั้นเป็นหลักฐานจำกัดเกี่ยวกับโฟลว์ที่คุณฝึก และปกป้องได้เพราะมันบอกว่าครอบคลุมอะไร
นี่ไม่ใช่การตรวจสอบบันทึกของผู้ให้บริการ VPN และไม่ใช่ใบรับรองสำหรับทุกแอปพลิเคชันในอนาคตบนอุปกรณ์
เขียนขีดจำกัดไว้ข้างผลลัพธ์ การทดสอบที่ระบุว่าครอบคลุมอะไรไม่ได้อยู่รอดจากการทบทวน ส่วนที่อ้างว่าอุปกรณ์ได้รับการตรวจสอบแล้วไม่อยู่รอด เก็บคู่มือ curl ไว้ข้างตัวเลือกตระกูลที่คุณใช้ และเก็บตารางสี่แถวไว้กับผลลัพธ์