iptables ไม่อนุญาตให้มีการเชื่อมต่อ mysql กับ ips ที่ใช้นามแฝง?

ฉันมีไฟร์วอลล์ iptables ที่ค่อนข้างง่ายบนเซิร์ฟเวอร์ที่ให้บริการ MySQL แต่ iptables ดูเหมือนจะให้ผลลัพธ์ที่ไม่สอดคล้องกันมาก

นโยบายเริ่มต้นของสคริปต์มีดังนี้:

iptables -P INPUT DROP

จากนั้นฉันสามารถทำให้ MySQL เป็นแบบสาธารณะด้วยกฎต่อไปนี้:

iptables -A INPUT -p tcp --dport 3306 -j ACCEPT

ด้วยกฎนี้ฉันสามารถเชื่อมต่อ MySQL จาก IP ต้นทางใด ๆ กับ IP ปลายทางใด ๆ บนเซิร์ฟเวอร์ได้โดยไม่มีปัญหา อย่างไรก็ตามเมื่อฉันพยายาม จำกัด การเข้าถึง IP เพียงสามตัวโดยแทนที่บรรทัดด้านบนด้วยสิ่งต่อไปนี้ฉันพบปัญหา (xxx = masked octect):

iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.184 -j ACCEPT 
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.196 -j ACCEPT 
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.251 -j ACCEPT

เมื่อกฎข้างต้นเข้าที่แล้วจะเกิดสิ่งต่อไปนี้:

ฉันสามารถเชื่อมต่อกับเซิร์ฟเวอร์ MySQL จากโฮสต์. 184, .196 และ. 251 ได้ดีตราบใดที่ฉันกำลังเชื่อมต่อกับเซิร์ฟเวอร์ MySQL โดยใช้ที่อยู่ IP เริ่มต้นหรือชื่อแทน IP ในซับเน็ตเดียวกันกับที่อยู่ IP เริ่มต้น
ฉันไม่สามารถเชื่อมต่อกับ MySQL โดยใช้ชื่อแทน IP ที่กำหนดให้กับเซิร์ฟเวอร์จากเครือข่ายย่อยที่แตกต่างจาก IP เริ่มต้นของเซิร์ฟเวอร์เมื่อฉันมาจากโฮสต์. 184 หรือ. 196 แต่ทำงานได้ดีเพียง 251 จากโฮสต์. 184 หรือ. 192 ความพยายาม telnet เพียงแฮงค์ ...
```
# telnet 209.xxx.xxx.22 3306
Trying 209.xxx.xxx.22...
```
หากฉันลบบรรทัด. 251 (ทำให้. 196 เป็นกฎสุดท้ายที่เพิ่ม) โฮสต์. 196 ยังคงไม่สามารถเชื่อมต่อกับ MySQL โดยใช้ชื่อแทน IP ได้ (ดังนั้นจึงไม่ใช่ลำดับของกฎที่ทำให้เกิดพฤติกรรมที่ไม่สอดคล้องกัน) ฉันรู้ว่าการทดสอบนี้ไม่มีความหมายเพราะมันไม่สำคัญว่าจะเพิ่มกฎสามข้อในลำดับใด แต่ฉันคิดว่าอาจมีคนถาม
ถ้าฉันเปลี่ยนกลับไปเป็นกฎ "สาธารณะ" โฮสต์ทั้งหมดสามารถเชื่อมต่อกับเซิร์ฟเวอร์ MySQL ได้โดยใช้ IP เริ่มต้นหรือนามแฝง (ในซับเน็ต)
```
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
```

เซิร์ฟเวอร์กำลังทำงานในคอนเทนเนอร์ CentOS 5.4 OpenVZ / Proxmox (2.6.32-4-pve)

และในกรณีที่คุณต้องการดูกฎปัญหาในบริบทของสคริปต์ iptables นี่คือ (xxx = masked octect):

# Flush old rules, old custom tables
/sbin/iptables --flush
/sbin/iptables --delete-chain

# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT

# Enable free use of loopback interfaces
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Accept inbound TCP packets (Do this *before* adding the 'blocked' chain)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow the server's own IP to connect to itself
/sbin/iptables -A INPUT -i eth0 -s 208.xxx.xxx.178 -j ACCEPT

# Add the 'blocked' chain *after* we've accepted established/related connections
#   so we remain efficient and only evaluate new/inbound connections
/sbin/iptables -N BLOCKED
/sbin/iptables -A INPUT -j BLOCKED

# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
/sbin/iptables -A INPUT -p ICMP --icmp-type 11 -j ACCEPT

# ssh (private)
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT          

# ftp (private)
/sbin/iptables -A INPUT -p tcp --dport 21 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT          

# www (public)
/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT                                
/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT                               

# smtp (public)
/sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT                                
/sbin/iptables -A INPUT -p tcp --dport 2525 -j ACCEPT                              

# pop (public)
/sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT                               

# mysql (private)
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.184 -j ACCEPT 
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.196 -j ACCEPT 
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.251 -j ACCEPT

ความคิดใด ๆ ขอบคุณล่วงหน้า. :-)

mysql iptables ip-aliasing

— เคอร์ติ
แหล่งที่มา

อย่า.184 or .196 hostsเจ้าภาพลูกค้ายังมีอยู่ IP เพิ่มเติมในเครือข่ายย่อยอื่น ๆ ของคุณหรือไม่ หากคุณทำtcpdump -qn port 3306และพยายามเชื่อมต่อจากระบบใดระบบหนึ่งคุณเห็นอะไร คุณเห็นที่อยู่แหล่งที่คุณคาดหวังหรือไม่

— Zoredache

ขอบคุณ Zordache! นั่นแก้ไขได้ โฮสต์. 251 ไม่มี IP ใด ๆ ที่ได้รับมอบหมายจากซับเน็ตอื่น อีกสองโฮสต์ทำ (.184 และ. 196) และดังนั้นเมื่อพวกเขาเชื่อมต่อกับ IP บนเครือข่ายย่อยอื่น ๆ IP ต้นทางในโฮสต์เหล่านั้นจะเปลี่ยนเป็น IP ในเครือข่ายย่อยเดียวกัน ฉันคิดว่า IP ขาออก / ต้นทางจะเป็นค่าเริ่มต้นที่กำหนดไว้เสมอ แต่ tcpdump แสดงให้เห็นอย่างชัดเจนว่า IP ต้นทางเปลี่ยนเป็น subnet 209.xxx.xxx.xxx ทุกครั้งที่มันเชื่อมต่อกับ IP ในซับเน็ตเดียวกันนั้น (ต้องเรียกใช้ tcpdump จากโฮสต์ Proxmox จริง ๆ ) คุณเป็นคนใจดี ขอบคุณ!

— เคอร์ติส

โฮสต์ไคลเอ็นต์ไคลเอนต์. 184 หรือ. 196 มีที่อยู่ IP เพิ่มเติมในซับเน็ตอื่นของคุณหรือไม่

หากคุณทำtcpdump -qn port 3306และพยายามเชื่อมต่อจากระบบใดระบบหนึ่งคุณเห็นอะไร คุณเห็นที่อยู่แหล่งที่คุณคาดหวังหรือไม่ นี่อาจเป็นปัญหาการกำหนดเส้นทางอย่างง่าย

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

10.2.13.0/24 dev eth1  proto kernel  scope link  src 10.2.13.1 
10.2.4.0/23 dev eth0  proto kernel  scope link  src 10.2.4.245 
default via 10.2.4.1 dev eth0

ให้ดังนั้นตารางเส้นทางนี้ตัวอย่างเช่นสำหรับระบบ homed หลายสิ่งที่ลิขิตให้10.2.13.0/24จะมาจาก10.2.13.1และสิ่งที่ลิขิตให้จะมาจาก10.2.4.0/2310.2.4.245

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