การตอบกลับ ARP มีที่อยู่ MAC ไม่ถูกต้อง

ฉันมีหุ่นยนต์ที่ใช้ linux พร้อมอะแดปเตอร์แบบมีสายและไร้สาย เมื่อฉันบูทขึ้นมันจะเชื่อมต่อกับอุปกรณ์ไร้สาย เมื่อฉันกำหนด IP ให้กับสาย (ทั้งแบบคงที่หรือกับ DHCP) ดูเหมือนว่าใช้งานได้ เช่นเดียวกับifconfigแสดง IP ที่เหมาะสมและrouteแสดงเส้นทางที่เหมาะสม อย่างไรก็ตามเมื่อฉันทำการร้องขอ ARP ของ IP แบบใช้สายการตอบกลับ ARP จะมี MAC ไร้สาย

??? ไม่มีบริดจ์ที่รันบนหุ่นยนต์ดังนั้นทำไมฉันไม่รับ MAC แบบใช้สาย ???

เมื่อสายไฟถูกตัดการเชื่อมต่อ IP แบบผ่านสายตอบกลับการ ping ...

ทำไมหุ่นยนต์ถึงตอบผ่านอินเตอร์เฟซไร้สายเพื่อร้องขอ IP บนสาย?

แก้ไข: ทั้งอะแดปเตอร์แบบมีสายและไร้สายบนเครือข่ายย่อย IP เดียวกัน ฉันขอ ARP จากคอมพิวเตอร์ (ลองกับคอมพิวเตอร์ที่แตกต่างกัน) ในเครือข่ายย่อย IP เดียวกัน

เอาต์พุต ifconfig ที่เกี่ยวข้อง:

eth0      Link encap:Ethernet  HWaddr 00:01:C0:04:BD:F7  
          inet addr:192.168.0.110  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
ra0       Link encap:Ethernet  HWaddr 24:3C:20:06:3E:6D  
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:59 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:31023598 (29.5 MiB)  TX bytes:85640627 (81.6 MiB)

เส้นทางที่เกี่ยวข้องเอาท์พุท:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ra0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

มันเป็น linux ที่มีการตัดทอนมากดังนั้นฉันไม่มีเครื่องมือเช่น artptables, iptables, sysctl, brctl เป็นต้น

แก้ไข: แผนภาพตามที่ร้องขอ

แก้ไข: ฉันทิ้งการจราจรและดูตาราง ARP คำร้องขอ ARP ที่ 192.168.0.110 ส่งคืนการตอบกลับ ARP ที่มี 24: 3C: 20: 06: 3E: 6D MAC ต้นทางของแพ็กเก็ตตอบกลับ ARP ยังมี 24: 3C: 20: 06: 3E: 6D ฉันได้ลองเล่นซอกับ _filter, _ignore และ _announce ตามที่กล่าวถึงที่นี่แต่ก็ไม่มีประโยชน์

แก้ไข: การตั้งค่าเกตเวย์ (บนทั้งสองอินเตอร์เฟส) ไม่สร้างความแตกต่าง (อย่างที่ควรเป็น)

แก้ไข: สิ่งนี้ทำงานได้ดีในระบบปฏิบัติการรุ่นก่อนหน้า (ขึ้นอยู่กับ openembedded) เป็นไปได้ไหมที่พวกเขาจะเปลี่ยนแปลงบางสิ่ง?

สิ่งที่คุณเห็นคือพฤติกรรมปกติเมื่อคุณมีสองอินเตอร์เฟสในเครือข่ายเดียวกัน มันเป็นเรื่องที่อธิบายไว้ในบทความนี้ LWN

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

อย่างไรก็ตามผมเชื่อว่าคำตอบจะโกหกปัญหาของคุณได้อย่างถูกต้องในการจัดการและrp_filter arp_filterเอกสารสำหรับแต่ละรายการมีอยู่ด้านล่าง

ฉันขอแนะนำให้ลองสิ่งนี้ก่อน:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

คุณอาจต้องทำการเปลี่ยนแปลงนี้เช่นกัน:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

