Messages

[Andere]

Andere Lösungen heißt zumindest bei mir: zusätzliche Lösungen. Ich habe kein Problem damit, die Mechanismen von IPv4 auf IPv6 umzustellen, wenn das aber bedeutet, für alle möglichen Features zusätzliche Mechanismen oder spezifische Geräte-Konfigurationen (Umstellung von DHCP-Verhalten am Server, Registry-Edits auf Windows-Clients, Umstellungen an Android und/oder IOS-Geräten, separate IPv4- / IPv6-Netze) einsetzen zu müssen, bin ich aus Aufwandsgründen raus - für mich persönlich besteht der Ansatz dann den Lackmustest nicht.

Das mag in Business-Umgebungen anders sein, wo AD, LDAP, Windows-Domänen, 802.1x oder IPAM sowieso schon am Start sind. Bei mir ist das mit "IPv4 im LAN" und "IPv6 outbound only" aber anders: Da brauche ich - und zwar nur auf der OpnSense - eine einfache Zuordnung MAC -> IPv4 -> DNS-Einträg(e) und kann damit alles erschlagen.

Es wäre wahrscheinlich auch anders, wenn sich die ISPs nicht auf diese blöde dynamische IPv6-Zuweisung eingeschossen hätten oder langfristiger, wenn IPv6-only eine echte Option darstellt.

@n3: Im RADVD (falls Du den nutzt) kannst Du die Option "Do not send any DNS configuration to clients" setzen - wie gesagt, ich nehme nur SLAAC, keinen DHCPv6. Damit kommt dann kein DNSv6-Server mehr an. So auch das oben verlinkte HOWTO. Das funktioniert - alles, was wir hier diskutieren, ist offenbar komplexer als man sich das so zuerst vorstellt. Mir fehlt bislang jedenfalls das HOWTO, das das lückenlos beschreibt.

Und: Die ULA wird bei DS-Betrieb nie verwendet, solange der Name auch auf eine IPv4 auflöst... das würde m.E. nur mit IPv6-only funktionieren, nicht mit IPv6 mostly. Solange Du dynamische IPv6-Präfixe und IPv4-only Clients hast, wird das nix.

@Patrick: Ich nutze weder Windows-Domänen noch DHCPv6. M.W. unterstützen Android-Clients (und manche andere) auch nur SLAAC für die IPv6-Zuweisung - ich weiß allerdings nicht, ob das aktuell immer noch so ist. D.h., aktuell arbeite ich mit einer festen Reservierung MAC -> IPv4. IPv6 wird eigentlich nur für Outbound genutzt, inbound nehme ich sowieso meist einen Reverse Proxy, deshalb brauche ich da die IPv6 selten.

Oha. Da kommt aber (theoretisch) viel Arbeit auf einen zu, wenn man dem internen DNS die IPv6 (und zwar aus den genannten pragmatischen Gründen ULAs) hinzufügen will:

a. Wie ich gerade feststelle, wird die IPv6 bei Windows aus einer (zufälligen) DUID abgeleitet. Das bedeutet, ich kann die ULA nicht einmal aus den vorhandenen MAC-Daten für die DHCPv4-Reservierungen ableiten. Es sei denn, ich ändere auf den Windows-Clients per Registry-Setting die Einstellungen so, dass die Ableitung aus der MAC erfolgt, so dass man zumindest die EUI-64 vorab zentral kennt. Das könnte im Extremfall bedeuten, dass ich die DNSv6-Einträge alle nochmal händisch erfassen muss, nachdem ich auf jedem Client die tatsächliche ULA ausgelesen habe. Keine Ahnung, wie Android das macht, aber IOS nimmt m.W. auch eine zufällige EUI-64, wenn man es nicht abschaltet (und das nicht nur für ausgehende Verbindungen mit privacy extensions).

b. Automatisiert kann man die Einträge sowieso nicht so einfach erzeugen, weil man für Nicht-IPv6-fähige Geräte und Services keine DNSv6-Einträge machen will - sonst würden die IPv6-only Clients auf Fehler laufen, weil sie ja dann bevorzugt IPv6 versuchen würden. Wobei: das gälte nur für GUAs, siehe nächster Punkt.

c. Bei ULAs ist es so, dass die ja überraschenderweise niedriger priorisiert werden als IPv4. Wenn also beide Einträge existieren, bringt das rein gar nichts, denn die IPv4 wird der ULA IPv6 immer vorgezogen. IPv4-only Clients nehmen sowieso nur IPv4, und solange diese noch existieren, werden die IPv4-DNS-Einträge auch noch gebraucht - es wäre nicht einmal eine Option, die Einträge exklusiv nur für IPv4 oder IPv6 zu machen.

d. Differenzieren müsste man für echte Services sowieso, denn wenn die per DHCP-Option 108 IPv6-only gesetzt werden, sind sie für IPv4-only Clients nicht mehr erreichbar. M.W. unterstützt Kea DHCP auf OpnSense eine Client-spezifische Steuerung der Option 108 nicht - solche Services müssten also statisch auf Dual-Stack konfiguriert werden.

Ergo: Alle Clients nutzen sowieso nur den IPv4-Teil des DNS-Eintrags. Dann kann ich mir die lokalen IPv6-Einträge im DNS also gleich sparen.

Offenbar wird das also nix bei mir mit "IPv6-mostly" - m.E. klappt das erst gut mit "IPv6 only".

Sorry für Off-Topic, aber wie gesagt, ich versuche nur gerade, das Big Picture zu erfassen (die klassische Version mit internem IPv4 kenne ich).

Das mit dem klassischen Dual-Stack sehe ich auch noch so wie Patrick.

