หน้าจอ iftop พิสูจน์อะไรได้และไม่ได้เกี่ยวกับ VPN

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

สามเงื่อนไขกำหนดความหมายของหน้าจอ

เงื่อนไขคือ อินเทอร์เฟซใดถูกแสดง ตัวกรองและเครื่องมือเองซ่อนอะไร และการทดสอบได้ลงมือทำอะไรจริง ๆ ตอบตามลำดับนั้น เพราะความผิดพลาดในข้อแรกทำให้อีกสองข้อไม่มีความหมาย

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

เงื่อนไขข้อแรก: อินเทอร์เฟซใดถูกแสดง

iftop รับอินเทอร์เฟซอย่างชัดเจนด้วย -i และคู่มือของมันอธิบายพฤติกรรมเมื่อคุณไม่ระบุ: มันเลือกหนึ่งตัว ซึ่งอาจเป็นอุปกรณ์ที่ดูเหมือนภายนอกแทนที่จะเป็นอุโมงค์ ค่าเริ่มต้นนั้นสมเหตุสมผลสำหรับเครื่องมือวัดแบนด์วิดท์และไม่ดีสำหรับการทดสอบการรั่วไหล

ระบุอินเทอร์เฟซเสมอ และจดไว้ข้างผลลัพธ์ ภาพหน้าจอที่ไม่มีชื่ออินเทอร์เฟซไม่สามารถทำซ้ำได้

เงื่อนไขข้อที่สอง: ตัวกรองและเครื่องมือซ่อนอะไร

iftop ยอมรับนิพจน์ตัวกรอง และการไหลที่ตัวกรองตัดออกจะมองไม่เห็นเพราะโครงสร้าง ไม่ใช่เพราะไม่มีการไหล เครื่องมือยังค้นหาชื่อโฮสต์โดยค่าเริ่มต้นเพื่อติดป้ายที่อยู่ และการค้นหาเหล่านั้นสร้างการรับส่ง DNS ของตัวเอง คือการรับส่งที่คุณไม่ได้ตั้งใจจะสังเกต -n ปิดการค้นหาและทำให้การแสดงผลเป็นตัวเลข การซ่อนแถว DNS ภายหลังไม่เหมือนกับการไม่สร้างคำถาม

ความต่างนี้ควรพูดตรง ๆ เพราะปรากฏในเครื่องมืออื่นด้วย การปราบการแสดงผลของกิจกรรมหนึ่งไม่เหมือนกับการป้องกันกิจกรรมนั้น หากการค้นหา DNS เป็นส่วนหนึ่งของสิ่งที่คุณทดสอบ ให้รันการทดสอบโดยปิดการค้นหา เพื่อให้การสังเกตไม่ปนเปื้อนจากผู้สังเกต

เงื่อนไขข้อที่สาม: การทดสอบได้ลงมือทำอะไรจริง ๆ

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

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

DNS สมควรได้รับการสังเกตของตัวเอง ผู้รับคำถามและเส้นทางที่คำถามเดินทางเป็นสองข้อเท็จจริง และหน้าจอแบนด์วิดท์ไม่แสดงทั้งสองอย่าง

การใช้ iftop เป็นหลักฐานสนับสนุน

เมื่อนั้น iftop จึงเพิ่มคุณค่า และเพิ่มในฐานะการยืนยัน sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" แสดงว่าการไหลที่คาดไว้ปรากฏบนอินเทอร์เฟซที่คาดไว้หรือไม่ พร้อมจำนวนไบต์ที่ทำให้ข้ออ้างเรื่องความนิ่งตรวจสอบได้

เปรียบเทียบกับ ss -tnp สำหรับมุมมองระดับซ็อกเก็ต และ ip route get สำหรับเส้นทางที่เคอร์เนลจะเลือก แล้วคุณมีสามการสังเกตของคำขอเดียวแทนความประทับใจหนึ่งอย่างเกี่ยวกับเครื่องหนึ่งเครื่อง คู่มือ iftop บันทึกการเลือกอินเทอร์เฟซ ไวยากรณ์ตัวกรอง และพฤติกรรมการค้นหา ซึ่งเป็นสามสิ่งที่การทดสอบการรั่วไหลขึ้นอยู่ด้วย หน้าจอแบนด์วิดท์ระบุตำแหน่งของกิจกรรม ส่วนเส้นทาง ข้อยกเว้น และพฤติกรรมเมื่อล้มเหลวเป็นตัวตัดสินว่ากิจกรรมนั้นเป็นไปตามข้อกำหนดหรือไม่