Ich betreibe ein Dual-Stack-Heimnetzwerk (IPv4 und IPv6) mit ein paar VLANs, um IoT-Geräte (VLAN 20) von normalen Benutzern (VLAN 10) von Netzwerkhardware (ungetaggtes VLAN) zu trennen. Momentan hoste ich lokales DNS (und einige andere Dienste) auf einem Raspberry Pi 3 B + (läuft Raspbian), der normalerweise von dem nicht gekennzeichneten VLAN lebt, aber ich möchte versuchen, die Adressen auf den anderen 2 VLANs (10.) Anzugeben und 20) als Experiment (vereinfachen Sie die Firewall-Regeln, reduzieren Sie die Belastung des Routers usw.). Mein erster Versuch ist fehlgeschlagen, also habe ich versucht, die Dinge zu vereinfachen und einfach in das nicht gekennzeichnete VLAN plus VLAN 10 zu platzieren, aber auch das ist fehlgeschlagen, und ich kann nicht verstehen, warum.
Einzeladresse einrichten
Hier ist das normale Setup (nur eine Adresse im nicht gekennzeichneten VLAN, nichts im VLAN 10 oder 20):
Und hier sind die resultierenden Adressen, die ich bekomme:
$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether <MAC_ADDR> brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fd:<IPv6_ULA_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 85965sec preferred_lft 13965sec inet6 <IPv6_GLOBAL_ADDR_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 85965sec preferred_lft 13965sec inet6 fd:<STATIC_IPv6_ULA>/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::<IPv6_LLA>/64 scope link valid_lft forever preferred_lft forever
Dies funktioniert gut, ich kann über den Router an die Hosts in den VLANs 10 und 20 routen. Das Problem entsteht, wenn versucht wird, eine Schnittstelle zu einem der VLANs hinzuzufügen.
Ein VLAN hinzufügen
Um eine Adresse in VLAN 10 hinzuzufügen, habe ich bei der Konfiguration mit einer Adresse die folgende Konfiguration hinzugefügt:
Und hier sind die resultierenden Adressen, die ich bekomme:
$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether <MAC_ADDR> brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fd:<STATIC_IPv6_ULA>/64 scope global noprefixroute valid_lft forever preferred_lft forever 3: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether <MAC_ADDR> brd ff:ff:ff:ff:ff:ff inet 10.0.10.10/24 brd 10.0.10.255 scope global eth0.10 valid_lft forever preferred_lft forever inet6 fd:<IPv6_VLAN_10_ULA_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86377sec preferred_lft 14377sec inet6 <IPv6_GLOBAL_ADDR_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86377sec preferred_lft 14377sec inet6 fd:<STATIC_IPv6_VLAN_10_ULA>/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::<IPv6_LLA>/64 scope link valid_lft forever preferred_lft forever
Dies war sehr seltsam. Ich verlor meine globale IPv6-Adresse im nicht gekennzeichneten VLAN sowie meine Link-Local-Adresse (LLA) und die ULA, die ich von SLAAC bekomme. Ich habe ein paar Pings ausprobiert, um zu sehen, was funktioniert, und ich habe folgendes gefunden:
So funktionierte IPv4 in beiden VLANs einwandfrei, IPv6 war jedoch in dem nicht gekennzeichneten VLAN defekt. Ich habe nach syslogallen Nachrichten gesucht dhcpcdund diese gefunden:
00:28:23 HOSTNAME systemd[1]: Starting dhcpcd on all interfaces... 00:28:23 HOSTNAME dhcpcd[340]: dev: loaded udev 00:28:23 HOSTNAME dhcpcd[340]: eth0: waiting for carrier 00:28:23 HOSTNAME dhcpcd[340]: eth0.10: waiting for carrier 00:28:24 HOSTNAME dhcpcd[340]: eth0: carrier acquired 00:28:24 HOSTNAME dhcpcd[340]: DUID <DUID> 00:28:24 HOSTNAME dhcpcd[340]: eth0: IAID <IAID> 00:28:24 HOSTNAME dhcpcd[340]: eth0: IAID conflicts with one assigned to eth0.10 00:28:24 HOSTNAME dhcpcd[340]: eth0: adding address fe80::<IPv6_LLA> 00:28:24 HOSTNAME dhcpcd[340]: eth0: adding address fd:<STATIC_IPv6_ULA>/64 00:28:24 HOSTNAME dhcpcd[340]: eth0: adding route to fd:<STATIC_IPv6_ULA_PREFIX>/64 00:28:24 HOSTNAME dhcpcd[340]: eth0: probing address 192.168.1.10/24 00:28:24 HOSTNAME dhcpcd[340]: eth0.10: carrier acquired 00:28:24 HOSTNAME dhcpcd[340]: eth0.10: IAID <IAID> 00:28:24 HOSTNAME dhcpcd[340]: eth0.10: IAID conflicts with one assigned to eth0 00:28:24 HOSTNAME dhcpcd[340]: eth0: deleting address fe80::<IPv6_LLA> 00:28:24 HOSTNAME dhcpcd[340]: eth0.10: adding address fe80::<IPv6_LLA> 00:28:24 HOSTNAME dhcpcd[340]: eth0.10: adding address fd:<STATIC_IPv6_VLAN_10_ULA>/64 00:28:24 HOSTNAME dhcpcd[340]: eth0.10: adding route to fd:<STATIC_IPv6_ULA_VLAN_10_PREFIX>/64 00:28:24 HOSTNAME dhcpcd[340]: eth0.10: probing address 10.0.10.10/24 00:28:24 HOSTNAME dhcpcd[340]: eth0: soliciting an IPv6 router 00:28:25 HOSTNAME dhcpcd[340]: eth0.10: soliciting an IPv6 router 00:28:29 HOSTNAME dhcpcd[340]: eth0.10: using static address 10.0.10.10/24 00:28:29 HOSTNAME dhcpcd[340]: eth0.10: adding route to 10.0.10.0/24 00:28:29 HOSTNAME dhcpcd[340]: eth0.10: adding default route via 10.0.10.1 00:28:29 HOSTNAME dhcpcd[340]: forked to background, child pid 603 00:28:29 HOSTNAME systemd[1]: Started dhcpcd on all interfaces. 00:28:30 HOSTNAME dhcpcd[603]: eth0: using static address 192.168.1.10/24 00:28:30 HOSTNAME dhcpcd[603]: eth0: adding route to 192.168.1.0/24 00:28:30 HOSTNAME dhcpcd[603]: eth0: adding default route via 192.168.1.1 00:28:30 HOSTNAME dhcpcd[603]: eth0.10: Router Advertisement from fe80::<IPv6_LLA_OF_ROUTER> 00:28:30 HOSTNAME dhcpcd[603]: eth0.10: adding address <IPv6_GLOBAL_ADDR_FROM_SLAAC>/64 00:28:30 HOSTNAME dhcpcd[603]: eth0.10: adding address <IPv6_VLAN_10_ULA_FROM_SLAAC>/64 00:28:30 HOSTNAME dhcpcd[603]: eth0.10: adding route to <IPv6_GLOBAL_PREFIX_FROM_SLAAC>/64 00:28:30 HOSTNAME dhcpcd[603]: eth0.10: adding default route via fe80::<IPv6_LLA_OF_ROUTER> 00:29:17 HOSTNAME dhcpcd[603]: eth0.10: fe80::<IPv6_LLA_OF_ROUTER> is unreachable, expiring it 00:30:08 HOSTNAME dhcpcd[603]: eth0.10: fe80::<IPv6_LLA_OF_ROUTER> is reachable again
Es scheint also, dass es ein Problem gibt, das dazu führt, dass die LLA im nicht gekennzeichneten VLAN gelöscht wird. Dadurch wird verhindert, dass Routerankündigungen auf dieser Schnittstelle angezeigt werden.
Ich vermute, dass diese Einrichtung möglich sein sollte (mehrere VLANs pro Netzwerkkarte, die mit IPv6 arbeiten). Irgendwelche Ideen, was dieses Problem verursacht? Ist das nur ein Konfigurationsfehler von mir?
Falls es nützlich ist, hier die Kernel-Version von Raspbian, die auf dem Raspberry Pi läuft:
$ uname -a Linux HOSTNAME 4.14.70-v7+ #1144 SMP Tue Sep 18 17:34:46 BST 2018 armv7l GNU/Linux
Schnelle Aufnahme: Die MAC-Adressen (die Sie herausgearbeitet haben) der unmarkierten und der getaggten Schnittstelle sind identisch, daher sind die ff80: ... link-local-IPv6-Adressen gleich und werden daher gelöscht.
dirkt vor 5 Jahren
0
@dirkt: Sie dürfen gleich sein, _because_ sie sind linklokal und liegen daher in unterschiedlichen Bereichen. Wenn dhcpcd sie als Duplikat löscht, ist das falsch.
grawity vor 5 Jahren
0
@ pewter-bronco: Welche dhcpcd-Version verwendest du? Die Unterstützung für automatische IAIDs von mit VLAN gekennzeichneten Schnittstellen wurde nur in Version 7.0.0 hinzugefügt.
grawity vor 5 Jahren
0
Good point @grawity, sieht aus wie die standardmäßige Raspbian-Version von dhcpcd 3.2.3-11 ist. Etwas veraltet = P Ich werde in die Aktualisierung gehen ...
pewter-bronco vor 5 Jahren
0
Ja, dhcpcd ist in debian nicht mehr aktuell: https://tracker.debian.org/pkg/dhcpcd
pewter-bronco vor 5 Jahren
0
Nun, es sieht so aus, als ob die Versionsnummer von `apt` von` dhcpcd` nicht mit der auf dem System vorhandenen übereinstimmt: `$ sudo dhcpcd --version`` dhcpcd 6.11.5` `Copyright (c) 2006-2016 Roy Marples` `In Funktionen kompiliert: INET IPv4LL INET6 DHCPv6 AUTH` muss jedoch noch aktualisiert werden.
pewter-bronco vor 5 Jahren
0
1 Antwort auf die Frage
0
pewter-bronco
Danke für den Tipp @grawity! Das Problem war einfach das dhcpcdwar nicht mehr aktuell. Da @ grawity in den obigen Kommentaren erwähnt wurde, wurde dhcpcdin Version 7.0.0 nur die Unterstützung für automatische IAIDs auf Schnittstellen mit VLAN-Tags hinzugefügt. Hier war die Version meines Raspbian-Systems mit der Standardinstallation von apt:
$ sudo dhcpcd --version dhcpcd 6.11.5 Copyright (c) 2006-2016 Roy Marples Compiled in features: INET IPv4LL INET6 DHCPv6 AUTH
Falls es jemandem hilft, hier die Schritte, die ich zur Installation der neuesten Version (7.0.8) aus dem Quellcode unternommen habe:
wget https://github.com/rsmarples/dhcpcd/archive/dhcpcd-7.0.8.tar.gz tar xzf dhcpcd-7.0.8.tar.gz cd dhcpcd-dhcpcd-7.0.8 ./configure --libexecdir=/lib/dhcpcd --dbdir=/var/lib/dhcpcd5 make sudo make install
Beachten Sie, dass ich festgelegt dbdirauf /var/lib/dhcpcd5, obwohl diese Befehle verwenden im Allgemeinen empfehlen /var/lib/dhcpcd. Auf meinem System /var/lib/dhcpcd5wurde bereits von der vorhandenen Installation von verwendet dhcpcd, und /var/lib/dhcpcdexistierte nicht. Tu, was für dich sinnvoll ist.
Und jetzt funktioniert alles perfekt mit der hinzugefügten VLAN 10-Schnittstelle (und es funktioniert auch, wenn ich die VLAN 20-Schnittstelle hinzufüge). So sieht es mit der hinzugefügten VLAN 10-Schnittstelle aus:
$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether <MAC_ADDR> brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global noprefixroute eth0 valid_lft forever preferred_lft forever inet6 fd:<IPv6_ULA_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86382sec preferred_lft 14382sec inet6 <IPv6_GLOBAL_ADDR_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86382sec preferred_lft 14382sec inet6 fd:<STATIC_IPv6_ULA>/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::<IPv6_LLA>/64 scope link valid_lft forever preferred_lft forever 3: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether <MAC_ADDR> brd ff:ff:ff:ff:ff:ff inet 10.0.10.10/24 brd 10.0.10.255 scope global noprefixroute eth0.10 valid_lft forever preferred_lft forever inet6 fd:<IPv6_VLAN_10_ULA_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86381sec preferred_lft 14381sec inet6 <IPv6_VLAN_10_GLOBAL_ADDR_FROM_SLAAC>/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 86381sec preferred_lft 14381sec inet6 fd:<STATIC_IPv6_VLAN_10_ULA>/64 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::<IPv6_LLA_2>/64 scope link valid_lft forever preferred_lft forever
Interessanterweise ist die LLA für jede Schnittstelle einzigartig. Es sieht so aus, als würde es von der IAID abgeleitet, von der ich syslogjetzt sehe, dass sie auf jeder Schnittstelle eindeutig ist. Für eth0 wird meine IAID von meiner MAC-Adresse abgeleitet, aber für die VLAN 10-Schnittstelle ist die IAID einfach ff:00:00:0a. Für die VLAN 20-Schnittstelle gilt dies ff:00:00:14. Es scheint also, dass die IAID einfach ist ff::VLAN_NUMBER, was zu eindeutigen LLAs auf jeder Schnittstelle führt. Was auch immer, das ist eher eine Neugier als ein echtes Thema ...
Unabhängig davon werden alle Schnittstellen ordnungsgemäß konfiguriert und können sowohl interne Netzwerk-Hosts als auch externe Internet-Hosts erreichen. Nochmals vielen Dank @grawity!