Messages

Ich würde zyxel nwa50ax Pro empfehlen. Dann auch gleich mit OpenWRT. Ich habe die bei Mir laufen, sehr stabil. Für Openwrt sind weiterhin Anpassungen notwendig, aber als Router laufen die im Standard nicht.

Die Reichweite ist in House sehr gut. Die Leistung für die Clients auch.

Die Konfiguration von OpenWRT ist gewöhnungsbedürftig, das stimmt. Aber trotzdem relativ selbsterklärend. Wichtig ist eigentlich dass für einen AP bestimmte Pakete geändert und andere weg gelassen werden sollten. Außerdem läuft die Anbindung der SSIDs, wie schon geschrieben, über Bridges. Mach gerne einen extra Thread auf wenn dazu Fragen sind.

Zur Reichweite in die Tiefgarage ist es wohl schwierig, was zu empfehlen. Das hängt sehr start von der Bausubstanz ab, und Tiefgarage klingt nach dicker Betondecke, was schwierig werden könnte. Das kann wohl nut ausgetestet werden.

Sehe ich auch so. Da können wir kaum etwas empfehlen, am ehesten noch, nimm einen AP mit externen Antennen....

Der https://www.amazon.de/dp/B0CYT44ZYL funktioniert auch mit OpenWRT, keine Ahnung wie gut der durch die Decke kommen würde...

Nachtrag: Das Mesh bei TP-Link, Zyxel, Fritzbox ist ja eher Roaming + Einstellungsübernahme. Soetwas gibt es bei OpenWRT nicht. Roaming geht wunderbar und sehr schnell, aber es ist "deine" Aufgabe mehrere AP's entsprechend zu konfigurieren. Die Einrichtug als wLAN Extender geht auch, Schwierigkeiten macht als Extender/Bridge allerdings die gleichzeitige Nutzung des 2.4 und 5Ghz Bandes.... Das geht ohne weitere Dienste (batman-adv) nicht wirklich zufriendenstellend. Es gibt dann noch WDS und 802.11s als "richtiges" Mesh.

Gruß

Einen managebaren Switch beschaffen. Dort ein LAN (VLAN 1) und GAST (VLAN x) anlegen (oder eventuell weitere). OpnSense und alle APs (wichtig: VLAN-fähig) werden auf Trunk-Ports geschaltet, die Endgeräte je nach Vertrauensstellung auf VLAN 1 oder x.

Ich empfehle, wenn es KEIN Rack-Switch werden soll, den Zyxel XGS 1250-10. 8 1G Ports, 3 10G Ports und ein SFP+. Auf dem Switch lässt sich hervorragend OpenWRT installieren. (Du brauchst leider einmalig ein UART 3.3V Kabel) Dazu dann z.B. ein oder mehrere Zyxel NWA50pro (auf dem lässt sich auch OpenWRT installieren) So hast Du für die Netzwerktechnik eine Oberfläche die sich z.B. auch mit opensoho managen lässt.

Bei Mir macht die Fritzbox ebenso noch Telefonie, alles andere nicht mehr.

Auf den APs werden pro VLAN jeweils SSIDs angelegt mit unterschiedlichen Passworten. Somit kann man bei

WLAN-Clients durch Auswahl der SSID bestimmen, was sie dürfen.

Und Du kannst z.B. auch für IoT Geräte nur ein 2.4Ghz Wlan aufspannen, Client Seperation nutzen oder andere Verschlüsselungseinstellungen....


ich würde statt Kea allerdings dnsmasq empfelen. Durch die DNS Integration erspart man sich einiges an Konfigurationsaufwand. Auch ipv6 ist problemlos möglich.

Netzwerk-Clients, bei denen der Switch das zugewiesene VLAN ausgangsseitig entfernt und eingangsseitig hinzufügt (sogenannter "Tagged"-Port).

Das ist allerdings ein untagged Port. Dieser ist bei einem vLAN-fähigen Switch trotzdem einem vLAN zugehörig.
Ein Tagged Port ist eine andere Bezeichnung für einen Trunk-Port. Das ist Herstellerabhängig wie der genannt wird.
Ein TrunkPort ist ein Tagged-Port der ein oder mehrere vLANs enthält.

Wie Du deine Endgeräte (dazu gehört die Opnsense letztendlich auch) konfigurierst, hängt davon ab wie der Port auf dem Switch konfiguriert ist. Ein kurzes Beispiel. Wenn der Port auf dem Switch untagged ist, kannst Du das mit dem Port verbundene Interface der Opnsense ganz normal wie sonst auch konfigurieren. Du musst auf dem jeweiligen Endgerät nichts beachten.

