più interfacce fisiche con IP sulla stessa sottorete


13

Ho un box Linux con 9 schede di rete su di esso e voglio che otto di loro abbiano indirizzi univoci sulla stessa sottorete, ad esempio:

ifconfig eth1 192.168.123.1 netmask 255.255.0.0
ifconfig eth2 192.168.123.2 netmask 255.255.0.0
ifconfig eth3 192.168.123.3 netmask 255.255.0.0
...
ifconfig eth8 192.168.123.8 netmask 255.255.0.0

Il comportamento predefinito di ARP è estremamente controproducente in questo caso, poiché provoca tutto il traffico per tutti gli IP che passano esclusivamente attraverso eth1, il che è praticamente l'esatto contrario di quello che voglio.

Quindi ho rovistato e ho finito per apportare alcune modifiche a sysctl come questo:

net.ipv4.conf.all.arp_filter=1
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Ciò ha impedito eth1di impersonare tutti gli altri, ma non riesco ancora a eseguire il ping di qualsiasi cosa diversa eth1dall'indirizzo con successo. (ad es. da un secondo computer sullo stesso switch, 192.168.123.1risponde solo al ping)

Immagino di dover fare qualcosa con arptables o iproute o QUALCOSA, ma mi sono perso in mare in questo campo.

Punti bonus: la soluzione deve essere compatibile con Linux 2.6.27.27. (Più specificamente, Slax 6.1.2)


Puoi pubblicare la tabella di routing?
ponsfonze,

2
Qual è il tuo scopo nel creare questa configurazione? Cosa stai cercando di realizzare?
David Schwartz,

così sta la follia.
Sirex,

se vuoi unire queste interfacce, dovrai effettivamente legarle.
resmon6

1
@DavidSchwartz No, la macchina non dovrebbe agire come un interruttore (o router). Pensate più come consecutive di 8 macchine virtuali con una scheda di rete fisica dedicata per ogni VM ( Nota: io non VM in esecuzione, questo è solo un'analogia ). Dal punto di vista di un altro box sulla stessa rete, il mio PC singolo dovrebbe essere completamente indistinguibile da otto PC discreti.
frustrated_tester

Risposte:


17

È necessario un modello di sistema avanzato . Linux è fondamentalmente costruito attorno a un modello di sistema di invio debole, quindi non è davvero una buona scelta del sistema operativo per questa applicazione.

Dovrai falsificare ogni parte del comportamento di cui hai bisogno, dall'ARP all'instradamento delle politiche alla selezione dell'indirizzo di origine. Avrai anche bisogno di filtri per evitare che i pacchetti vengano accettati se arrivano sull'interfaccia sbagliata.

I passaggi assolutamente necessari sono:

  1. Configura arp_filter = 1 e arp_ignore = 2 su tutte le interfacce.

  2. Aggiungi il routing basato sull'interfaccia e basato sull'origine per il traffico in uscita. (L'interfaccia di destinazione deve essere scelta in base all'indirizzo di origine.)

  3. Aggiungi il filtro di ingresso per interfaccia per eliminare silenziosamente i pacchetti ricevuti sull'interfaccia sbagliata. (Pacchetti con un indirizzo di destinazione assegnato a un'altra interfaccia.)

Sfortunatamente, non vi è consenso sul fatto che questi tre passaggi siano tutto ciò che è necessario. Il modello di sistema di fascia bassa è integrato nell'intero stack TCP / IP di Linux e non è chiaro cosa potrebbe andare storto con problemi sottili come il multicast.

Ad esempio, non è chiaro come scegliere l'interfaccia di output per le trasmissioni. Dovrebbero uscire tutti? Può essere. Qual è il comportamento corretto se lo stack riceve una trasmissione in uscita con un indirizzo di origine non assegnato a una delle interfacce?

Ancora una volta, hai scelto lo strumento sbagliato per il lavoro.


6

È più probabile che tu voglia creare un bridge con le interfacce 8/9 e quindi assegnare un indirizzo IP a quel bridge (pacchetto bridge-utils, comando 'brctl add').

In questo modo il bridge funzionerà come uno switch e può avere un indirizzo IP nella tua sottorete.


AFAIK, questa dovrebbe effettivamente essere la risposta corretta per Linux. Linux aggira molti dei problemi menzionati nella risposta di David usando i dispositivi bridge (ovvero evita i problemi L3 costruendo una migliore rete logica L2).
Dave,

4

Vorrei raccomandare il collegamento delle interfacce fisiche, quindi configurare tutti gli indirizzi sulla singola interfaccia legata.

Avrai bisogno di supporto anche sullo switch.

Ecco un mini tutorial che puoi usare per iniziare.


4

Sembra che tu voglia un ambiente di test equivalente a 9 macchine separate e credevi che 9 interfacce su una macchina potessero emularlo. In Linux semplicemente non può farlo attraverso un singolo stack per le ragioni descritte da David Schwartz. BTDT e avere le cicatrici. Era abbastanza male con 2 interfacce.

Una soluzione migliore potrebbe essere quella di eseguire 8 o 9 macchine virtuali discrete in un unico host e collegare 8 o 9 interfacce a queste macchine virtuali.


Risorse di lettura: Unix Network Programming: l'API Socket Networking, di Stevens, Fenner e Rudoff. Vedi anche RFC1122 e RFC4907.
Skaperen,

0

Sì, è possibile seguire il suggerimento di David Schwartz:

echo -ne 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo -ne 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo -ne 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter

// Per una corretta funzionalità, ad esempio le risposte ARP di eth1 vengono generate quando sia eth0 che eth1 si trovano nella stessa sottorete

echo -ne 0 > /proc/sys/net/ipv4/conf/all/arp_filter
echo -ne 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo -ne 0 > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo -ne 2 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo -ne 0 > /proc/sys/net/ipv4/conf/eth1/arp_filter
echo -ne 2 > /proc/sys/net/ipv4/conf/eth1/arp_ignore

//Create a table called "new_rt_table" and create a routing rule that says any packet with a mark equal to '1' gets routed according to the "new_rt_table"(can name it whatever you want) table. The file /etc/iproute2/rt_tables is the only source of table names on the system. Internally, routing tables have integer identifiers.

echo 1 new_rt_table >> /etc/iproute2/rt_tables
ip rule add from all fwmark 1 table new_rt_table

// imposta la tabella "new_rt_table" per instradare i pacchetti tramite eth1

ip route add default dev eth1 table new_rt_table
ip route show table new_rt_table

// contrassegna i pacchetti in modo che 'ip route' possa instradarlo attraverso eth1

iptables -F -t mangle
iptables -t mangle -I OUTPUT -s <ip addr of eth1> -o eth0 -j MARK --set-mark 1

// abilita il supporto per più tabelle di routing nella configurazione del kernel.

Configurazione del kernel

→ Supporto di rete → Opzioni di rete

[*] IP: router avanzato

[*] IP: routing delle politiche

CONFIG_IP_ADVANCED_ROUTER

CONFIG_IP_MULTIPLE_TABLES

// i passaggi precedenti reindirizzano i pacchetti che devono essere emessi da eth0 per uscire correttamente da eth1.

Si prega di suggerire altri metodi se qualcuno riesce a farlo funzionare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.