rp_filter - บูลีน
    1 - ทำการตรวจสอบความถูกต้องของแหล่งข้อมูลโดยใช้เส้นทางที่กลับด้านตามที่ระบุใน RFC1812
        ตัวเลือกที่แนะนำสำหรับโฮสต์ homed เดี่ยวและเครือข่าย stub
        เราเตอร์ อาจทำให้เกิดปัญหาในการซับซ้อน (ไม่วนซ้ำฟรี)
        เครือข่ายที่ใช้โปรโตคอลที่ไม่น่าเชื่อถือช้า (ประเภทของ RIP)
        หรือใช้เส้นทางคงที่

    0 - ไม่มีการตรวจสอบแหล่งที่มา

    conf / all / rp_filter ต้องถูกตั้งค่าเป็น TRUE เพื่อทำการตรวจสอบแหล่งที่มา
    บนอินเตอร์เฟส

    ค่าเริ่มต้นคือ 0 โปรดทราบว่าการกระจายบางอย่างเปิดใช้งาน
    ในสคริปต์เริ่มต้น

arp_filter - บูลีน
    1 - ช่วยให้คุณมีอินเตอร์เฟซเครือข่ายหลายอย่างในเวลาเดียวกัน
    subnet และรับ ARP สำหรับแต่ละอินเตอร์เฟส
    ขึ้นอยู่กับว่าเคอร์เนลจะกำหนดเส้นทางแพ็กเก็ตจากหรือไม่
    ARP'd IP ออกจากอินเทอร์เฟซนั้น (ดังนั้นคุณต้องใช้แหล่งที่มา
    การกำหนดเส้นทางพื้นฐานเพื่อให้สิ่งนี้ทำงานได้) ในคำอื่น ๆ จะช่วยให้การควบคุม
    บัตรใด (โดยปกติ 1) จะตอบคำขอ ARP

    0 - (ค่าเริ่มต้น) เคอร์เนลสามารถตอบสนองต่อคำขอ ARP พร้อมที่อยู่
    จากอินเทอร์เฟซอื่น ๆ สิ่งนี้อาจดูเหมือนผิดปกติ แต่มักเกิดขึ้น
    ความรู้สึกเพราะมันเพิ่มโอกาสในการสื่อสารที่ประสบความสำเร็จ
    ที่อยู่ IP นั้นเป็นเจ้าของโดยโฮสต์ที่สมบูรณ์บน Linux ไม่ใช่
    อินเตอร์เฟสเฉพาะ สำหรับการตั้งค่าที่ซับซ้อนเช่นโหลด - เท่านั้น
    การปรับสมดุลพฤติกรรมนี้จะทำให้เกิดปัญหาหรือไม่

    arp_filter สำหรับส่วนต่อประสานจะถูกเปิดใช้งานหากอย่างน้อยหนึ่งตัว
    conf / {all, อินเตอร์เฟส} / arp_filter ถูกตั้งค่าเป็น TRUE
    มันจะถูกปิดการใช้งานเป็นอย่างอื่น

สำหรับการรักษาอย่างละเอียดมากขึ้นดูบทความนี้:

http://www.embedded-bits.co.uk/tag/rp_filter/

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

ผู้ใช้ส่วนใหญ่จะไม่กำหนดค่าอุปกรณ์ด้วยวิธีนี้ แต่ในทางทฤษฎีแล้วมันควรจะเป็นไปได้

ก่อนอื่นเราทำการหยิบยกปัญหากับเราเตอร์ Netgear เพราะพวกเขาจะรายงานข้อขัดแย้งของที่อยู่ IP - ที่อยู่ MAC 2 รายการใช้ IP เดียวร่วมกัน เห็นได้ชัดว่าเราเตอร์จะเริ่มทำงานได้ไม่ดีในสถานการณ์นี้และทำให้เครือข่ายผู้ใช้สับสน

ฉันสร้างเครือข่ายส่วนตัวที่มีเฉพาะเราเตอร์ (อีเธอร์เน็ต + wifi) แล็ปท็อป windows (อีเธอร์เน็ตเท่านั้น) และอุปกรณ์ฝังตัว (อีเธอร์เน็ต + wifi) ใช้ wireshark, tcpdump บนอุปกรณ์และ arp บน windows ฉันสามารถเห็นการทำงานต่อไปนี้:

