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 = замаскований октект):

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 або .196 спроба telnet просто висить ...
```
# telnet 209.xxx.xxx.22 3306
Trying 209.xxx.xxx.22...
```
Якщо я видаляю рядок .251 (робить останнє додане правило .196), хост .196 все ще не може підключитися до MySQL, використовуючи псевдоніми IP (так що це не порядок правил, що викликає непослідовну поведінку). Я знаю, цей тест був дурним, тому що не має значення, в якому порядку додаються ці три правила, але я подумав, що хтось може запитати.
Якщо я переключусь на правило "public", усі хости можуть підключитися до сервера MySQL, використовуючи IP-адреси за замовчуванням або псевдонім (у будь-якій підмережі):
```
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
```

Сервер працює у контейнері CentOS 5.4 OpenVZ / Proxmox (2.6.32-4-pve).

І, на всякий випадок, якщо ви віддаєте перевагу бачити проблемні правила в контексті сценарію iptables, ось це (xxx = маскований октект):

# 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спробу і підключитесь до однієї з цих систем, що ви бачите? Чи бачите ви очікувану адресу джерела?

— Зоредаче

Спасибі, Зордаче! Це вирішило це. Хост .251 не мав жодних IP-адрес, присвоєних іншій підмережі. Інші два хости роблять (.184 та .196), і коли вони підключаються до IP в іншій підмережі, вихідний IP на цих хостах переходить на IP в тій самій підмережі. Я думав, що вихідний / вихідний IP завжди буде призначеним за замовчуванням. Але tcpdump чітко показує, що вихідний IP-код змінюється на підмережу 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

Отже, з огляду на цю прикладну таблицю маршрутів для багатодомної системи, все, що призначено для того 10.2.13.0/24, прийде 10.2.13.1, і все, що призначено для того 10.2.4.0/23, прийде 10.2.4.245.

— Зоредаче
джерело