จะดูทราฟฟิกของไคลเอนต์ OpenVPN ที่เกตเวย์ได้ที่ไหน

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

ตัดสินก่อนว่าคุณกำลังดูการจัดวางแบบใด

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

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

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

ผูกที่อยู่กับเซสชันก่อน

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

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

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

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

อ่านตารางโฟลว์บนเกตเวย์แบบกำหนดเส้นทาง

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

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

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

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

การดักจับแบบจำกัดหนึ่งครั้งเพื่อยืนยันการอ่าน

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

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

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

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

บันทึกของพร็อกซี และขอบเขตของสิ่งที่คุณเห็น

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

ตรวจสอบการตั้งค่าการบันทึกของเวอร์ชันที่ติดตั้ง แทนที่จะถือว่าทุกคำขอถูกบันทึกโดยค่าเริ่มต้น

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