ตรวจสอบว่าอุโมงค์แยกทำงานจริง: ผลลัพธ์ IP ครั้งเดียวไม่ใช่การทดสอบ

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

ความเชื่อผิด: การค้นหาที่อยู่พิสูจน์ความครอบคลุม

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

หน้าแสดงที่อยู่ก็ไม่อาจแสดงเส้นทาง ตัวแปลง หรือนโยบายเมื่อล้มเหลวได้ มองมันเป็นการสังเกตครั้งเดียว ไม่ใช่คำตัดสิน

ลองทั้งการไหลที่รวมอยู่และการไหลที่ถูกยกเว้น

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

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

นี่คือเหตุผลที่การทดสอบในแอปพลิเคชันผิดอาจแสดงผลตรงข้ามกับที่ออกแบบไว้ บันทึกสี่ฟิลด์สำหรับทั้งสองฝั่งก่อนจะสรุปผลใด ๆ

เพิ่ม DNS และกรณีล้มเหลว

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

curl -s https://ifconfig.me
nslookup intranet.example

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

ทำซ้ำเมื่อสถานะเปลี่ยน

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

หากผลลัพธ์ต่างกัน ให้หาเจ้าของกฎและขั้นตอนการประมวลผลก่อนจะเปลี่ยนการตั้งค่าหลายอย่างพร้อมกัน การเปลี่ยนห้าสิ่งแล้วสังเกตผลเดียวไม่ใช่การวินิจฉัย แต่คือการตั้งค่าใหม่

ผลลัพธ์ควรยืนยันอะไร

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

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