Назад | Перейти на главную страницу

iptables не разрешает подключения mysql к IP-адресам с псевдонимом?

У меня есть довольно простой брандмауэр 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 

Как только приведенные выше правила вступят в силу, произойдет следующее:

Сервер работает в контейнере OpenVZ / Proxmox CentOS 5.4 (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 

Любые идеи? Заранее спасибо. :-)

Имеют ли клиентские хосты .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.