ARP ตอบกลับหายไปจาก br0 เป็น tap0 โดยใช้ OpenVPN ในโหมด bridging

ฉันติดตั้งกล่อง linux (บน esxi5) ซึ่งทำหน้าที่เป็นเซิร์ฟเวอร์ OpenVPN เซิร์ฟเวอร์ถูกกำหนดค่าให้ใช้การเชื่อมต่อสำหรับลูกค้าซึ่งใช้งานได้จริงโดยมีข้อยกเว้นหนึ่งข้อ

หากไคลเอนต์ส่ง Ping เครื่องบางตัวในเครือข่ายซึ่งไม่ใช่เซิร์ฟเวอร์นั้นจะไม่ทำงาน ฉันตัดทุกอย่างที่ฉันรู้ (iptables และอื่น ๆ ) และรัน tcpdump ต้มมันลงไปในสิ่งต่อไปนี้:

ฉันเห็นคำขอ ARP บน tap0 และ br0
ฉันเห็น ARP ตอบกลับใน br0
ฉันไม่เห็น ARP ตอบกลับใน tap0

คำถาม: ทำไมอุปกรณ์ br0 ไม่ส่งต่อ ARP ตอบกลับไปยังอุปกรณ์ tap0

— บึง
แหล่งที่มา

ตกลง - ฉันก้าวไปอีกขั้น เมื่อฉันดูตาราง mac ของบริดจ์โดยใช้ showmacs brctl ฉันเห็นที่อยู่ mac ของไคลเอนต์ vpn ของฉันที่ด้าน tap0 ถ้าตอนนี้ฉันเริ่มกระตุกจากไคลเอนต์ vpn ไปยัง subnet ที่อยู่ mac จะย้ายไปที่พอร์ต over bridge ซึ่งแน่นอนว่าบล็อกการตอบกลับ arp ของซับเน็ต Mac จะสลับกลับมาเกือบจะทันทีเมื่อ ping หยุด ดังนั้นสิ่งที่ฉันไม่รู้คือเหตุผลที่ที่อยู่ mac เปลี่ยนไปใช้สวิตช์ผิด - การค้นหาทั้งหมดของฉันให้ผลไม่ไกล

— fen

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

— the-wabbit

แยกปัญหาโดยใช้รายการ ARP แบบคงที่ก่อนในไคลเอนต์ของคุณถ้าส่ง Ping ทำงานได้ดีหลังจากนั้นคุณสามารถไปยังการแก้ไขปัญหา ARP ถ้ามันใช้ไม่ได้แสดงว่าคุณมีปัญหาการเชื่อมต่อเครือข่ายที่ใหญ่กว่า ARP

— Ricardo

เนื่องจากเราไม่สามารถรู้ได้เลยว่าเครือข่ายของคุณมีลักษณะอย่างไร ยิงยาว; คุณมีclient-to-clientในไฟล์กำหนดค่า openvpn ของเซิร์ฟเวอร์ของคุณหรือไม่ หากเซิร์ฟเวอร์ของคุณเชื่อมต่อกับเครือข่าย VPN โดยใช้ openvpn เป็นไคลเอนต์ประโยคนั้นอาจเป็นจริง PS คุณใช้ distro แบบใด

— Michal Sokolowski

คำตอบ:

หากไม่มีข้อมูลเพิ่มเติมเราคาดเดา แต่ให้ลองทำดังนี้:

ก่อนอื่นตรวจสอบให้แน่ใจว่าทั้ง eth0 และ tap0 อยู่ในโหมด promiscuous br0 ไม่ควรอยู่ในโหมดที่หลากหลาย

ถัดไปตรวจสอบว่าคุณมี arptables และกฎ iptables ใด ๆ ที่อาจรบกวน

เมื่อคุณได้รับการตอบกลับจาก arp แล้วคุณอาจยังไม่มีสิ่งนี้แต่ลองตรวจสอบดู

ในที่สุดตรวจสอบการตั้งค่าrp_filterแต่ก็ตรวจสอบพารามิเตอร์ sysctl พิเศษที่คุณอาจตั้งไว้

— higuita
แหล่งที่มา

... และเนื่องจากเป็น ESXi ทำให้แน่ใจว่าโหมด promiscuous เปิดใช้งานบนสวิตช์เสมือน

— เจอรัลด์รวงผึ้ง

^ ^ ^ ^ มันเป็นสิ่งสำคัญที่จะต้องเปิดใช้งานโหมดที่หลากหลายใน vSwitchหากคุณใช้ ESXi จริงๆ.

— roaima

หากโฮสต์ ESXi ของคุณมีการเชื่อมต่อกับเครือข่ายซ้ำซ้อนมีปัญหา ARP หลายประการที่สามารถปรากฏได้เนื่องจากการตั้งค่าเริ่มต้นของ Net.ReversePathFwdCheckPromisc ผู้ใช้ pfSense ที่ใช้ CARP เป็นกลุ่มแรกสุดในการแก้ไขข้อบกพร่องนี้ซึ่งอธิบายไว้ที่https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting

ในสภาพแวดล้อมที่คล้ายกันเราได้ตั้งค่าการเชื่อมโยง OpenVPN บน FreeBSD แต่ยังรวมถึงความซับซ้อนเพิ่มเติมของ vlans บนโฮสต์ที่ Net.ReversePathFwdCheckPromisc ไม่ได้ถูกตั้งค่าเป็น 1 และที่มีอัปลิงค์จำนวนมากไปยังเครือข่ายอยู่เราจะเห็นการสูญเสียแพ็กเก็ตจำนวนมาก (95% +) จากปริมาณการรับส่งข้อมูลขาเข้าไปยังอุปกรณ์ประปา มันทำงานได้ดีเมื่อตั้งค่าเป็น 1

— JG23
แหล่งที่มา