iptables ne permettant pas les connexions mysql aux ips aliasés?

J'ai un pare-feu iptables assez simple sur un serveur qui fournit des services MySQL, mais iptables semble me donner des résultats très incohérents.

La stratégie par défaut sur le script est la suivante:

iptables -P INPUT DROP

Je peux ensuite rendre MySQL public avec la règle suivante:

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

Avec cette règle en place, je peux me connecter à MySQL depuis n'importe quelle IP source vers n'importe quelle IP de destination sur le serveur sans problème. Cependant, lorsque j'essaie de restreindre l'accès à seulement trois adresses IP en remplaçant la ligne ci-dessus par ce qui suit, je rencontre des problèmes (xxx = octet masqué):

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

Une fois les règles ci-dessus en place, les événements suivants se produisent:

Je peux me connecter au serveur MySQL à partir des hôtes .184, .196 et .251 très bien tant que je me connecte au serveur MySQL en utilisant son adresse IP par défaut ou un alias IP dans le même sous-réseau que l'adresse IP par défaut.
Je ne parviens pas à me connecter à MySQL en utilisant des alias IP attribués au serveur à partir d'un sous-réseau différent de l'adresse IP par défaut du serveur lorsque je viens des hôtes .184 ou .196, mais .251 fonctionne très bien. À partir des hôtes .184 ou .196, une tentative de telnet se bloque simplement ...
```
# telnet 209.xxx.xxx.22 3306
Trying 209.xxx.xxx.22...
```
Si je supprime la ligne .251 (faisant de .196 la dernière règle ajoutée), l'hôte .196 ne peut toujours pas se connecter à MySQL à l'aide d'alias IP (donc ce n'est pas l'ordre des règles qui cause le comportement incohérent). Je sais, ce test particulier était stupide car peu importe l'ordre dans lequel ces trois règles sont ajoutées, mais j'ai pensé que quelqu'un pourrait demander.
Si je reviens à la règle "publique", tous les hôtes peuvent se connecter au serveur MySQL en utilisant les IP par défaut ou alias (dans l'un ou l'autre des sous-réseaux):
```
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
```

Le serveur s'exécute dans un conteneur CentOS 5.4 OpenVZ / Proxmox (2.6.32-4-pve).

Et, juste au cas où vous préférez voir les règles du problème dans le contexte du script iptables, le voici (xxx = octet masqué):

# 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

Des idées? Merci d'avance. :-)

mysql iptables ip-aliasing Curtis
la source

Les .184 or .196 hostshôtes clients ont-ils également des adresses IP supplémentaires dans votre autre sous-réseau? Si vous faites un tcpdump -qn port 3306essai et que vous vous connectez à partir de l'un de ces systèmes, que voyez-vous? Voyez-vous l'adresse source que vous attendez?

Zoredache

Merci, Zordache! Cela l'a résolu. L'hôte .251 n'avait aucune adresse IP attribuée à partir de l'autre sous-réseau. Les deux autres hôtes le font (.184 et .196), et donc lorsqu'ils se connectent à une IP sur l'autre sous-réseau, l'IP source sur ces hôtes bascule vers une IP dans le même sous-réseau. J'avais pensé que l'adresse IP sortante / source serait toujours celle attribuée par défaut. Mais, tcpdump montre clairement que l'IP source passe au sous-réseau 209.xxx.xxx.xxx chaque fois qu'il se connecte à une IP de ce même sous-réseau. (Cependant, j'ai dû exécuter tcpdump à partir de l'hôte physique Proxmox.) Vous êtes un génie. Merci!

Curtis

iptables ne permettant pas les connexions mysql aux ips aliasés?

Réponses: