ทราฟฟิกบน eth0 ไม่ได้หมายความว่าอุโมงค์ VPN รั่ว

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

ทุกแพ็กเก็ตของอุโมงค์ยังคงข้ามสาย

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

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

จับภาพอินเทอร์เฟซทีละหนึ่ง

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

sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194

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

ถามเคอร์เนลว่าเลือกอุปกรณ์ใด

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

ผลลัพธ์ที่แยกออกเป็นสองทางคือสิ่งที่พบได้บ่อย: IPv4 ไปยังอุโมงค์และ IPv6 ไปยังอะแดปเตอร์กายภาพ เพราะโปรไฟล์ดันเส้นทาง IPv4 เท่านั้น นั่นคือการรั่วไหลจริง และมองไม่เห็นในการจับภาพเฉพาะ IPv4 กรอง IPv6 และเฝ้าดูที่อยู่ที่ไม่ใช่เซิร์ฟเวอร์และไม่ใช่ link-local

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

เมื่อการจับภาพเป็นการรั่วไหลจริง

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

แก้เส้นทางหรือข้อยกเว้น ไม่ใช่ไฟร์วอลล์ จากนั้นจับภาพอีกครั้งจากการเชื่อมต่อใหม่และตรวจ IPv4 กับ IPv6 แยกกัน เพราะการแก้อย่างหนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกอย่างคู่มือ tcpdumpอธิบายตัวเลือกอินเทอร์เฟซและทิศทางที่ใช้ข้างต้น