Best Practice für IPv6, DNS und Webserver (nginx)

Hi,
ich möchte auf meinem Virtual Dedicated Server IPv6 für alle Dienste implementieren und komme nun an einen Punkt wo ich mir nicht ganz sicher bin welcher der beste oder gängigste Weg ist seinen DNS und Webserver (nginx) für einen Dienst zu konfigurieren.

Ich habe mein Szenario mal skiziert (siehe Anhang).
- Proxmox host als Hypervisor.
- VM100 als LXC Container mit Debian 11, nginx als Webserver bzw. Reverse Proxy.
- VM101 als LXC Container mit Debian 11 und exemplarisch ein beliebiger Dienst, mit Dashboard und einen Dienstport.
- Eine öffentliche IPv4 Adresse am Proxmox Host und ein öffentliches /64er IPv6 Netz, welches an allen Maschinen liegt.

Nehmen wir an ich möchte den Dienst unter der Domain service.example.com in VM101 bereitstellen. Dieser Dienst hat ein Dashboard, welches unter Port 80 erreichbar ist und einen Dienstport, welcher unter Port 9000 erreichbar ist. Um welchen Dienst es sich handelt spielt hier keine Rolle.

Da VM101 in der Realiät nur eine von vielen ist und ich mich nicht für jeden Dienst, welchen ich bereitstelle, um ein Zertifikat kümmern will, verwende ich VM100 als Reverse Proxy, welcher ein Wildcard Zertifikat von Lets Encrypt hält und für alle Webdienste die zentrale Zertifikatsverwaltung übernimmt.

Die IPv4 Lösung:
Ganz klassisch wird hier eine IPv4 http Anfrage (1) auf service.example.com per DNS auf die öffentliche IP 200.2.3.4 gelenkt, welche dort auf die interne IPv4 übersetzt wird (NAT44) und anschließend per Port-Forwarding auf den nginx reverse proxy gelenkt wird. Hier leitet der nginx die Anfrage von 80 auf 443 um, verarbeitet Zertifikate und schickt die Anfrage letztendlich weiter (Upstream) an den die VM101, welche letztlich den Webdienst bereitstellt.
Für eine IPv4 Anfrage auf den Dienstport 9000 (2) funktioniert das ganze analog, nur ohne den Umweg über VM100, sondern per Port-Forwarding direkt an VM101. Keinerlei Probleme hier.

Die IPv6 Lösung:
Und hier sehe ich nun 5 Möglichkeiten das ganze zu realisieren:

1. Ich trage in den DNS beim AAAA-Eintrag die IP des Proxmox Hosts als Ziel ein (service1.example.com) und übersetze die IPv6 anschließend zu einer IPv4 (NAT64). Der Rest geschieht dann Analog wie bei IPv4. HTTP Anfragen gehen per Port-Forwarding an VM100, Dienstport Anfragen direkt an VM101. Nachteil: NAT64 -> möchte man bei IPv6 ja tunlichst vermeiden. Ist auch nicht mein Favorisierter Weg.

2. Genau wie bei 1. nur mit NAT66 (und evtl. ULA Adressen?!), den Rest analog zu 1. (wurde nicht eingezeichnet). Würde das einen Unterschied machen? Nachteil: wieder NAT. Also nein.

3. DNS AAAA-Eintrag zeigt auf VM100 (service2.example.com). Eine IPv6 http Anfrage wird ohne Übersetzung direkt an die öffentliche IPv6 Adresse von VM100 geleitet/geroutet. Der nginx verarbeitet die Anfrage wie gehabt und leitet sie an VM101 weiter. Das Problem ist nun, dass Anfragen an den Dienstport ebenfalls an VM100 ankommen und nicht wie bei reinem IPv4 per Port-Forwarding vorher vom Host abgefangen und direkt an VM101 geleitet werden. Hier muss also der nginx auch als Load-Balancer eingerichtet werden und auf Port 9000 hören, sowie auf jeden weiteren Port den irgend eine andere VM benötigt. Ist das so korrekt? Stößt man hier auf Probleme, da die Ziel-IPv6-Adresse der Anfrage vom Client und Quell-IPv6-Adresse der Antwort nicht die selbe ist? Oder ist sie es? Wie verarbeitet nginx hier den Stream eigentlich?

4. DNS AAAA-Eintrag zeigt auf VM101 (service3.example.com). Sowohl http als auch Dienstport Anfragen kommen direkt an der VM101 an. Für den Dienstport ist nun alles klar. Für http gibt es wieder 2 Möglichkeiten. VM101 kümmert sich nun selbst um Zertifikate, was ich ja vermeiden möchte oder Ich leite http Anfragen an VM100 um, welche sie dann wieder zurück (aber nun verschlüsselt) an VM101 leitet. Aber wie dann genau? Port-Forwarding an VM101? oder dort auch einen nginx aufsetzen? Wäre für mich nun irgendwie eine schlechtere Lösung als bei 3., da ein Hop mehr.

5. Ich richte für das Dashboard und für den Dienstport unterschiedliche AAAA-Einträge im DNS ein (service2 und service3.example.com). Gefällt mir aber ehrlicherweise nicht und ich weis auch nicht ob diese Lösung wirklich überall funktionieren würde. Ich könnte mir vorstellen, das bei einigen Diensten der Konfigurationsaufwand sehr groß sein könnte mehrere DNS Namen für den gleichen Dienst zu benutzen.

Gibt es noch eine Möglichkeit oder Lösung, die ich hier vergessen oder übersehen habe?

Ich bin sehr gespannt ob sich überhaupt wer das ganze durchliest und mir dazu seine Meinung sagen kann.