Darüber hinaus haben meine Experimente mit der DHCP option 108 (RFC 8925) mit Kea zumindest bei Windows 11 (noch) nicht funktioniert. Der Client-PC holt sich immer (auch) eine IPv4.

Wenn das besser unterstützt würde, könnte man drüber nachdenken. Allerdings muss man dann im internen DNS beide Varianten (IPv4/6) pflegen, damit alle Clients die Services finden - also Mehraufwand.

Stimmt, ich meinte Stateless.

Wie geht denn "IPv6-only preferred"? Sowie ich DS habe, weil einige Clients es brauchen, muss ich doch zwangsläufig DHCPv4 machen und auch einen DNSv4 haben - das würde aber von allen Clients genutzt, oder? Die IPv4-only Clients können dann aber die IPv6-only Services / Geräte nicht nutzen, richtig?

Anders gesagt: Mal mal ein Bild, wie sich das genau zusammensetzt. Ich verstehe ja noch IPv6-only, wobei mich daran schon stört, dass ich:

a. Eine Bridge-Technologie für den externen IPv4-Zugang (z.B. github) brauche und
b. bei dynamischen IPv6-Präfixen zusätzlich noch ULAs für den internen Netzwerktraffic benötige (wobei die dann niedriger priorisiert sind als GUAs, ich also sehr aufpassen muss, dass NUR die ULAs im internen DNS auftauchen).

Did you follow the bridge documentation to the very end, including the tuneables? https://docs.opnsense.org/manual/how-tos/lan_bridge.html

If you did, you would end up with a single LAN interface that is configured as a bridge of igc1-3 with a single IPv4 range only. Anything else is probably a misconfiguration.

Ja, so ist es. Du zeigst in Deinen Screendumps ja gar nicht, welchen DNS-Server Du verwendest. Ruf mal "ipconfig /all" auf, dann sieht Du es.
Dort sollte, wenn es nur einen per DHCPv4 verteilten Server gibt, auch nur eine IPv4 dafür geben.

Patrick liegt richtig...

Zu 1:

Ich schrieb das, weil hier empfohlen wurde, den DNS-Server über SLAAC zu verteilen. Wie gesagt, das wirkt nicht immer, weil manche Clients das nicht übernehmen und DHCPv6 dazu benötigen.


Zu 2.

Ich kenne AdGuard nicht, aber theoretisch kann jeder DNS-Server (ob selbst per IPv6 oder IPv4 betrieben) sowohl IPv4 als auch IPv6 auflösen. Du musst hier streng unterscheiden zwischen dem Protokoll, mit dem Du den DNS-Server ansprichst und den Adressen, die er Dir zurückliefern kann.
Angeblich kann Adguard schon lange IPv6: https://adguard.com/en/blog/dns-ipv6-support.html

Wenn Du also per DHCPv4 bereits den Adguard-Server an die Clients annoncierst, wozu brauchst Du dann einen zweiten Server per IPv6? Vor allem: Wenn das unterschiedliche Server wären, ist undefiniert, welches Ergebnis ggf. genutzt würde.


Zusammengefasst:

Wenn man Dual Stack nutzt und somit sowieso (irgend) einen IPv4-DNS-Server per DHCPv4 anbietet, würde ich überhaupt keinen IPv6-DNS-Server verteilen, weder über SLAAC, noch über DHCPv6. Und dann braucht man auch weder DNSv6 noch DHCPv6, sondern nur SLAAC für IPv6, was garantiert mit jedem Client funktioniert, wenn er denn überhaupt IPv6 kann. So steht es auch im HOWTO.

Einen DNS-Server per IPv6 zu annoncieren, brächte nur etwas, wenn man IPv6-only hätte und dann bräuchte man eben den "Assisted" Mode für komplette Abdeckung. Inwieweit IPv6-only aber überhaupt Sinn macht, soll jeder selbst bewerten - ich halte nichts davon, weil man dann für IPv4-only Services im Internet (und davon gibt es reichlich, beispielsweise github.com) wieder irgendwelche IPv6-to-IPv4 Brückenlösungen benötigt.

Ich bin ein Fan von Ockhams Rasiermesser...

Did you try RSS?

Zwei Hinweise:

1. Nicht alle Geräte akzeptieren die Angabe des DNS-Servers per SLAAC, manche brauchen DHCPv6 dazu. Das ist der Grund, weshalb der RA-Mode "Assisted" existiert - dabei wird die IPv6 per SLAAC und nur der DNS-Server per DHCPv6 übergeben.

2. Eigentlich braucht es bei Dual-Stack den IPv6-DNS-Server nicht - es ist sogar eher schädlich, denn jeder DNS-Server kann auch IPv6 auflösen (also reicht der IPv4-Server) und welcher priorisiert wird, falls beide angegeben wurden, ist nicht definiert.

Ergo: In meinem Guide empfehle ich deshalb, gar keinen DNS-Server per IPv6 zu verteilen, also RA-Mode "Unmanaged" (oder wie auch immer das beim verwendeten RA-Daemon heißt) siehe: https://forum.opnsense.org/index.php?topic=45822.0, Note 6.

1. Did you specify "force" in the option?
2. Did you wait for the client to renew its lease?

If at all, why not create a setting that is stored in config.xml and can be switched between bash, sh, tcsh and others?

und der richtige LAN-Port verwendet wird

;-)

Ziemlich sicher nicht, sonst wären die Interface-Namen bei virtio  anders (vtnetX). Und wenn es passthru wäre, würde der Ansatz nicht funktionieren.

Einen Packet-Trace kann man mit "tcpdump -i pppoe0 -X" ja auch auf der OpnSense mitlaufen lassen. Wird ja nicht soviel kommen, wie das PPPoE-Protokoll zeigt.

Ja, die bekommen bei gleichem Typ die selben Bezeichnungen.