☰

Linux-Bridge mit SSH-Tap-Schnittstellen (Cloud -> LAN)

tag-icon • tag-icon networking bridge
Linux-Bridge mit SSH-Tap-Schnittstellen (Cloud -> LAN)

Ich habe in letzter Zeit ziemlich viel zu diesem Thema gelesen - weil ich es nicht gewohnt bin, auf so „niedrigen Ebenen“ zu arbeiten - aber ich kann nicht mit dem Finger darauf zeigen, was ich falsch mache. Glauben Sie mir, ich habe es versucht ;)

Ich möchte einen Cloud-Server anschließen, da er Teil unseres Firmen-LAN war.

Ich habe mich entschieden, eine Layer-2-Brücke () zu erstellen br0. Der Hauptgrund dafür ist, dass ich gesendete Pakete vom LAN empfangen muss, damit ein Gerät vom Cloud-Server erkannt wird.

Ich habe auf dem Cloud-Server eine Route erstellt, um das LAN-Subnetz durch die tap0Schnittstelle zu leiten.

Alle iptablesund ebtableshaben eine Standardrichtlinie von ACCEPT(Bearbeiten: Es sind keine Regeln definiert und sie sind sogar deaktiviert).

Die ARP-Tabelle auf dem LAN-Client zeigt den IP/MAC-Eintrag des Cloud-Servers.

Ich kann br0aus der Cloud einen Ping ausführen und ich kann die Cloud-Maschine tap0(statisch definierte IP im Client-Subnetz) vom LAN-Client aus anpingen.

tcpdumpWenn ich auf beiden Schnittstellen ein () mache cloud tap0 and LAN br0, kann ich sehen, dass LAN-Verkehr (STP, IP, ARP, ...) fließt.

Und hier ist es nicht mehr so ​​toll: Ich kann keine anderen Rechner im LAN erreichen (wenn ich das LAN-Gateway anpinge, erhalte ich die Meldung „Zielhost nicht erreichbar“. Wenn ich den Test mit anderen LAN-Rechnern durchführe, bekomme ich keine Antwort).

PS: zwing mich nicht, OpenVPN zu installieren ^^

bearbeiten:

$ bridge link

2: eth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 
4: tap0 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100

$ brctl show

bridge name     bridge id               STP enabled     interfaces
br0             8000.00155da90b0b       no              eth0
                                                        tap0

$ ip link

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 8e:15:41:dc:70:b0 brd ff:ff:ff:ff:ff:ff
11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:a9:0b:0b brd ff:ff:ff:ff:ff:ff

Antwort1

Nach all diesen Stunden war ich ziemlich zuversichtlich, dass das, was ich tat, nicht allzu weit von der Realität entfernt war.

Ich beschloss, dieselbe Cloud-Instanz mit einem neuen Host in meinem Heim-LAN zu verbinden. Es funktionierte ohne größere Probleme.

Ich bin mir immer noch nicht sicher, was das ursprüngliche Problem verursacht (vielleicht ein teures Gerät im Unternehmensnetzwerk?), aber zumindest weiß ich, dass es nicht von mir kommt :)

verwandte Informationen