slacky.eu

Mi sto impazzendo.

Ho un host con un ip sulla eth0
ip=192.168.0.10
netmask=255.255.255.0
gateway=192.168.0.1

Ho bisogno che nel sistema sia presente anche l'ip 192.168.0.20, non importa la netmask.
E' importante però che tale ip non sia raggiungibile dalla rete esterna, di conseguenza non lo posso mettere su eth0:0

l'ho messo su una seconda scheda di rete eth1 a cui non c'è alcun cavo di rete connesso, e poi ho forzato il default gateway a passare dalla eth0.

Vado su una seconda macchina, pingo 192.168.0.20 e mi risponde!!!!

con un tcpdump vedo che i pacchetti passano sulla eth0. In pratica sembra come se l'avessi messo su eth0:0 anzichè eth1.

Ho provato di tutto, anche mettendolo nella netmask 255.255.255.255 (così nessun host dovrebbe poterlo pingare) oppure mettendolo in down
ifconfig eth1 192.168.0.20 netmask 255.255.255.255 down
ho provato anche con altre netmask.

così facendo con ifconfig non si vede l'ip, ma solo con ifconfig -a, eppure continua ad essere raggiungibile dall'esterno.

Ho anche provato a metterlo su loopback ma niente, gli host esterni continuano a vederlo.
La soluzione non è firwallando... non deve proprio presentarsi!!
Se un host invia un broadcast verso questo ip quello che voglio è che il sistema risponda solamente se tale broadcast è sul 192.168.0.10

Sapete come fare?

Io darei un occhio a /proc/sys/net/ipv4/ip_forward che dovrebbe essere a 0. Non dovrebbe fare differenza perché, se non ricordo male, serve solo in caso di routing.

Trovo comunque strano che mettendo l'ip su una scheda scollegata risponda comunque ai ping. Non è che è attivo un bridge sulle schede di rete creato magari da qualche software di virtualizzazione?

È normale invece, è ho capito il perché (finalmente dopo 20 anni che uso una rete

), ed ho risolto.

Anche io pensavo giocando di ip_forward (che però è già settato a 0), rotte statiche, iptables e - visto che si tratta di una macchina virtuale su VMware - il software di virtualizzazione.

La verità è che il fatto che un ip stia su eth0 o eth1 in verità è fittizio. L'ip è del sistema, non della scheda.

Quando il secondo host pinga manda un broadcast a TUTTI gli host della rete dicendogli "sei tu 192.168.0.20?"; se non è lui semplicemente ignora il messaggio (ma con tcpdump lo puoi vedere); se invece è lui allora ti risponderà di si e il mittente si segna il macaddress che gli ha detto questo.
Lo vedi con il comando arp
Quando poi parte il pacchetto ip della vera richiesta (p.e. ping) il mittente va a leggere la tabella di arp e interrogherà direttamente il macaddress che si è segnato.

L'host si vede arrivare questa richiesta sulla eth0. La risposta avverrà in base alle tabelle di routing (per default "esci da dove entri" perché agli switch di solito da fastidio che un pacchetto parte da una interfaccia e la risposta viene da un'altra, ovvero routing asimmetrico, ma il comportamento è modificabile)

Giocando con il parametro in proc arp_ignore e un altro che ora non ricordo, si può dire alla eth0 "fatti i fatti tuoi e rispondi solo per quanto riguarda il tuo ip"
Addirittura tunando adeguatamente puoi dirgli anche di rispondere per quanto riguarda eth0 e non per eventuali ip virtuali su eth0:0

Domani vi mando i dettagli e il link con cui ho risolto.

eccolo
http://kb.linuxvirtualserver.org/wiki/U ... isable_ARP

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
con questa configurazione non viene neanche annunciato un ip su eth0:0, ma io l'ho comunque lasciato su eth1 con cavo di rete staccato. Avevo provato anche su loopback, ma poi interferisce con le rotte statiche.

arp_announce - INTEGER
Define different restriction levels for announcing the local
source IP address from IP packets in ARP requests sent on
interface:
0 - (default) Use any local address, configured on any interface
1 - Try to avoid local addresses that are not in the target's
subnet for this interface. This mode is useful when target
hosts reachable via this interface require the source IP
address in ARP requests to be part of their logical network
configured on the receiving interface. When we generate the
request we will check all our subnets that include the
target IP and will preserve the source address if it is from
such subnet. If there is no such subnet we select source
address according to the rules for level 2.
2 - Always use the best local address for this target.
In this mode we ignore the source address in the IP packet
and try to select local address that we prefer for talks with
the target host. Such local address is selected by looking
for primary IP addresses on all our subnets on the outgoing
interface that include the target IP address. If no suitable
local address is found we select the first local address
we have on the outgoing interface or on all other interfaces,
with the hope we will receive reply for our request and
even sometimes no matter the source IP address we announce.

The max value from conf/{all,interface}/arp_announce is used.

Increasing the restriction level gives more chance for
receiving answer from the resolved target while decreasing
the level announces more valid sender's information.

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses

The max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}

slacky.eu

due schede di rete, due ip, una vlan

due schede di rete, due ip, una vlan

Re: due schede di rete, due ip, una vlan

Re: due schede di rete, due ip, una vlan

Re: due schede di rete, due ip, una vlan