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


10

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

# 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 

Есть идеи? Заранее спасибо. :-)


1
.184 or .196 hostsЕсть ли у хостов клиента дополнительные IP-адреса в другой подсети? Если вы делаете tcpdump -qn port 3306и пытаетесь подключиться к одной из этих систем, что вы видите? Вы видите адрес источника, который ожидаете?
Zoredache

1
Спасибо, Зордаче! Это решило это. Хост .251 не имеет IP-адресов, назначенных из другой подсети. Два других хоста это делают (.184 и .196), поэтому при подключении к IP-адресу в другой подсети исходный IP-адрес на этих хостах переключается на IP-адрес в той же подсети. Я думал, что исходящий / исходный IP всегда будет назначен по умолчанию. Но tcpdump ясно показывает, что исходный IP-адрес изменяется на подсеть 209.xxx.xxx.xxx при каждом подключении к IP-адресу в той же подсети. (Однако пришлось запустить tcpdump с физического хоста Proxmox.) Вы гениальны. Спасибо!
Кертис

Ответы:


8

Есть ли у клиентов хостов .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.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.