So richten Sie internes Routing zwischen virtuellen Schnittstellen und einer echten Ethernet-Schnittstelle ein (Linux)

Question

Ich habe eine Linux-Box mit einer echten (im Gegensatz zu einer virtuellen, auch als Alias ​​bezeichneten) Ethernet-Schnittstelle, die ich verwenden kann (eth0 wird für andere Zwecke verwendet – ich kann es nicht verwenden, noch kann ich weitere Netzwerkkarten hinzufügen). Angenommen, es ist eth1

Ich muss einige Objekte/Entitäten über SNMP steuern, also richte ich für jedes Objekt eine virtuelle Ethernet-Schnittstelle mit der entsprechenden MAC-Adresse ein. Dies mache ich wie folgt (Beispiel für vif1):

ip -family inet link add link eth1 name vif1 address <the MAC addr> type macvlan
ip link set vif1 up multicast on
ip route del default dev vif1 table main /* enable the pings/TFTP going out! */
ip route add default via 192.168.1.1 table main proto static metric /* restore orig */

eth1, vif1, vif2, ... erhalten alle eine IP-Adresse von einem einzigen (entfernten) DHCP-Server. Alle diese IP-Adressen befinden sich natürlich im selben IP-Subnetz, beispielsweise 10.11.1.0/24.

Problem: Ping von der Linux-Box zum DHCP-Server (sagen wir 10.11.1.1) funktioniert. Ping vom DHCP-Server-Rechner zur eth1-IP oder einer beliebigen vif#X-IP funktioniert, ABER (DieProblem, nehme ich an …), nur eth1 antwortet auf die ICMP-Pakete (überprüft durch ifconfig-Zähler und durch Wireshark-Sniffing). Dieses Problem führt dazu, dass keine Verbindung zu den SNMP-Agenten hergestellt werden kann, die den IP-Adressen der vif-Schnittstellen zugeordnet sind.

Ich vermute, dass ich internes Routing einrichten muss, damit IP-Pakete ihr Ziel vif#X erreichen. Ich habe versucht, eine IP-Regel mit einer neuen IP-Routing-Tabelle hinzuzufügen, habe sie (die neue Tabelle) aber wahrscheinlich nicht richtig eingerichtet ... Kann mir jemand sagen, wie (und vorzugsweise auch warum) das geht?

Auf der Linux-Box läuft Ubuntu9.04 und auf dem DHCP-Server Windows XP SP3

Answer 1

Endlich gelöst: Es ist ein ARP-bezogenes Problem.

1. Der DHCP-Server weist der MAC-Adresse der virtuellen Schnittstelle eine IP-Adresse zu und legt dieses Paar in der lokalen ARP-Tabelle des Servers fest.
2. Die Linux-Box verknüpft die neue IP-Adresse mit der virtuellen Schnittstelle, die sie angefordert hat.
3. PINGs funktionieren in beide Richtungen:
4. Beim PingenausLinux zum Server, es geht über die echte Schnittstelle (die sich im selben IP-Subnetz befindet)
5. Beim Pingen vom ServerZuLinux, wieder die echte Schnittstelle reagiert so dass esscheintals ob alles ok wäre...

ABER

Wenn der Server IP-Pakete sendet (in meinem Fall SNMP-Nachrichten), verwendet er die MAC-Adresse der virtuellen Schnittstelle. Wenn es die Linux-Box erreicht, verwirft der Kernel diese Frames einfach, da er nicht weiß, wie er sie weiterleiten soll. Beim Ausführen von Wireshark werden diese Nachrichten angezeigt, da die Schnittstelle normalerweise in den Promiscuous-Modus versetzt wird.

Damit die SNMP-Nachrichten den SNMP-Agenten erreichen, der an die virtuelle Schnittstelle gebunden ist, muss das IP-Paket dieMAC-Adresse der realen Schnittstelle(Ich glaube, dass der Kernel erst dann ein VLAN-Routing basierend auf der IP-Adresse durchführt …)

Der Weg, dies zu erreichen, ist das Senden einerunentgeltliches ARPAnfrage von der realen Schnittstelle der Linux-Box an den Server, die besagt, dass die neu zugewiesene IP-Adresse (an eine der virtuellen Schnittstellen...) der MAC-Adresse der realen Schnittstelle „gehört“. Dadurch wird die ARP-Tabelle des Servers korrekt aktualisiert.

Dies erklärt übrigens auch, warum es funktioniert, einige Zeit zu warten, bevor der SNMP-Verkehr gestartet wird: Der ARP-Tabelleneintrag des Servers ist veraltet, sodass der Server eine ARP-Anfrage sendet, die beantwortet wirdkorrektbis zumechte Schnittstelle

Answer 2

Warum richten Sie kein Bridge-Gerät ein? brctl addbr bridgeFügen Sie die IP- und MAC-Adresse des physischen Geräts zu dieser Bridge hinzu, verschieben Sie das Gerät (ohne IP) zur Bridge und hängen Sie dann auch Ihre VIFs an die Bridge an.