1- # Theorie (Namen werden noch überarbeitet)
2-
3- ## Anwendungsbereiche für Teilempfehlungenen
4-
5- ### IPv6 Adresse für jeden Service einzeln
6- Wenn man jeden Nginx reverse Proxy mit einer separaten Adresse (in unserem Fall IPv6, da wir kein IPv4 Netz besitzen)
7- versorgt, so kann man direkt auf OSI Layer 3 nachvollziehen auf welchem Service die Request kam. Wenn man für alle
8- Services nur eine IP-Adresse verwenden würde, so könnte man frühestens auf Layer 5 (TLS/SNI) nachvollziehen auf welcher
9- Applikation die Request kam. Alternativ auch auf Layer 7, aber dies sollte nicht der Anspruch sein und wäre auch zu viel
10- Aufwand alle Application Logs nach einer IP-Adresse zu durchsuchen.
11-
12- ### Wofür benötigt man einen IPv4 -> IPv6 Proxy?
13- #### Use Case 1 - Virtualisierung mit nur einer IPv4 Adresse
14- Wenn man sich jetzt vorstellt, dass man einen Server hat, welcher zwei virtuelle Maschinen betreibt auf denen jeweils
15- zwei Webserver laufen, so muss man sich fragen wie man damit umgeht.
16-
17- 1 . Entscheiden für einen Webserver
18- 2 . Aufsetzen eines zentralen reverse Proxies
19- 3 . IPv4 -> IPv6 Proxy
20-
21- === "Für einen Webserver entscheiden"
22- - Keine Option, da man beide Webserver verwenden will
23-
24- === "Aufsetzen eines zentralen reverse Proxies"
25- - Pro:
26- - Beide VMs können exposed werden
27- - Zentralisierter Aufruf auf einen reverse Proxy
28- - Contra:
29- - langsamere Laufzeit durch mehre Proxys (Die Proxys auf den VMs brauchen man ja dennoch)
30- - SPOF (Single point of failure) - Wenn der erste reverse Proxy nicht mehr funktioniert, kann auf kein Service mehr zugegriffen werden
31- - Vermehrter Debugging Aufwand durch mehrere Verbindungsstellen
32- - Aufwendigere Konfiguration (spezifische Header Einstellungen (Real-IP Forwarded-For))
33-
34- === "IPv4 -> IPv6 Proxy"
35- - Pro:
36- - Für IPv6 geringere Laufzeit (veraltetes IPv4 Protokoll)
37- - Reverse Proxies der VMs sind direkt im Internet
38- - dadurch keine Header Konfiguration nötig
39- - Falls der zentrale IPv4 Proxy nicht mehr funktioniert, so ist der Service immer noch über IPv6 erreichbar
40- - Contra:
41- - Uns keine bekannt, falls euch welche einfallen, bitten wir um einen Pull Request
42-
43-
44- #### Use Case 2 - IPv6 only Server
45- Man stelle sich vor, dass man ganz viele Server hat. Um Kosten zu sparen gibt man jedem Server nur ein IPv6 Netz
46- und keine IPv4 Adresse. So braucht man nur einen zentralen IPv4->IPv6 Proxy um die Erreichbarkeit der Server über IPv4
47- sicher zu stellen.
48-
1+ # Theoretische Grundlagen
2+
3+ ## Wahl des Reverse Proxies
4+ Im Rahmen dieses Guides werden nginx auf dem Host sowie Traefik als Container vorgestellt.
5+
6+ Nginx ist ein leistungsstarker und weit verbreiteter Webserver und Reverse Proxy, der sich
7+ durch hohe Stabilität, Effizienz und Flexibilität in klassischen Serverumgebungen auszeichnet.
8+
9+ Traefik hingegen ist speziell auf containerisierte Umgebungen ausgelegt und integriert sich
10+ nahtlos mit Plattformen wie Docker oder Kubernetes. Es erkennt neue Services automatisch und
11+ konfiguriert Routing-Regeln dynamisch, was es besonders für moderne, dynamische Deployments
12+ attraktiv macht.
13+
14+ ## Eine IPv6 Adresse pro Service
15+
16+ !!! note
17+ Die meisten Hosting-Provider weisen jedem Server ein /64-IPv6-Präfix zu,
18+ was einem Adressraum von $2^{64}$ Adressen entspricht – eine Zahl, die in
19+ der Praxis quasi unerschöpflich ist.
20+
21+ Ausnahmen gibt es beispielsweise bei Strato, siehe dieses
22+ [Video](https://www.youtube.com/shorts/oSvU4HXZ_Wc).
23+
24+ Wird jedem nginx Reverse Proxy eine eigene IPv6-Adresse zugewiesen, kann bereits auf OSI-Layer 3
25+ nachvollzogen werden, an welchen Webservice eine Anfrage gerichtet war. Würde hingegen für alle
26+ Dienste nur eine gemeinsame Adresse verwendet, wäre eine eindeutige Zuordnung frühestens auf
27+ Layer 5 (durch Auswertung des TLS SNI Headers) möglich; ohne ein spezielles Analysewerkzeug sogar
28+ erst auf Layer 7, etwa über die Logdaten des Webservers.
29+
30+ Der Webserver nginx bietet mit der Direktive ` listen ` die Möglichkeit, virtuelle Hosts an spezifische
31+ IPv4- oder IPv6-Adressen zu binden. Diese Technik erlaubt eine frühzeitige Trennung und Zuordnung des
32+ eingehenden Traffics zu den einzelnen Anwendungen. Soll ein Dienst abgeschaltet oder vorübergehend
33+ blockiert werden, kann dessen zugewiesene Adresse zudem sehr einfach über die Firewall – oder sogar
34+ direkt beim Provider – gesperrt werden, ohne dass Änderungen an der Servicekonfiguration selbst
35+ erforderlich sind.
36+
37+ ## Sonderfälle
38+ ### Virtualisierungsserver
39+ Zwar richtet sich dieser Guide in erster Linie an Administratoren einfacher vServer, doch kann es
40+ schnell vorkommen, dass aufgrund steigender Leistungsanforderungen auf einen dedizierten Server
41+ gewechselt wird.
42+
43+ Nehmen wir an, ein solcher Server verfügt über eine IPv4-Adresse und ein /64-IPv6-Präfix, auf dem
44+ mehrere virtuelle Maschinen betrieben werden sollen. Das Hostsystem, das direkt auf der physischen
45+ Hardware installiert ist, kann in diesem Szenario als Router fungieren. Über NAT und Port Address
46+ Translation (PAT) lassen sich dabei gezielt einzelne Ports an die virtualisierten Systeme weiterleiten.
47+
48+ Dank des zugewiesenen IPv6-Präfixes kann jedoch jeder virtuellen Maschine eine eigene öffentliche
49+ IPv6-Adresse zugeordnet werden, wodurch sie direkt aus dem Internet erreichbar ist – ganz ohne NAT.
50+
51+ In diesem Zusammenhang kann der Einsatz eines IPv4-zu-IPv6-Proxys sinnvoll sein. Ein solcher Proxy
52+ nimmt Anfragen über IPv4 entgegen und leitet sie intern per IPv6 an den Zielserver weiter. Auf diese
53+ Weise bleibt die Erreichbarkeit auch für IPv4-Clients gewährleistet, selbst wenn die eigentliche
54+ Infrastruktur ausschließlich auf IPv6 basiert.
55+
56+ ### IPv6-only Server
57+ Angenommen, es steht eine größere Anzahl von Servern zur Verfügung. Um Kosten und Verwaltungsaufwand
58+ zu reduzieren, wird dabei bewusst auf individuelle IPv4-Adressen verzichtet und jedem System ausschließlich
59+ ein IPv6-Netz zugewiesen.
60+
61+ !!! warning
62+ Dieses Setup impliziert, dass die Systeme selbst keine ausgehende IPv4-Verbindung aufbauen können.
63+ Das kann die Administration erschweren – beispielsweise, wenn Repositories von GitHub, Docker Hub oder
64+ anderen ausschließlich über IPv4 erreichbaren Diensten bezogen werden sollen. In solchen Fällen ist
65+ entweder ein IPv6-fähiger Mirror oder ein NAT64-Gateway erforderlich, um den Zugriff zu ermöglichen.
66+
67+ Die wenigsten Anbieter stellen derzeit NAT64 Gateways zur Verfügung, weshalb zum derzeitigen Zeitpunkt
68+ von dieser Systemarchitektur abzuraten ist.
69+
70+ Die Erreichbarkeit dieser Server aus dem IPv4-Internet kann in einem solchen Szenario über einen zentralen
71+ IPv4-zu-IPv6-Proxy sichergestellt werden. Dieser Proxy fungiert als gemeinsame Eingangsstelle für alle
72+ IPv4-Anfragen und leitet sie intern über IPv6 an die jeweiligen Zielsysteme weiter – effizient, kostensparend
73+ und ohne die Notwendigkeit zusätzlicher IPv4-Ressourcen.
4974
5075### IPv4-to-IPv6 Proxy
51- Dieser einfache IPv4-to-IPv6 Proxy unterstützt in seiner ersten Version lediglich HTTP Verbindungen auf Port 80 und TLS
52- Verbindungen auf Port 443. Eine Anpassung dieser Konfiguration um einige anderen Protokolle (SMTPs, IMAPs, POP3s) welche
53- TLS verwenden zu unterstützten ist denkbar.
54-
55- Aus Gründen der Vollständigkeit hier einmal die Nginx Konfiguration für den Proxy für Alpine Linux. Die Einrichtung ist
56- denkbar einfach: nginx installieren, die untenstehende Konfiguration kopieren und den Proxy starten:
76+ Im folgenden wird eine einfache nginx Konfiguration vorgestellt, welche als IPv4-to-IPv6 Proxy eingesetzt
77+ werden kann. In seiner aktuellen Version unterstützt er ausschließlich HTTP- und HTTPs-Verbindungen. Mit
78+ geringfügigen Anpassungen der Konfiguration lässt sich der Proxy jedoch auch für andere TLS-gesicherte
79+ Protokolle wie SMTPs, IMAPs oder POP3s einsetzen.
5780
5881``` nginx
5982user nginx;
@@ -62,7 +85,6 @@ worker_processes auto;
6285error_log /var/log/nginx/error.log notice;
6386pid /var/run/nginx.pid;
6487
65-
6688events {
6789 worker_connections 1024;
6890}
@@ -88,7 +110,6 @@ http {
88110}
89111
90112stream {
91- # https://gist.github.com/kekru/c09dbab5e78bf76402966b13fa72b9d2#non-terminating-tls-pass-through
92113 server {
93114 listen 443;
94115
@@ -102,20 +123,3 @@ stream {
102123 }
103124}
104125```
105-
106- ### Vergleich der Proxy Möglichkeiten
107-
108- ![ Schaubild] ( ../img/schaubild_cloudflare-vs-transparent-proxy.png ) {: loading=lazy }
109-
110- Aus unserer Sicht ergibt die Verwendung eines eigenen vorgeschalteten Proxies nur Sinn, wenn mehr als ein Server
111- administriert wird und die Web-Server über IPv6 Adressen nach außen bereitstellt werden.
112-
113- Wird lediglich ein System betreut (wie z.B. der oben erwähnte Cloudserver), kann die zugewiesene IPv4 Adresse natürlich
114- ebenfalls auf den Ports 80 und 443 verwendet werden und dann auf den Reverse Proxy zeigen. Dadurch entfällt die
115- Abhängigkeit zu anderen Systemen.
116-
117- Sofern der Cloudserver über keine eigene IPv4 Adresse oder keine eigenen IPv6 Adressen verfügt, sollte ein Proxy
118- vorgeschaltet werden, um den Nutzern, die keine IPv4/IPv6 Adresse verfügen, den Zugriff zu ermöglichen.
119-
120-
121- ## Vergleich nginx / traefik
0 commit comments