Ein mit EINEM vLAN getaggter Port  auf dem Switch führt dazu dass Du auf dem Endgerät das eine vLAN konfigurieren musst. Das geht in der Opnsense, aber auch unter Linux und Windows. Macht man in der Regel so nicht, findet sich aber manchmal bei VOIP-Telefonen, dass ein einzelnes vLAN für die Netzkonfiguration vorrausgesetzt wird.

Ein Trunkport ist für alle vLANs konfiguriert, die an diesem Port ankommen und aus diesem Port ausgehend raus gehen sollen. Das wird z.B. genutzt um einem AP mehrere vLANs für mehrere SSID's bereitzustellen. Du kannst aber auch alle vLANs (die Du konfigurierst) mittels eines Trunkports an die Opnsense (oder auch ein Windows, Linux etc Device) übergeben. Dazu musst Du dann auf dem Interface der Opnsense, welches physikalisch mit dem Trunkport verbunden ist, logische vLAN-Interfaces erstellen.

Hier finde ich das auch sehr gut erklärt: https://www.thomas-krenn.com/de/wiki/VLAN_Grundlagen

It's a bit late, I solved this using the SNI map and a default entry. OpnSense 26.1

Nginx > Data Streamx > SNI Based Routing

default > my openvpn Server

[ein]

private Netzwerke blockieren und bong Netzwerke blockieren bei pppoe0

Ja

Modem vlan01

Wenn Du auf der Opnsense ein Vlan angelegt hast > deaktivieren
Wenn Du auf der Opnsense kein Vlan angelegt hast > aktivieren und Vlan id auf 7 setzen
Bzw. Wenn das Internet schon läuft nicht ändern;-)

Welches Netz haben denn die OpenVPN Clients und wohin wird das geroutet? Zum OpenVPN-Server? Welche IP hat der? Was für ein Netz ist 192.168.1.x und wohin wird das geroutet. Ist das Netz 10.130.0.0/20 euer internes Netz für Clients und Server? Welche IP haben die Mailserver?

Nimm gerne andere IP Adressen als eure orginalen, aber um Tipps geben zu können müssen die IP-Adressen zumindest die Struktur abbilden

edit: TAP-Device, also "enden" die Clients direkt im am OpenVPN-Server angeschlossenen Netz. Was für IP's bekommen dann die Clients? Was meinst Du mit virtuelle?

Korrekt. Ganz safe wären 1488.

Nein, das ist eben nicht notwendig,zumindest nicht in Deutschland. 1492 ist safe . Für dein Gutes HowTo, welches nicht nur für D. gilt mag das allerdings anders sein.

sonst die virtio-Karte auch auf 1500 Bytes plus VLAN beschränkt ist, nämlich als Antwort hierauf:

Was vollkommen ok ist. Auch aus einer virtuellen Maschine funktioniert damit PPPoE und die Anmeldung über ein dsl Modem.... Wichtig ist, dass das PPPoE Interface eine MTU von 1492 hat.

Wenn wir schon spitzfindig werden:

stimmt das spätestens nicht mehr, wenn man dann QinQ macht, das ist nämlich NICHT einkalkuliert.

Klar, es kann funktionieren, weil manche moderne Netzwerkhardware sogar Frames bis 9014 Bytes unterstützt, ich habe das aber im Guide so beschrieben, dass es IMMER funktioniert (gesetzt den Fall, dass Mini-Jumbo-Frames auf der ISP-Strecke auch gehen).

Das macht überhaupt nichts, die meiste Netzwerkhardware ist durchaus in der Lage neue Header  mitaufzunehmen und die Framegröße entsprechend anzupassen. Ja, nicht alle aber selbst alte Switche können das. Qinq ist da keine Ausnahme.

Ein Jumboframe ist der Payload. Die Header werden, soweit ich weiß nicht mitgezählt. Selbst wenn Du 28 vLAN Header hinzufügen würdest, so lange die MTU 1500 beträgt ist es technisch kein Jumboframe

Ich verstehe deine Intention, dass ist für dein HowTo durchaus sinnvoll, aber ist inzwischen eher anders herum. Die meiste Hardware unterstützt dass, nur wenige Komponenten können das nicht.

Ja, ich weiß. :-) Ich habe es aber (das war auch lange vor vlans) auch mal mit den jeweiligen OSI Headern und dem dazugeghörigen Payload gelernt... Da weiß ich manchmal nicht wie ich das nennen soll...

