Zu blöd für VLAN-Tagging?

[Pummeluff]

Guten Abend,

ich wollte mich mal mit dem Thema VLAN-Tagging auseinandersetzen. Normalerweise hilft da die KI ganz gut. Aber hier stößt die irgendwie auch an ihre Grenzen.

Hardware

• Router: Unifi Cloud Gateway Ultra, Version 4.4.9, Netzwerkversion 10.0.162
• Switch: USW PoE
• Rechner am Port 7: NAS Helios 64 mit Debian 13

Netzwerk

• Nativ: 192.168.109.0/24
• VLAN: 192.168.2.0/24 (VLAN-Id: 2)

Was will ich
Auf dem NAS will ich eine secondary IP anlegen: 192.168.2.5/24. Ziel soll später mal ein DNS-Rerouting sein. D.h. hardcodierte DNS-Server im Netzwerk sollen zwangsläufig an mein Pihole umgeleitet werden.

Was hab ich jetzt konfiguriert

sudo ip link add link end0 name end0.2 type vlan id 2
sudo ip addr add 192.168.2.5/24 dev end0.2
sudo ip link set dev end0.2 up

Angezeigt wird mir

2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 64:62:66:d0:05:ac brd ff:ff:ff:ff:ff:ff
    altname enx646266d005ac
    inet 192.168.109.10/24 brd 192.168.109.255 scope global end0
       valid_lft forever preferred_lft forever
8: end0.2@end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 64:62:66:d0:05:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.5/24 scope global end0.2
       valid_lft forever preferred_lft forever

Jetzt würde ich eigentlich erwarten, dass ich das VLAN-Gateway 192.168.2.1 anpingen kann. Nur leider bekomme ich hier ein Timeout. Die anderen Rechner im Netz, auf deren Port nicht das VLAN 2 getaggt ist, können das Gateway anpingen.

Debugging

dmesg | grep -i vlan
[    2.097256] 8021q: 802.1Q VLAN Support v1.8

dhclient -v end0.2
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/end0.2/64:62:66:d0:05:ac
Sending on   LPF/end0.2/64:62:66:d0:05:ac
Sending on   Socket/fallback
DHCPDISCOVER on end0.2 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on end0.2 to 255.255.255.255 port 67 interval 6
ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
From 192.168.2.5 icmp_seq=1 Destination Host Unreachable
 
tcpdump -i end0 -e -n 'vlan and (arp or icmp)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on end0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:57:08.524666 64:62:66:d0:05:ac > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 2, p 0, ethertype ARP (0x0806), Request who-has 192.168.2.1 tell 192.168.2.5, length 28

Woran scheitert es?

 

[Stock86]

Wer hat denn die 192.168.2.1? Der Router? Ist da das VLAN 2 auch vergeben?

Und welcher Switchport ist mit dem Router verbunden? Ist der Port auch im VLAN 2?

Und in deiner Adressübersicht der NAS erkenne ich so auch nicht, dass er das VLAN 2 angezogen hat.

 

[TheCadillacMan]

Ist das VLAN 2 auch am Port an dem der Router hängt getagged? Sieht auf dem Screenshot nicht so aus.

 

[-=Azrael=-]

Ka wie das bei Unifi läuft/heißt, simples vLAN:

Access = ungetagged, Ports werden z.B. dem vLAN 2 zugewiesen, hier kommen deine Endgeräte dran, die sollen in der Regel von vLAN Tags nichts mitbekommen. Jedes Endgerät ist automatisch im jeweiligen vLAN, dass dem jeweiligen Port zugewiesen wurde.( Port 1-3 z.B. vLAN 2, Port 4 -6 vLAN 3 usw.)

Trunk = getagged, hier werden deine vLANs getagged zugewiesen, d.h. der Port kann mehrere vLANs "tragen"(z.B. vLAN 2 bis 10).
Uplink zum Router, der dann das eigentliche tagging der frames und auch das Inter-vLAN-Routing übernimmt, sofern gewünscht.
Die vLANs müssen dann auch im Router inkl. DHCP/NetzID etc. konfiguriert werden.

 

[Pummeluff]

Wer hat denn die 192.168.2.1? Der Router? Ist da das VLAN 2 auch vergeben?

Ja, hat der Router, also das Cloud Gateway.

Und welcher Switchport ist mit dem Router verbunden? Ist der Port auch im VLAN 2?

Ist das VLAN 2 auch am Port an dem der Router hängt getagged? Sieht auf dem Screenshot nicht so aus.

Danke, das war's.

 

[Stock86]

Also funktioniert es jetzt?

 

[Pummeluff]

Ja, hab's hinbekommen.

Allerdings hab ich jetzt das VLAN wieder gelöscht. Ich hab das DNS-Rerouting auch ohne VLAN hinbekommen. Das DNS ist jetzt relativ zugenagelt.

Erreichte Ziele:

• Alle DNS-Abfragen, die nicht an den Pihole sondern öffentliche DNS-Server gehen, werden trotzdem an den Pihole weitergeleitet.
• DNS over TLS wird über die Firewall geblockt
• DNS over HTTPS wird deaktiviert, DoH-Server werden von Pihole geblockt

Offen:
Ich müsste noch in das Cloud Gateway eine Blockliste an DoH-IPs aufnehmen (Port 443).

Falls es jemandem hilft.

Mein Pihole
Hat 2 IP-Adressen. Pihole hört auf allen Interfaces.

• 192.168.109.10: Primäre IP-Adresse, die auch per DHCP verteilt wird.
• 192.168.109.50: DNS-Reroute-Adresse

Auf dem Router (Cloud Gateway
DNAT-Regel: Alle Anfragen auf Port 53, die nicht an 192.168.109.10 gehen, werden auf 192.168.109.50 umgeleitet

• Translated IP: 192.168.109.50, Port 53
• IP Version IPv4, TCP/UDP
• Source: 192.168.109.10 - Match Opposite, Port Any
• Destination: IP Any, Port: 53

SNAT-Regel: Alle Antworten von 192.168.109.50 werden über das Gateway geschickt.

• Translated IP: 192.168.109.1 (=Gateway)
• IP Version IPv4, TCP/UDP
• Source: Network 192.168.109.0/24, Port: Any
• Destination: IP 192.168.109.50, Port 53

Die Regeln decken schon mal DNS und DNSSEC ab

DoH
Im Pihole hab ich eine Liste von zusätzlichen Einträgen, die ich blocke:
/etc/pihole/hosts-adblock-ext.list

0.0.0.0 use-application-dns.net

Das ist (lt. KI) die Canary Domain, die Firefox und Chrome nutzen, um zu prüfen, ob DoH im lokalen Netz erlaubt ist. Schlägt das fehl, wird auf den lokalen DNS zurückgegriffen.

Dann hab ich noch eine DoH-Blockliste im Pihole eingebunden.

Der DoH-Test war schon mal negativ, also positiv. Die Server konnten nichts auflösen.