SynProxy ไม่สามารถส่งคืนแพ็กเก็ต syn ack ด้วยโทโพโลยีสะพานคู่แบบอสมมาตร


12

ฉันมีโทโพโลยีสะพานคู่แบบอสมมาตรตามที่แสดงด้านล่างเมื่อฉันเชื่อมต่อจาก 172.16.11.5 และ 172.16.10.6 ด้วย ssh แต่ฉันไม่สามารถเชื่อมต่อได้เนื่องจาก SynProxy

                  -------
                  |     |
                  ---o--- 172.16.11.5
                     |
                     |
                -----o----- 172.16.11.6
                |         |
                |         | default gw 1.1.1.1
                |         |
     1.1.1.2/30 --o----o--- 2.2.2.2/30
                  |    |
                  |    |
                  |    | (enp10s0f0)
              ----o----o-----
              |             |
              |     XXX     |
              |             |
              |  br1   br0  | synproxy
              |             |
              ----o----o-----
                  |    |
                  |    |
                  |    |
     1.1.1.1/30 --o----o--- 2.2.2.1/30
                |         |
                |         | default gw 2.2.2.2
                |         |
                -----o----- 172.16.10.1
                     |
                     |
                  ---o--- 172.16.10.6
                  |     |
                  -------

ในทุกเครื่องระหว่าง 172.16.11.5 และ 172.16.10.6 "ตัวกรอง rp" ปิดอยู่และ "ip forwarding" เปิดอยู่ มีเครื่องที่กึ่งกลางของทอพอโลยีซึ่งเรียกว่า "XXX" เครื่อง XXX มีสองบริดจ์และ SynProxy

เมื่อ SynProxy ปิดที่ XXX ฉันสามารถ ping จาก 172.16.11.5 ถึง 172.16.10.6 และแพ็คเก็ต icmp ตามเส้นทางนี้: br1-> 172.16.10.1-> 172.16.10.6-> 172.16.10.1-> br0 นอกจากนี้ฉันสามารถเข้าถึงจาก 172.16.11.5 ถึง 172.16.10.6 ด้วย ssh ดังนั้นปริมาณการใช้งาน TCP จะทำงานตามที่ฉันคาดไว้

อย่างไรก็ตามเมื่อเปิด SynProxy ใน XXX ฉันสามารถ ping จาก 172.16.11.5 ถึง 172.16.10.6 และแพ็คเก็ต icmp ตามเส้นทางเดียวกัน แต่ฉันไม่สามารถเข้าถึงจาก 172.16.11.5 ถึง 172.16.10.6 โดยใช้ ssh นี่เป็นเพราะ synproxy ไม่สามารถส่งการตอบกลับการตอบ syn ผ่าน br1 iface หากฉันเพิ่มเส้นทางสำหรับแพ็คเก็ต synack ใน XXX ฉันสามารถเชื่อมต่อจาก 172.16.11.5 ถึง 172.16.10.6 ด้วย ssh

route เพิ่ม 172.16.11.5 dev enp10s0f0

กฎของ SynProxy สำหรับ XXX:

iptables -t raw -A PREROUTING -i br0 -p tcp -m physdev --physdev-in 
enp10s0f0 -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack
iptables -t raw -A PREROUTING -i br1 -p tcp -m physdev --physdev-in 
enp11s0f0 -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack

iptables -t filter -A FORWARD -i br0 -p tcp -m physdev --physdev-in 
enp10s0f0 -m tcp -m state --state INVALID,UNTRACKED -j SYNPROXY 
--sack-perm --timestamp --wscale 7 --mss 1460
iptables -t filter -A FORWARD -i br0 -m physdev --physdev-in enp10s0f0 
-m state --state INVALID -j DROP
iptables -t filter -A FORWARD -i br1 -p tcp -m physdev --physdev-in 
enp11s0f0 -m tcp -m state --state INVALID,UNTRACKED -j SYNPROXY 
--sack-perm --timestamp --wscale 7 --mss 1460
iptables -t filter -A FORWARD -i br1 -m physdev --physdev-in enp11s0f0 
-m state --state INVALID -j DROP

แต่สิ่งนี้ไม่เป็นที่ยอมรับเนื่องจากเครือข่าย 172.16.11.0 เป็นระบบคลาวด์ ดังนั้นฉันไม่สามารถเพิ่มเส้นทางเครือข่ายคลาวด์ทั้งหมดไปยังตารางเส้นทางและไม่สามารถเพิ่มที่อยู่ mac ไปยังตาราง arp

ฉันจะเชื่อมต่อจาก 172.16.11.5 ไปยังเครื่อง 172.16.10.6 โดยใช้ ssh ได้อย่างไรเมื่อ SynProxy เปิดใช้งานบน XXX หรือเป็นไปได้?

ขอบคุณล่วงหน้า,


คุณสามารถบอกได้ว่าค่าmedium_idของอินเตอร์เฟสสะพานใน synproxy มีค่าเท่าใด? นอกจากนี้กฎ SYNPROXY ที่แท้จริงของคุณในตารางทั้งหมดคืออะไร
Alexander Janssen

ฉันเพิ่มกฎ iptables สำหรับ SynProxy แต่ฉันไม่รู้อะไรเกี่ยวกับ medium_id ฉันค้นหาอย่างรวดเร็วบนอินเทอร์เน็ต แต่มันไม่ใช่ heplful @AlexanderJanssen
nyzsirt

คำตอบ:


0

วิธีที่ง่ายที่สุดที่ฉันสามารถแก้ไขได้คือเปลี่ยนเส้นทางเริ่มต้นบนเครื่องเกตเวย์เพื่อใช้บริดจ์เดียวกันดังนั้นมันจึงไม่สมมาตรอีกต่อไป

  • ใน 172.16.11.6 ตั้งค่าเริ่มต้นเป็น 2.2.2.1 (ผ่าน br0)
  • บน 172.16.10.1 ตั้งค่าเริ่มต้นเป็น 2.2.2.2 (ผ่าน br0)

ฉันอยากรู้ว่าทำไมมันถึงได้รับการออกแบบมาอย่างนี้ ... อะไรคือจุดประสงค์ของสะพานที่สอง?

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