Zumindest MPLS wird auch draußen dran gehängt und wird eigentlich auf den Endpunkten so konfiguriert, dass die MTU auch wieder 1500 betragen kann

Genau, natürlich gibt es eine Maximalgröße des gesamten Pakets. Diese ist bei der Verwendung von vLAN aber normalerweise um den vLAN-Header ergänzt (dann 1518) damit der Payload weiterhin 1500 Byte groß sein kann. Das gilt dann auch noch nicht als Jumboframe.... Und, ja. stimmt. MTU ungleich Payload.... :-)

Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.

Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)

Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.

Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)

Ja, aber, die einzige Situation, wo das typischerweise relevant ist, ist im DNS Fall, wenn es für einen Namen Einträge für all diese Adresstypen gibt.

Es ist doch insgesamt relevant wenn mit ULAs gearbeitet wird? Wenn ein interner Dienst (DNS, sonst irgendeiner) eine ULA und eine IPv4 hat, wird der IP-Stack des anfragenden Clients beim Neuaufbau der Verbindung den Aufbau über IPv4 bevorzugen.
Für ausgehende Verbindungen in das Internet. Der Client wird bei AAAA und A Records die IPv4 des Zielsystems benutzen. Wenn jetzt der Server im Internet nur einen AAAA Record hat, wird der Client mit seiner ULA bis zum DefaultGateway kommen....

Wenn intern Wenn man also mit ULA's arbeitet um das Problem mit dynamischen Prefixen zu umgehen, muss man halt entsprechend aufpassen. Andersherum kann man aber von der externen öffentlichen IPv6 auf die interne ULA NAT machen. Der IP-Stack wechselt die IP Variante nicht.

https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/

Ich bin mir dessen durchaus bewusst. Beruflich verzichte ich auf ULA's und setze auf einen festen Ipv6 Prefix. Wenn ich aber privat Dienste freigeben möchte (DynDNS) und auch IPv6 filtern möchte, habe ich kaum eine andere Chance. Dynamische Prefixe sind mindestens genauso großer Mist wie ULAs. Ein fester IPv6 Prefix ist mir privat dann zu teuer....

ULAs werden normalerweise nicht wegen der Angabe des DNS-Servers, sondern in dem Bestreben genutzt, bei dynamischen IPv6 Präfixen und gewünschtem weitgehenden Verzicht auf (legacy) IPv4 eine DNS-Eintragung vornehmen zu können - weil das mit den (dynamischen) GUAs eben nicht geht. Meine Bemerkung wies lediglich darauf hin, dass genau das bei Dual-Stack trotzdem nicht funktioniert, weil IPv6 ULAs bei gleichzeitiger Verfügbarkeit von IPv4 für DNS-Einträge aufgrund der geringeren Priorisierung gar nicht genutzt werden (viele denken, IPv6 würde "immer" vorgezogen - dem ist nicht so).

Genau aus dem Grund benutze ich ULA auch und hatte schon ein paar Merkwürdigkeiten mit IPv4 und den ULA,s die sich jetzt erklären

Mal ganz abgesehen davon, dass der DNS-Server genauso gut per IPv4 genutzt / adressiert werden könnte - aber falls sowohl IPv4 als auch IPv6 angegeben werden, ist die Frage, welcher Server dann genutzt wird, undefiniert. All das gilt für Dual-Stack.

Undefiniert ist das nicht, sondern beruht auf der Prio des jeweiligen Stacks des Betriebssystems. Es wird ipv6 bevorzugt.

Da gehts aber nur um die DNS Auflösung, wenn ein Name IPv6 GUA, IPV4 und IPv6 ULA hat, dann wird der Name in der Priorität aufgelöst bzw. vom Client in der Priorität benutzt.
Ist aber für DNS Infrastruktur kein Problem, DNS Server werden dem Client per IP mitgeteilt, dementsprechend ist IPv6 ULA zumindest dafür eine valide Lösung.

Ich will ja garnicht unbedingt klugscheißern, aber Nö. Wie meyergru auch schon schrieb, geht es um die grundsätzliche Priorisierung der Nutzung der entrsprechenden IP-Adresse durch den Netzwerkstack. IPv6 > IPv4 > IPv6 ULA. Das wirkt sich dann natürlich auf die Nutzung der vom DNS-Server zurückgelieferten IP aus.Diese wird vom Stack dann in der Priorität genutzt. Das gilt, wenn der Client sowohl ULA, GUA und IPv4 hat,auch für die IP-Adresse des DNS-Servers und damit für die Namensauflösung.
Der DNS-Infrastruktur ist das egal, ja.