หนึ่งจับปริมาณการใช้งานบนอินเตอร์เฟสเสมือนได้อย่างไร


12

ฉันต้องการจับภาพทราฟฟิกบนอินเตอร์เฟสเสมือนของ Linux เพื่อการดีบัก ฉันได้รับการทดสอบด้วยveth, tunและdummyอินเตอร์เฟซประเภท; ในทั้งสามฉันมีปัญหาในการtcpdumpแสดงอะไร

นี่คือวิธีการตั้งค่าส่วนต่อประสานแบบจำลอง:

ip link add dummy10 type dummy
ip addr add 99.99.99.1 dev dummy10
ip link set dummy10 up

ในเทอร์มินัลหนึ่งดูด้วยtcpdump:

tcpdump -i dummy10

ในหนึ่งวินาทีให้ฟังด้วยnc:

nc -l 99.99.99.1 2048

ในหนึ่งในสามทำการร้องขอ HTTP ด้วยcurl:

curl http://99.99.99.1:2048/

แม้ว่าใน terminal 2 เราสามารถดูข้อมูลจากการร้องขอการแสดงอะไรขึ้นมาจากcurltcpdump

Tun / แตะกวดวิชาชี้แจงสถานการณ์บางอย่างที่เคอร์เนลอาจไม่ได้ส่งแพ็กเก็ตใด ๆ เมื่อมีการดำเนินงานเกี่ยวกับอินเตอร์เฟซท้องถิ่น:

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

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

อาจtcpdumpจะต้องผูกกับอินเตอร์เฟซในวิธีที่แตกต่างกันอย่างไร


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

@derobert ในกรณีของการ pings เคอร์เนลสามารถตอบสนอง ในกรณีของแพ็กเก็ตข้อมูลฉันคิดว่าพวกเขาจะต้อง "ไป" ส่วนต่อประสานเพื่อให้แอปพลิเคชันสามารถตอบสนองต่อพวกเขาได้
solidsnack

1
แอปพลิเคชันพูดกับเคอร์เนลโดยใช้การอ่านเขียนและอื่น ๆ แอปเครือข่ายจำนวนมากไม่จำเป็นต้องตระหนักว่ามีอินเทอร์เฟซอยู่ เพื่อให้ทราฟฟิกข้ามหนึ่งในนั้นเคอร์เนลต้องดูว่าไม่ใช่โลคอล เช่นตั้งค่าอุโมงค์ OpenVPN จากนั้นคุณสามารถจับภาพทราฟฟิกผ่าน tun0 (แน่นอนว่า tun0 เป็นวิธีพิเศษสำหรับแอพที่จะพูดกับเคอร์เนลเพื่อใช้งานอินเทอร์เฟซเครือข่ายใน userland ซึ่งเป็นสิ่งที่ OpenVPN ทำ)
derobert

คำตอบ:


8

การรับส่งข้อมูลเกิดขึ้นผ่านloส่วนต่อประสาน

เมื่อมีการเพิ่ม IP ลงในกล่องเส้นทางสำหรับที่อยู่นั้นจะถูกเพิ่มลงในตาราง 'ท้องถิ่น' เส้นทางทั้งหมดในตารางนี้กำหนดเส้นทางการรับส่งข้อมูลผ่านส่วนต่อประสานย้อนกลับ

คุณสามารถดูเนื้อหาของตาราง 'ท้องถิ่น' ดังต่อไปนี้:

ip route show table local

ซึ่งระบบของฉันมีลักษณะดังนี้:

local 10.230.134.38 dev tun0  proto kernel  scope host  src 10.230.134.38 
broadcast 10.230.134.38 dev tun0  proto kernel  scope link  src 10.230.134.38 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 172.17.0.0 dev docker0  proto kernel  scope link  src 172.17.42.1 
local 172.17.42.1 dev docker0  proto kernel  scope host  src 172.17.42.1 
broadcast 172.17.255.255 dev docker0  proto kernel  scope link  src 172.17.42.1 
broadcast 192.168.0.0 dev enp6s0  proto kernel  scope link  src 192.168.0.20 
local 192.168.0.20 dev enp6s0  proto kernel  scope host  src 192.168.0.20 
broadcast 192.168.0.255 dev enp6s0  proto kernel  scope link  src 192.168.0.20 

ดังนั้นโดยทั่วไปถ้าเราส่งเข้าชมใด ๆ เพื่อ10.230.134.38, 127.0.0.0/8, 127.0.0.1(ซ้ำซ้อน) , 172.17.42.1หรือ192.168.0.20การจราจรจะได้รับการส่งผ่านอินเตอร์เฟซที่ย้อนกลับแม้ว่า IP ที่เหล่านั้นเป็นจริงบนอินเตอร์เฟซที่แตกต่างกัน



0

สิ่งนี้ควรเป็นไปได้ด้วยการเรียกใช้ระบบที่สอง (อาจเป็น VM บนโฮสต์นั้น)

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

iptables -t nat -A OUTPUT -p tcp -d 99.99.99.1 --dport 2048 \
  -j DNAT --to-destination 1.2.3.4
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.