Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Thomas Braun]

@wildbill sagte in Problem mit Zugriff aus VLAN nach 2. virt. Netzwerkkarte:

Du bist doch Linux-Spezi.

Aber kein Netzwerker. Kann ich nix zu sagen.

[Wildbill]

@thomas-braun Ok, ja, hast Recht, ist wohl eher was für Netzwerker. Schönen Abend. :blush:

[BananaJoe]

@wildbill deine Linux-Distribution konnte dem ganzen nicht entnehmen aber

• Dienste könnten an eine Netzwerkschnittstelle oder IP-Adresse gebunden sein.
  
  Das Bild ist vom iobroker, bei SSH & Co kann es auch einstellgestellt werden. Wobei Default in der Regel alle Schnittstellen sind
• Firewall auf der Linux-Büchse?

[Wildbill]

@bananajoe Hi, dachte ich hatte es erwähnt. Es ist jeweils Debian Bullseye im Einsatz.
Firewall ist nix auf den Linuxen am Laufen. Ich habe ja quasi nur den iobroker-lxc in Proxmox gestoppt, eine weitere Netzwerkkarte hinzugefügt mit dem zweiten VLAN und wieder gestartet. Deshalb ist auch kein Dienst an irgendeine Netzwerkkarte gebunden. Zumindest nicht von mir aktiv geändert. Von Geräten aus dem VLAN 100 ist iobroker ja sowohl per SSH als auch mit den diversen Diensten, die auf ihm laufen, erreichbar. Aber eben nur unter 192.168.100.14. Geräte aus dem VLAN 20 erreichen ihn genauso per SSH, nur eben nicht unter 192.168.100.14 (was ja vorher ging) sondern nur noch per 192.168.20.65. Gleiches gilt für die iobroker-Adapter. Vor der Umstellung, als ich den Slave aber bereits aufgelöst und die Adapter auf den Master, der da ausschließlich die 192.168.100.14 hatte, verschoben hatte, war die Verbindung auf diese IP bei einigen möglich. nach der Umstellung musste ich bei manchen Geräten explizit die IP aus dem VLAN 20 angeben, damit die Verbindung wieder lief.

Es scheint mir schon irgendwie ein Binding zu geben, welches Linux aber dann automatisch erstellt. Wenn eine Anfrage (abseits Ping) aus einem VLAn kommt, zu dem eine passende lokale IP existiert, so wird die Anfrage nur beantwortet, wenn sie auch an diese IP kommt. Nur, wo stell ich das ein. Ich hatte diesen Effekt auch bereits mal bei Ubuntu (OK, das setzt auf Debian auf) und auch mal bei Manjaro. Mit einer einzigen IP regelt alles die Firewall auf dem Router, bei mehreren IPs in verschiedenen VLAN regelt sich Linux das selber hin, unabhängig davon, was im Router die Firewall erlauben würde.

Gruss, Jürgen

[BananaJoe]

@wildbill die Meldung klingt ja nun schon anders, ich hatte verstanden das nur noch aus dem 192.168.20.er Netz der Zugriff funktioniert ...

1. haben die Geräte im 192.168.20.x Netzwerk ein Gateway?
2. ist über das Gateway das 182.168.100.x Netzwerk erreichbar? (ja, denn Ping geht ja)
3. Wenn das Gateway eine Firewall ist - gibt es denn eine Zugriffsregel welche den Zugriff auf den entsprechenden Port / Protokoll vom 192.168.20.x im 192.168.100.x Netzwerk erlaubt?

Ich tippe auf Punkt 3 ...

[Wildbill]

@bananajoe Ja, es gibt ein Gateway (Egderouter 4). Dort ist die Firewall so gesetzt, dass aus dem VLAN 20 die 192.268.100.14 erreichbar ist und vice-versa. Das funktioniert ja auch, solange der iobroker nur die IP 192.168.100.14 hat. Dann ist er von dort erreichbar. Sobald er zusätzlich eine zweite virtuelle NIC hat mit IP aus dem VLAN 20 ist er aus dem VLAN 20 nur unter der IP 192.168.20.65 und aus dem VLAN 100 nur unter 192.168.100.14 erreichbar. Außer der zweiten Netzwerkarte in Proxmox ändert sich nichts.
Ich habe es auch nochmals mit einem nackten frischen Debian als VM getestet, gleiches Verhalten. Mit einer IP aus nur einem VLAN und passenden Firewall- und Routing-Settings ist die VM aus beiden VLAN erreichbar. Sobald eine zweite IP aus dem jeweils anderen VLAN hinzukommt, geht auf beide IPs nur noch PING, SSH und Webdienste laufen dann ausschließlich nur noch unter der jeweiligen VLAN-IP.

Gruss, Jürgen

[Wildbill]

Kleines Update:
Ich habe noch ein drittes VLAN im Bereich 192.168.98.0/24, in welchem nur meine Switche und Access Points liegen. Dient als Managment LAN. Darin läuft auf einer VM ein Unifi controller. Der hat die IP 192.168.98.65. Von diesem aus sind sowohl die 192.168.100.14 als auch die 192.168.20.65 pingbar und per SSH erreichbar. Scheint also, dass Linux/Debian bei mehr als einer Netzwerkkarte aus verschiedenen IP-Bereichen bei eingehendem Verkehr nur das zulässt, was dann für die Karte aus dem jeweils eigenen Netz kommt. Ankommender Verkehr aus dem jeweils anderen Netz wird blockiert, ankommender Verkehr aus irgendeinem anderen Netz kommt wieder durch.

Gruss, Jürgen

[BananaJoe]

@wildbill öhm, jetzt habe ich es vom Gedanken her: Der Rückweg ist falsch / fehlt. Goldene Netzwerkregel.

Wenn du von der IP 192.168.20.99 auf die 192.168.100.14 zugreifst geht das Paket üb er dein Gateway 192.168.20.254 zur 192.168.100.254 zur 192.168.100.14

Die 192.168.100.14 hat aber ja auch die IP-Adresse 192.168.20.65
Und deren Routing schickt die Antwort dann über die 2. NIC raus.

Jetzt hat dein Rechner eine Frage an die 192.168.20.254 zur Weiterleitung übermittelt, bekommt die Antwort aber von der 192.168.20.65

Das funktioniert nicht

[Wildbill]

@bananajoe Ja, das hört sich sinnvoll an, an den Rückweg hab ich so gar nicht gedacht. Hört sich plausibel an :dizzy_face:
Dann werde ich damit leben, bevor ich nun Himmel und Hölle in Bewegung setze. Die Links und Lesezeichen habe ich bereits alle mal angepasst, iobroker läuft und tut alles, was er soll.
Die Frage wäre somit eher nur noch akademischer Natur und ich bin dennoch zufrieden.

Danke fürs Mitdenken und schubbsen in die richtige Gedankenrichtung. :+1:

Gruss, Jürgen

[BananaJoe]

@wildbill Also verschiedene Wege für Hin- und Rückweg sind schon im TCP/IP Protokoll erlaubt. Ob die Geräte damit immer zurecht kommen steht auf einem anderen Stern.