iptables nie zezwala na połączenia MySQL z aliasem IPS?

Mam dość prostą zaporę ogniową iptables na serwerze, który zapewnia usługi MySQL, ale wydaje się, że iptables daje bardzo niespójne wyniki.

Domyślne zasady dla skryptu są następujące:

iptables -P INPUT DROP

Następnie mogę ustawić MySQL jako publiczny, stosując następującą regułę:

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

Dzięki tej zasadzie mogę bez problemu łączyć się z MySQL z dowolnego źródłowego adresu IP do dowolnego docelowego adresu IP na serwerze. Jednak gdy próbuję ograniczyć dostęp tylko do trzech adresów IP, zastępując powyższą linię poniższym, napotykam problemy (xxx = maskowany 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

Po wprowadzeniu powyższych zasad, dzieje się:

I może połączyć się z serwerem MySQL z 0,184, .196 i .251 gospodarzy dobrze tak długo, jak łączę się z serwerem MySQL używając To domyślny adres IP lub aliasu IP w tej samej podsieci co domyślny adres IP.
Jestem w stanie połączyć się z MySQL przy użyciu aliasów IP, które są przypisane do serwera z innej podsieci niż domyślny adres IP serwera, gdy wracam z .184 lub .196 .251 gospodarze, ale działa dobrze. Z hostów .184 lub .196 próba telnet zawiesza się ...
```
# telnet 209.xxx.xxx.22 3306
Trying 209.xxx.xxx.22...
```
Jeśli usunę wiersz .251 (czyniąc .196 ostatnią dodaną regułą), host .196 nadal nie będzie mógł połączyć się z MySQL przy użyciu aliasów IP (więc to nie kolejność reguł powoduje niespójne zachowanie). Wiem, że ten konkretny test był głupi, ponieważ nie powinno mieć znaczenia, w jakiej kolejności dodano te trzy reguły, ale pomyślałem, że ktoś może zapytać.
Jeśli wrócę do reguły „publicznej”, wszystkie hosty mogą połączyć się z serwerem MySQL przy użyciu domyślnych lub aliasowanych adresów IP (w dowolnej podsieci):
```
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
```

Serwer działa w kontenerze CentOS 5.4 OpenVZ / Proxmox (2.6.32-4-pve).

I na wypadek, gdybyś wolał widzieć reguły problemu w kontekście skryptu iptables, oto on (xxx = maskowany 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

Jakieś pomysły? Z góry dziękuję. :-)

mysql iptables ip-aliasing

— Curtis
źródło

Czy .184 or .196 hostshosty klientów mają również dodatkowe adresy IP w drugiej podsieci? Jeśli to zrobisz tcpdump -qn port 3306i spróbujesz połączyć się z jednym z tych systemów, co zobaczysz? Czy widzisz oczekiwany adres źródłowy?

— Zoredache,

Dzięki, Zordache! To rozwiązało. Do hosta .251 nie przypisano żadnych adresów IP z drugiej podsieci. Pozostałe dwa hosty tak robią (.184 i .196), więc kiedy łączą się z adresem IP w drugiej podsieci, źródłowy adres IP na tych hostach przełącza się na adres IP w tej samej podsieci. Myślałem, że wychodzące / źródłowe IP zawsze będzie domyślnie przypisane. Ale tcpdump wyraźnie pokazuje, że źródłowy adres IP zmienia się na podsieć 209.xxx.xxx.xxx za każdym razem, gdy łączy się z adresem IP w tej samej podsieci. (Musiałem jednak uruchomić tcpdump z fizycznego hosta Proxmox.) Jesteś genialny. Dzięki!

— Curtis

Czy hosty klienckie .184 lub .196 również mają dodatkowe adresy IP w drugiej podsieci?

Jeśli to zrobisz tcpdump -qn port 3306i spróbujesz połączyć się z jednym z tych systemów, co zobaczysz? Czy widzisz oczekiwany adres źródłowy? Jest to prawdopodobnie prosty problem z routingiem.

Gdy system podejmuje decyzję o trasie, sprawdza tablicę tras. Tabele tras są listą, która jest zawsze sprawdzana w określonej kolejności. Trasy łącza dla sieci lokalnych są prawie zawsze najbardziej preferowanymi trasami i będą używane przed trasą korzystającą z bramy (routera). Domyślną bramą jest zawsze trasa używana, gdy żadna inna trasa nie zostanie zastosowana. Jeśli trasa ma określoną trasę src, adres ten będzie preferowany i najprawdopodobniej użyty, gdy ta trasa będzie używana.

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

Biorąc pod uwagę tę przykładową tabelę tras dla systemu z wieloma bazami, wszystko, z czego 10.2.13.0/24będzie pochodzić, będzie pochodzić 10.2.13.1i z czego 10.2.4.0/23będzie przeznaczone 10.2.4.245.

— Zoredache
źródło