1. Ifconfig บนอุปกรณ์จะแสดงที่อยู่ wln และ Ethernet IP และ MAC address ที่แตกต่างกันอย่างชัดเจน
2. บางครั้ง (ไม่ค่อยมาก) และ arp –a จาก windows แสดงชุดค่า IP-MAC ที่ถูกต้อง
3. เวลาส่วนใหญ่ arp –a จาก windows แสดงทั้ง wln และ eth0 มีที่อยู่ MAC เดียวกัน
4. เมื่อกระตุกทั้ง wln หรือ eth0 จาก windows การตอบสนองการ ping มาจาก wln และไม่ค่อยมาจาก eth0 tcpdump แสดง wln ที่ตอบสนองต่อ 1 จาก 4 pings เท่านั้น (เช่น)
5. เมื่อ windows ส่งข้อความ arp“ who have” สำหรับ eth0 IP - ทั้งอินเตอร์เฟส eth0 และ wln ตอบว่าพวกเขามี IP นั้น

ฉันเชื่อว่ารายการ 3 เกิดจากรายการ 5 ตาราง arp ยุ่งเหยิงเพราะ wln กำลังตอบกลับข้อความ arp ที่ควรมีเฉพาะ eth0 เท่านั้น ฉันเชื่อว่ารายการ 4 นั้นเกิดจากรายการที่ 5 Ping ถูกส่งโดยอ้างอิงจากที่อยู่ MAC และเนื่องจากข้อความ arp ล่าสุดที่ได้รับมาจาก wln ว่ามี IP eth0 การส่ง Ping จะถูกส่งไปยังอินเตอร์เฟส wln อย่างไม่ถูกต้อง

หลังจากการขุดและทดสอบมากวิธีแก้ปัญหานั้นง่ายมากจริง ๆ ดูบทความนี้ - http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

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

การตั้งค่านี้แก้ไขปัญหา:

echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

คำอธิบาย:

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied

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

ติดตามความคิดเห็นของ Insyte

ให้ตั้งชื่อบางอย่าง:

• PC1 - บนขวา
• PC2 - บนซ้าย
• PC3 - ล่างซ้าย

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

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

สถานการณ์การปรับใช้ของฉันคือ:

[RTR] | ------------ eth0 --- [เซิร์ฟเวอร์]
| -------- | switch1 | ----- eth1 ----- [เซิร์ฟเวอร์]

มันเป็นสวิตช์เดียวกันที่ทั้งสองอินเตอร์เฟสเชื่อมต่อ หวังว่ามันจะช่วยคุณได้

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

เพื่อป้องกันไม่ให้สิ่งต่อไปนี้ได้ผลสำหรับฉัน

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

วางไว้ที่ใดที่หนึ่งบนหุ่นยนต์ของคุณเพื่อให้คุณสามารถนำไปใช้ในการบูตได้

คำแนะนำ: ฉันขอแนะนำให้คุณกำหนดค่าเครือข่ายย่อยที่แตกต่างกันสองตัว (เช่น 192.168.1.x / 24 บน ra0 และ 192.168.2.x / 24 กับ eth0) คุณสามารถใช้นามแฝง IP บนพีซีของคุณและหุ่นยนต์ของคุณจะสามารถเข้าถึงได้ผ่านทางใด ๆ ของสอง IP คุณไม่สามารถมีเส้นทางขาออกสองเส้นทางสำหรับซับเน็ตเดียวกันบนโฮสต์เดียวกัน ไม่เว้นแต่จะมีบางอย่างที่ทำให้หุ่นยนต์ของคุณชอบมากกว่ากัน หุ่นยนต์ของคุณสามารถใช้เส้นทางเดียวเท่านั้นในการส่งแพ็กเก็ตออกมา

การอ่านบางส่วน: arp_announce , arp_ignore

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

route add default gw 192.168.0.1