Ubuntu Linux - NIC หลายตัว, LAN เดียวกัน…การตอบสนอง ARP มักจะออก NIC เดียวเสมอ


16

เราได้รับบริการอินเทอร์เน็ต AT&T U-Verse ซึ่งมีเกตเวย์ DSL ที่มุ่งมั่นอย่างมาก

เรามี 5 IP (netmask 248) แต่เกตเวย์ไม่สามารถทำสิ่งอื่นนอกเหนือจาก IP เดียว -> การทำแผนที่ที่อยู่ MAC เดียว

เรามีเครื่องไฟร์วอลล์เพียงเครื่องเดียวและเราเปลี่ยนเส้นทาง IP / พอร์ตคอมโบต่าง ๆ ไปยังสถานที่ต่าง ๆ ภายใน DMZ

วิธีการแก้ปัญหาของเราคือการมีเครื่องเสมือน VMWare บนไฟร์วอลล์ที่มี NIC เพิ่มเติมอีก 4 ตัวเพื่อรับที่อยู่ IP อีก 4 ที่ ... แต่เรามีปัญหา

เกตเวย์นั้นใช้ ARP ping เพื่อดูว่า IP ตอบสนองต่อ MAC ที่คาดหวังหรือไม่ ด้วย 4 NICs ทั้งหมดใน LAN เดียวกัน linux จึงตอบกลับคำขอ ARP สำหรับ IP ทั้งหมดโดยใช้อินเตอร์เฟสเดียว นั่นไม่ใช่สิ่งที่เกตเวย์คาดหวังและมันทำให้สับสนอีก 3 นิคส์ เกตเวย์ปฏิเสธที่จะกำหนดเส้นทางการรับส่งข้อมูลสำหรับ IP ที่ผลลัพธ์ ARP ping ไม่ใช่ MAC ที่คาดไว้

เราจะรับการตอบกลับ ARP สำหรับ IP ของ eth0 เพื่อออกไปที่ eth0, IP ของ eth1 เพื่อออกไปที่ eth1 ฯลฯ ได้อย่างไร?

แก้ไข

คำตอบของ Christopher Cashell ไม่ทำงานในสถานการณ์นี้ ฉันมีความหวังที่ดีในการอ่าน แต่ไม่ ...

แก้ไข 2

แก้ไข! ดูคำตอบของฉันด้านล่าง


PS - ไม่ 'หล่น uverse' แสดงความคิดเห็น ... U-Verse เป็น 18mbps, 3Mbps กับทุกอย่างอื่นหรือ 10Mbps ไม่น่าเชื่อถือมากผ่านทางสายเคเบิล
ดาร์รอน

@dblack: คุณลืมที่จะเพิ่มคำตอบของคุณ :)
หมดเวลาLimbăşan

ไซต์ api.recaptcha.net หยุดทำงานชั่วคราว คำตอบคือขึ้นแล้ว
darron

คำตอบ:


13

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

กล่าวโดยย่อคุณต้องการตั้งค่าพารามิเตอร์เหล่านี้:

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

สิ่งเหล่านี้ควรพร้อมใช้งานเมื่อใช้เคอร์เนล Linux ซีรีย์ 2.6 ที่ทันสมัย ตรวจสอบและให้แน่ใจว่าคุณมี '/ proc / sys / net / ipv4 / conf / / arp_announce' และ / proc / sys / net / ipv4 / conf / / arp_ignore 'อยู่ในระบบของคุณ

พารามิเตอร์ 'arp_filter' จะทำงานเฉพาะเมื่อที่อยู่ IP ต่างๆของคุณแบ่งปันส่วน LAN แต่ใช้เครือข่ายย่อย IP ที่แตกต่างกัน หากพวกเขาแชร์เครือข่ายย่อย IP ด้วยคุณต้องใช้ 'arp_ignore' และ 'arp_announce' ดังที่กล่าวมา

(ฉันเชื่อว่าคุณอาจต้องตั้งค่า 'arp_filter' กลับเป็น '0' ด้วย)


เกิดอะไรขึ้นกับ arp_filter มันเป็นวิธีแก้ปัญหาต้น ARP (2003?) แต่ดูเหมือนจะไม่ทำงานตามที่อธิบายไว้อย่างน้อยใน Centos 5 arp_ignore และ arp_announce ดูเหมือนจะดี
pcapademic

วิธีแก้ไขปัญหานี้ดูเหมือนจะใช้งานได้ในระดับ ARP เท่านั้น หากไม่มีการตั้งค่าเส้นทางเพิ่มเติมไฟร์วอลล์อาจยังเลือกบัตรขาออกผิด (และ MAC) สำหรับการรับส่งข้อมูล IP ของตัวเอง แต่จะ (ยัง) รับการรับส่งข้อมูล IP ขาเข้าบนการ์ดด้านขวานำไปสู่เส้นทางที่ไม่สมมาตรและ rp_filter
AB

