V-LAN Verständnisfragen

schimmelmann · Feb 7th 2019

Hallo Ihr Lieben!

Da es den Rahmen meiner ursprünglichen Frage zur MUNIN-Überwachung, die nun funktioniert sprengen würde, fange ich hier mal ein neues Thema an:

Ich habe mittlerweile viele Beiträge zum Thema VLAN durchgelesen.
Nun haben sich diverse Fragen ergeben, die ich hier mal stellen möchte:

Ausgangssituation:
Ich habe zwei VSERVER der Generation 8 gebucht. Diese möchte ich per VLAN verbinden.
Dazu habe ich testweise das kostenlose VLAN hier bei Netcup gebucht.

Auf beiden Servern habe ich im SCP die virtuelle Netzkarte aktiviert.
Auf beiden Servern habe ich in der interfaces.conf folgendes eingetragen:

Server A:

Code

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static    
address 37.120.xx.xx/22    
dns-nameservers 46.38.xxx.xxx 46.38.252.230 2a03:4000:xxxx::fce6    
gateway 37.120.xxx.x    
post-up ifup eth0:1


auto eth0:1
iface eth0:1 inet6 static    
address 2a03:4000:f:57b:543f:afff:xxxx:xxxx/64    
gateway XXXX::1

# vLAN
auto ens6
iface ens6 inet static    
address 192.168.xxx.1/24    
netmask 255.255.255.0

Display More

Server B:

Code

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static    
address 46.232.251.xxx/xx    
dns-nameservers 46.38.xxx.xxx 46.38.xxx.xxx 2a03:4000:xxxx::fce6    
gateway 46.232.xxx.x    
post-up ifup eth0:1


auto eth0:1
iface eth0:1 inet6 static    
address 2a03:4000:2b:488:7897:acff:xxxx:xxxx/64    
gateway xxxx::1


# vLAN
auto ens6
iface ens6 inet static    
address 192.168.xxx.2/24    
netmask 255.255.255.0

Display More

Soweit dass was ich bisher gemacht habe.
Es gibt noch eine Firewall auf beiden Servern.
Wie müsste da die Regel lauten, damit beide Server kommunizieren können?
Über die öffentlichen IP's können sich beide Rechner anpingen.
Über die VLAN IP's nicht.

Gibt es noch weiteres zu beachten?

Da meine Englischkenntnisse sehr eingeschränkt sind, würde ich mich freuen, wenn es mir jemand verständlich am oben genannten Beispiel erklären könnte.
Mir hilft i.R. ein praktisches Beispiel besser um das Grundsätzliche zu verstehen.

whoami0501 · Feb 7th 2019

Wenn die Server uneingeschränkt per VLAN kommunizieren sollen, empfiehlt sich theoretisch folgendes auf beiden Servern:

Code

iptables -A INPUT -i ens6 -s 192.168.xxx.0/24 -j ACCEPT
iptables -A OUTPUT -o ens6 -j ACCEPT

Was mir noch spanisch vorkommt, ist dein "address 192.168.xxx.y/24" - das /24 braucht man eigentlich nicht. Das beschreibt ja das genutzt Subnet, aber dafür gibst du darunter ja die netmask an.

Was sagt den ein ip address show?

Paul · Feb 7th 2019

Irgendwas passt da auch bei den Interface Namen noch nicht. Auf der einen Seite nutzt du eth0, dann aber bei dem VLAN Interface ens6. Schau lieber erstmal auf dem System nach wie die wirklich heißen (wie auch whoami0501 angedeutet hat).

schimmelmann · Feb 7th 2019

Quote from whoami0501
Wenn die Server uneingeschränkt per VLAN kommunizieren sollen, empfiehlt sich theoretisch folgendes auf beiden Servern:
Code
iptables -A INPUT -i ens6 -s 192.168.xxx.0/24 -j ACCEPT
iptables -A OUTPUT -o ens6 -j ACCEPT
Was mir noch spanisch vorkommt, ist dein "address 192.168.xxx.y/24" - das /24 braucht man eigentlich nicht. Das beschreibt ja das genutzt Subnet, aber dafür gibst du darunter ja die netmask an.

Was sagt den ein ip address show?

Danke für deine Antwort!
Die /24 hatte ich aus einem Beitrag übernommen. Die werde ich mal entfernen.
Und die Firewallregeln teste ich mal.
Dann melde ich mich wieder.
Bei ip adress show wurde die Schnittstelle ens6 angezeigt und keine Fehler gemeldet.
Wenn ich nicht weiter komme, kann ich ja die Ausgabe hier posten.
Lg

schimmelmann · Feb 7th 2019

Quote from Paul

Irgendwas passt da auch bei den Interface Namen noch nicht. Auf der einen Seite nutzt du eth0, dann aber bei dem VLAN Interface ens6. Schau lieber erstmal auf dem System nach wie die wirklich heißen (wie auch whoami0501 angedeutet hat).

Die Ausgabe von

ip li

ergab:

Code

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1    link/loopback etc.
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000    link/ether etc.
3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000    
link/ether etc.

Aus diesem Grund gehe ich davon aus, dass ens6 die richtige Schnittstelle ist...
Bin ich da im Irrtum?

Paul · Feb 7th 2019

Quote from schimmelmann

Bin ich da im Irrtum?

Alles ok. Ich nehme meinen Einwand zurück. Überrascht bin ich aber trotzdem. So eine Kombination sehe ich nämlich zum ersten Mal Hast du da zufällig selbst an den udev Regeln geschraubt?

Wie konfigurierst du denn die Firewall? Manuell mit iptables. Oder mit einem Wrapper wie UFW, Shorewall oder Firewalld?

schimmelmann · Feb 7th 2019

Das mit der virtuellen Festplatte kommt von Netcup.
Die Firewall ist das Problem weil die über die Webhostingfläche keyhelp geregelt wird. Die haben eine eigene Verzeichnisstruktur. Da bin ich gerade dran.
Wichtig war mir, ob die Konfiguration schon mal ok ist, denn dann kann es ja nur an der Firewall liegen.
Das schränkt schon mal den Fehler ein.

whoami0501 · Feb 7th 2019

Der Unterschied der Interface-Namen könnte von den Einstellungen des Netzwerkadapters im SCP abhängen. Je nachdem, was man dort für einen Gerätetyp eingestellt hat.

Die Frage ist halt, ob das Netzwerkinterface vom VLAN auch korrekt konfiguriert und hochgefahren ist. Daher wäre die Ausgabe von ip address show ens6 wichtig.

schimmelmann · Feb 7th 2019

Ausgabe von ip address show ens6

Code

3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    
link/ether 56:3f:af:db:f7:c5 brd ff:ff:ff:ff:ff:ff    
inet 192.168.xxx.1/24 brd 192.168.xxx.255 scope global ens6       
valid_lft forever preferred_lft forever    
inet6 fe80::543f:afff:fedb:f7c5/64 scope link        
valid_lft forever preferred_lft forever

Code

3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000    
link/ether 7a:97:ac:af:18:bc brd ff:ff:ff:ff:ff:ff    
inet 192.168.xxx.2/24 brd 192.168.xxx.255 scope global ens6       
valid_lft forever preferred_lft forever    
inet6 fe80::7897:acff:feaf:18bc/64 scope link        
valid_lft forever preferred_lft forever

whoami0501 · Feb 7th 2019

Das sieht gut aus. Dann wird es auf jeden Fall an der Firewall liegen.

Meine Interface-Config schaut auch so aus, und funktioniert problemlos.

schimmelmann · Feb 7th 2019

Quote from whoami0501

Das sieht gut aus. Dann wird es auf jeden Fall an der Firewall liegen.

Meine Interface-Config schaut auch so aus, und funktioniert problemlos.

Danke, dass ist schon mal ein wichtiger Anhaltspunkt. Dann werde ich mich an die Firewall machen.
Lg

Exiver · Feb 7th 2019

Ohne mich genauer mit der vlan-Option ausseinander gesetzt zu haben: Besteht hier Layer-2 Konnektivität? Falls ja, könnte man das Setup ersteinmal folgend prüfen:

- sudo apt install arping

- sudo arping 192.168.xxx.2

(falls das nicht tut, kannst du mit -i ens6 noch das Interface angeben)

- Falls es weiterhin nicht tut, kannst du zunächst noch prüfen, ob der Server überhaupt die MAC-Adresse des anderen Systems gelernt hat:

arp | grep 192.168.xxx.2

Edit: Alternativ mal die Firewall für eine Minute abschalten und schauen, ob der Ping dann ankommt ;o)

schimmelmann · Feb 7th 2019

Quote from Exiver

Ohne mich genauer mit der vlan-Option ausseinander gesetzt zu haben: Besteht hier Layer-2 Konnektivität? Falls ja, könnte man das Setup ersteinmal folgend prüfen:

- sudo apt install arping

- sudo arping 192.168.xxx.2

(falls das nicht tut, kannst du mit -i ens6 noch das Interface angeben)

- Falls es weiterhin nicht tut, kannst du zunächst noch prüfen, ob der Server überhaupt die MAC-Adresse des anderen Systems gelernt hat:

arp | grep 192.168.xxx.2

Edit: Alternativ mal die Firewall für eine Minute abschalten und schauen, ob der Ping dann ankommt ;o)

Display More

Danke für den Hinweis. Das werde ich gleich mal testen

schimmelmann · Feb 7th 2019

mit arping -i ens6 192.168.xxx.2 klappt es. Dann gehe ich noch mal an die Firewall

eripek · Feb 7th 2019

Zur Interface-Verwirrung - die klassische Interface-Nomenklatur eth0, eth1 usw. lässt sich für einzelne Interfaces wiederherstellen. Das ist etwa nachfolgend beschrieben: https://www.freedesktop.org/wi…bleNetworkInterfaceNames/

Ich vermute, dass so etwas zuvor einmal angewendet worden ist.

Möchte man generell wieder das alte Schema herstellen, geht das über einen Kernelparameter - näher beschrieben in https://askubuntu.com/question…es-with-alternate-kernels. Kurzfassung, wenn GRUB als Bootloader verwendet wird (quiet splash stand schon da):

Code

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash net.ifnames=0 biosdevname=0"

Danach update-grub ausführen - nach einem Neustart sollten die Interfaces alle wieder eth* heissen.

---

Zum VLAN selbst: Ich vermute, dass hier „VxLAN“ verwendet wird, also die VLANs eigentlich zwischen den Servern- und Serverstandorten via UDP getunnelt werden - davon bekommen wir als Nutzer aber nichts mit. Wir stellen im SCP ein, dass ein zusätzliches Interface aus dem jeweiligen VLAN dem Gast zur Verfügung gestellt wird.

Empfohlen ist dabei die Verwendung von „virtio“. Linux kommt mit diesem Treiber am besten zurecht. Die anderen Emulationen würde ich nur verwenden, wenn das Betriebssystem des Gastes kein Virtio beherrscht.

Das VLAN auf der nach dem Neustart des Gastes hinzugekommenen Schnittstelle ist bereits „untagged“. D.h. die Schnittstelle verhält sich so, dass auf die VLAN-Nummer keine Rücksicht mehr genommen werden muss. Sie kann auf Layer 2 direkt mit den anderen VPS/Rootservern im selben Netcup-VLAN kommunizieren. Neben der Firewall würde ich grundlegend auch schauen, ob nicht (etwa wegen eines Tippfehlers) die Netzwerkschnittstellen womöglich nicht mit derselben Subnetzmaske ausgestattet wären, oder, ob sonst gar eine Adress-Kollision vorliegt.

Klappt es immer noch nicht, würde ich den Support kontaktieren, denn es kann sein, dass, wenn meine Vermutung richtig ist, UDP nicht nur mit der durch VxVLAN erhöhten MTU nicht durchkommt.

Ich würde mich über Feedback, ob ich richtig gelegen bin, sehr freuen.

schimmelmann · Feb 7th 2019

Quote

Zur Interface-Verwirrung - die klassische Interface-Nomenklatur eth0, eth1 usw. lässt sich für einzelne Interfaces wiederherstellen. Das ist etwa nachfolgend beschrieben: https://www.freedesktop.org/wi…bleNetworkInterfaceNames/

Ich vermute, dass so etwas zuvor einmal angewendet worden ist.

Von mir nicht. Ich habe das VLan bei Netcup geordert und die Virtuellen Schnittstellen im SCP angelegt. Durch ip li

Bin ich dann auf die Bezeichnung gestoßen.
Die anderen Infos muss ich noch durchgehen. Heute wird das aber nichts mehr. Und natürlich werde ich hier, soweit es etwas neues gibt auch berichten.
Fürs erste erst einmal herzlichen Dank! Bisher waren die Informationen sehr hilfreich. Lg

schimmelmann · Feb 8th 2019

Hallo Ihr Lieben!
Ich danke euch herzlich für eure Antworten.
Durch eure Beiträge wurde klar, dass meine Konfiguration in Ordnung ist und es an der Firewall liegen musste.
Ich habe dann in dem Forum von KeyHelp nach den Firewalleinstellungen gefragt. Dort brachte mich jemand darauf, was ich die ganze Zeit übersehen hatte...
Die IP-Bereiche die ich für das VLAN nutzen wollte waren standardmäßig komplett blockiert.
Nun können sich die beiden Server direkt anpingen.
Somit bin ich ein ganzes Stück weiter gekommen. Ich hatte schon an meinem Verstand gezweifelt.
Lg Jörn

Tags