Problema configurazione interfaccia di loopback secondaria

[a.danny82]

Ciao a tutti,

ho l'esigenza di configurare un interfaccia di loopback secondaria su macchine linux suse.

Sono riuscito nella configurazione sia in maniera statica editando il file ifcfg-lo o ifcfg-lo:1

sia in maniera dinamica con:

ip addr add ip_desiderato/8 dev lo

oppure

ifconfig lo:1 ip_desiderato/8 up



Il tutto funziona correttamente.



Se però (come ho l'esigenza di fare):

ip macchina:10.51.3.234/23

ip loopback: 10.51.3.223/8



l'ip della macchina 10.51.3.234 non risulta più raggiungibile dalla stessa rete ma risulta raggiungibile dalle altre wlan.

dallo sniffing inoltre è emerso che il pacchetto (ad esempio icmp) arriva alla macchina ma non risponde (forse perchè non viene accettato).

Ho tentato anche la configurazione di rotte statiche forzando la rete nell'eth0 e la loopback secondario sulla lo ma non ha funzionato.



Probabilmente è un problema di istradamento....

Qualcuno ha qualche idea?

Premetto che la medesima configurazione senza toccare le rotte o cose particolari è configurabile senza problemi sia sui sistemi windows che solaris, ma su linux in genere non funziona.



ciao e grazie in anticipo

[a.danny82]

Ciao a tutti,

sono riuscito a risolvere il problema

bisogna innanzi tutto modificare il file /etc/sysctl.conf

decommentando:

net.ipv4.conf.all.rp_filter = 1
enable route verification on all interfaces

ed inserendo:

net.ipv4.conf.all.arp_ignore = 1
Enable configuration of ARP_ignore option

net.ipv4.conf.eth0.arp_ignore = 1
Do not respond to ARP requests if the requested IP address is configured on the "lo" (loopback) device or any virtual eth0:X device.

net.ipv4.conf.all.arp_announce = 2
Enable configuration of ARP_announce option

net.ipv4.conf.eth0.arp_announce = 2
As the source IP address of ARP requests is entered into the ARP cache on the destination, it has the effect of announcing this address. This is undesirable for the lo or any other virtual interfaces from the real servers.

Using this setting, whenever the real server makes an ARP request, it tries to use the real IP as the source IP of the ARP request.



Dopodichè lanciare il comando:

# sysctl -p

per abilitare le modifiche



editare il file

/etc/sysconfig/network/ifcfg-lo

ed aggiungere:

IPADDR_2=10.51.3.223
NETMASK_2=255.255.255.255
BROADCAST_2=10.51.3.223

(se l'interfaccia di loopback ricade sotto la stessa maschera dell'interfaccia fisica bisogna mettere /32 e il broadcast naturalmente uguale all'ip dell'interfaccia di loopback)

Per fare la stessa operazione a caldo bisogna lanciare:

# ip addr add 10.51.3.223/32 brd 10.51.3.223 dev lo
N.B.: ifconfig lo:1 ecc o creare un file ifcfg-lo:1 su SUSE genera problemi di raggiungibilità, anche se su altri sistemi funziona lo stesso.

[matteo]

credo che il problema era più la netmask che tutto il resto del workaround.

se facevi un po' di tracciamento con:
iptables -A INPUT -p icmp -j LOG
iptables -A OUTPUT -p icmp -j LOG
tail -f /var/log/firewall

ti accorgeresti che non è vero che la macchina non risponde, ma che il pacchetto di ritorno tenterebbe di uscire dalla interfaccia di loopback.
Infatti la netmask 10.51.3.223/8 genera una network 10.0.0.0 che prevale rispetto alla 10.51.2.0 che si è formata sulla ethernet.

se da dentro la macchina fai un ping a qualsiasi indirizzo sulla 10.x.x.x, questo tenterà di uscire dalla loopback

portando la netmask a /32 hai risolto il problema a monte limitando la rete di loopback ad un solo indirizzo.

tutte le altre impostazioni dentro sysctl.conf sono finezze accessorie che non dovrebbero servire dal momento che imposti la netmask a /32.

windows su questo è un po' meno rigido

Matteo

P.S.: per vedere la tabella del firewall: iptables -L -n -v
per pulirla: iptables -F