Für die Bereitstellung von öffentlichen IPv6-Adressen in nicht-IPv6-Netzwerken und zur Absicherung meiner Kommunikation in fremden Netzwerken betreibe ich ein eigenes kleines, Wireguard-basiertes VPNWährend des Testbetriebs stellte sich heraus, dass ich zwar mit IPv6-Zieladressen im Internet ohne Probleme kommunizieren konnte - doch die Kommunikation zu IPv6-Ressourcen, die innerhalb meiner eigener Infrastruktur liegen, schlug fehl. Genauer: TCP-basierte Kommunikation schlug fehl. Nach etwas Debugging mittels tcpdump und einer Skizze meiner Infrastruktur war die Ursache schnell klar:
Ohne es gleich zu bemerken, wurden TCP-Anfragen an meine eigenen Services anders geroutet als die dazugehörigen Antworten. Im Folgenden will ich das Problem und mögliche Lösungen erklären.
Eines vorweg: Das Problem ist ein relativ spezifisches und tritt u.U. nur dann auf, wenn VPN-Server und angesprochener Service (in meinem Fall Nextcloud) im selben Netz-Segment betrieben werden.
In meinem Beitrag “Dezentrales HA Servercluster-VPN mit PeerVPN” habe ich euch PeerVPN vorgestellt - einen kleinen Peer-to-Peer VPN-Server, der sich wunderbar eignet, um seine Hosts miteinander zu vernetzen. Ich betreibe selbst mehrere Server an verschiedenen Standorten, die direkt miteinander Daten austauschen. So kommuniziert beispielsweise jeder Host mit einem zentralen Munin-Server, um Statusupdates zu senden. Auch Icinga-Daemons laufen auf den Hosts und prüfen verschiedene lokale Dienste. Das Ergebnis wird an das Icinga-Backend geschickt.
All diese Kommunikation soll für die Öffentlichkeit nicht einsehbar sein, d.h.:
- Die Existenz von Wartungs- und Verwaltungsdiensten soll verborgen werden
- Die Verbindung soll verschlüsselt werden: Internet und Hoster kann im Zweifel nicht getraut werden
- Nur autorisierte Personen oder Maschinen sollen Zugriff auf bestimmte Dienste haben (z.B. Admin, Munin-Frontend)