Re: [ml] Iptables e eth0:n

Edoardo Serra wrote:

> Questo server ha due schede di rete di cui una con 2 ip pubblici
> connessa a internet e una con un IP privato connesso alla LAN
> eth0 --> ippubblico1
> eth0:100  --> ippubblico2
> eth1 --> ipprivato
> 
> La configurazione di iptables, (iptables -L -v) è la seguente (riporto
> solo le regole secondo me più rilevanti)
> 
> Chain INPUT (policy DROP 189 packets, 27146 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination
>   979  121K ACCEPT     all  --  eth1   any     anywhere            
> anywhere
>  5630  854K ACCEPT     all  --  any    any     anywhere      
> anywhere            state ESTABLISHED
>     1    56 ACCEPT     all  --  any    any     anywhere      
> anywhere            state RELATED
>     0     0 ACCEPT     udp  --  any    any     anywhere      
> anywhere            udp spt:domain dpts:1024:65535
>     0     0 ACCEPT     tcp  --  any    any     IPAUTORIZZATO      
> anywhere            tcp dpt:ssh
> 
> Tutte le connessioni in ingresso da eth1 devono essere accettate e ssh
> solo da alcuni IP
> Ho omesso altre regole simili, alcuni ip accedono ad alcuni altri
> servizi....

[...]

> Ora, se dall'esterno origino una connessione ssh verso ippubblico1 va
> tutto bene, i pacchetti vengono droppati, ma se origino una connessione
> verso ippubblico2 i pacchetti passano tranquillamente, sia per ssh sia
> per tutti gli altri servizi che in teoria non dovrebbero essere visti
> dal mondo esterno


iptables (netfilter, in realtà) non ha di suo alcuna conoscenza
"intrinseca" di quale sia l'IP della NIC sulla quale arrivano i
pacchetti, ma si basa (per stabilire cosa sia INPUT e cosa FORWARD)
solamente sulla "strada" che i pacchetti prendono all'interno dello
stack dopo essere stati processati dal codice di routing. In questi
termini, non c'è alcuna differenza tra un IP "principale" ed uno
"alias", dal suo punto di vista, e pertanto non sarebbero giustificate
differenze di comportamento nel trattare i due IP di destinazione.

Non ho idea di quali siano le cause, quindi, del comportamento che citi,
ma salvo bug specifici del kernel di CentOS che usi (difficile comunque
da giustificare) non è un comportamento spiegabile normalmente, e mi
lascia piuttosto pensare a una qualche parte del ruleset che fa qualcosa
di diverso da quello che si attende chi l'ha compilato (qualcosa in
PREROUTING, magari, che cambi le carte prima di arrivare in INPUT?)

Consiglierei di far dare un'occhiata all'output (completo, sia pur
"purgato" delle informazioni sensibili) di un iptables-save, piuttosto
che di iptables -L.

Bye