8

ตกลงนี่เป็นวิธีแก้ปัญหา ก่อนสรุป:

นี่คือแผนเครือข่ายพื้นฐานของฉัน:

 eth0 10.10.10.2 netmask 255.255.255.248
 eth1 10.10.10.3 netmask 255.255.255.248
 eth2 10.10.10.4 netmask 255.255.255.248
 eth3 10.10.10.5 netmask 255.255.255.248

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

ก่อนอื่นให้ส่งคำขอ ARP ออกอากาศไปที่สิ่งเหล่านี้ เนื่องจาก IP ทั้งหมด 4 รายการเป็นที่อยู่ภายในเครื่องที่ถูกต้องทั้ง 4 อินเตอร์เฟสจะพยายามตอบกลับ

1) ติดตั้งarptables เพิ่มสถานที่แห่งนี้ในระหว่างการบู๊ต ( /etc/rc.localที่นี่):

arptables -F INPUT
arptables -A INPUT -i eth0 --destination-ip ! 10.10.10.2 -j DROP
arptables -A INPUT -i eth1 --destination-ip ! 10.10.10.3 -j DROP
arptables -A INPUT -i eth2 --destination-ip ! 10.10.10.4 -j DROP
arptables -A INPUT -i eth3 --destination-ip ! 10.10.10.5 -j DROP

การทำเช่นนี้จะช่วยป้องกันไม่ให้มีการออกอากาศไปยังส่วนต่อประสานที่ไม่ถูกต้อง ดังนั้นอินเทอร์เฟซที่ถูกต้องจะเป็นเพียงการตอบกลับเท่านั้น

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

ตัวเลือก sysctl rp_filterดูเหมือนจะปฏิเสธแพ็กเก็ตตอบกลับ ARP ขาออกหากอยู่ในอินเตอร์เฟสที่ไม่ถูกต้อง ดังนั้น...

2) ปิดการใช้งานrp_filter

บน Debian / Ubuntu, ที่นี้หมายถึงการแสดงความคิดเห็นออกมาทั้งสองrp_filterเส้นใน/etc/sysctl.d/10-network-security.conf

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

ถ้าฉันจะเพิ่มอินเตอร์เฟซที่อื่นและต้องป้องกันการปลอมแปลงที่อาจจะสามารถฝีมือบางarptables / iptablesรายการที่จะทำในสิ่งเดียวกัน


5

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

การแก้ปัญหาเป็นตัวเลือก sysctl ในขณะที่ฉันจำได้ว่าสิ่งที่คุณกำลังมองหาคือ:

net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1

ที่จะแก้ไขปัญหาให้คุณ เพียงแค่เพิ่มเข้าไปใน /etc/sysctl.conf และเรียกใช้ ' sysctl -p' (หรือเรียกใช้แต่ละบรรทัดเป็นอาร์กิวเมนต์ของsysctl -w''

นี่จะทำให้ Linux ตอบสนองต่อการร้องขอ ARP บนอินเทอร์เฟซที่มีการกำหนดที่อยู่ IP ให้เท่านั้น


อืม ... น่าเสียดายที่มันไม่ทำงาน ฉันได้วางสิ่งนั้นลงใน sysctl.conf แล้วเรียกใช้ sysctl แม้บูตใหม่ไม่มีการเปลี่ยนแปลง ฉันสามารถใส่ตัวเลือกใน / proc และดูว่าพวกมันถูกตั้งค่าแล้ว แต่ถ้าฉัน arping จากกล่องอื่นการตอบสนองทั้งหมดมาจาก MAC เครื่องเดียวกัน อินเตอร์เฟซที่มีทั้งหมดในเครือข่ายเดียวกัน (ออกอากาศเดียวกัน ฯลฯ ) ...
ดาร์รอน

1
นี่เป็นวิธีแก้ไขที่ถูกต้องหากอินเตอร์เฟสอยู่ในเครือข่ายเดียวกัน แต่มีที่อยู่ในซับเน็ตต่างกัน ยืนยันการทำงานแล้ว
Alastair Irvine

1

คำตอบที่ยอมรับร่วมกับสิ่งนี้: http://www.linuxquestions.org/questions/linux-networking-3/multiple-interfaces-all-traffic-flows-through-just-one-38-538701/

ที่ซึ่งเส้นทางแบบสแตติกใช้เพื่อสื่อสารกับ IP ที่ต้องการผ่านทางอินเตอร์เฟสบางตัวสร้างโซลูชันที่ทรงพลังและเรียบง่ายสำหรับปัญหาที่คล้ายกันที่ฉันมี


0

คุณสามารถบริดจ์เกตเวย์และให้ไฟร์วอลล์จัดการ IP ได้หรือไม่


เท่าที่ฉันเข้าใจมันไม่ใช่ ... แต่มีคนโปรดแก้ไขฉันถ้าฉันผิด
darron
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.