Ein IPv6 Homeserver via OPNsense

Ein IPv6 Homeserver via OPNsense

Eigentlich ist es zu verlockend: Neben einer einzigen IPv4-Adresse weist mir mein Internetprovider auch gleich noch eine IPv6-Adresse zu. Doch halt: Ist das wirklich nur eine einzelne IP-Adresse? Eben nicht, man bekommt einen Netzwerkblock zugewiesen. Ich könnte also jedem einzelnen Rechner, sogar jedem einzelnen Dienst in meinem Heimnetzwerk eine eigene IPv6-Adresse zuweisen. Das eröffnet ungeahnte Möglichkeiten - Es ist Zeit das mal auszuprobieren!

In meiner Umgebung steht eine OPNsense Firewall welche sich ums Internet kümmert. Mein Testserver, welcher von extern erreichbar sein soll, ist ein Ubuntu basiertes System welches sich bei mir in einem Netzwerk mit dem Namen PREP befindet. Der Name ist eigentlich egal, für dieses Beispiel sinniger wäre vermutlich der Begriff DMZ. Als Internetanschluss besitze ich Glasfaser (FTTH), das Prinzip hier gilt jedoch sinngemäß genauso für ADSL. Sogar für statische IP-Adressen ist dieses Beispiel sinngemäß anzuwenden.

Noch eine kurze Anmerkung: Unter IPv6 ist das fehleranfällige NAT für solche Aufgaben unerwünscht. Jeder sollte genügend IPv6 Adressen erhalten, um alle internen Systeme via IPv6 erreichbar zu machen - sofern man möchte. Da man genügend öffentliche IP-Adresse hat, ist kein NAT notwendig.

OPNsense

Meine OPNsense ist via Dualstack am Internet verbunden, d.h. ich habe neben meiner IPv4 noch eine IPv6 Adresse mit einem /56er Präfix anliegen. Obwohl ich Glasfaser habe, ist es vom Verfahren her so wie hier in der Dokumentation von OPNsense beschrieben für DSL. Das macht keinen Unterschied. Hier der Link zur Doku: https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html. Schreibe mir einen Kommentar oder eine Nachricht, falls hierzu weitere Details erwünscht sind.

 

Meine IPv4 Adresse für dieses Netzwerk ist manuell gesetzt. Für IPv6 ist Track Interface eingetragen. Das zu verfolgende Interface ist WAN, als Prefix-ID verwende ich df (223 dezimal = df hexadezimal).

Sollte ich von meinem Internetprovider als Prefix 2001:0db8:1234:5600/56 erhalten, so beginnen alle IPv6 Adressen in meinem PREP Netzwerk mit dem Prefix 2001:0db8:1234:56df/64. Die letzten zwei Stellen, welche bisher als 00 dargestellt waren, werden durch die gesetzte Prefix-ID ersetzt. Hierbei handelt es sich um zwei hexadezimale Ziffern mit je 4 Bit. Eine hexadezimale Ziffer kennt 16 verschiedene Möglichkeiten von 0 bis f. Das sind 2⁴ = 16 Möglichkeiten. Zwei hexadezimale Ziffern sind somit 8 Bit. Mein Prefix wird also von /56 zu /64 "verlängert". Das ist auch genauso gewollt, dass man mehrere Netze mit IPv6 Adressen bestücken kann - deswegen bekomme ich von meinem Provider ein /56er Prefix.

OPNsense Track Interface
Linux ip -6 a

Linux

Als Linux verwende ich ein Ubuntu basiertes System. Letztendlich ist egal welches Linux zum Einsatz kommt. Die gezeigten Verfahren sollten bei den gängigsten Distributionen sinngemäß übertragbar sein.

Wie im Screenshot gezeigt, hat mein Ubuntu als IPv6-Adresse unter anderem die 2a00:79c0:72b:2edf::2000/128 erhalten. Das ist ein Beispiel einer Adresse, welche tatsächlich bei mir mal vergeben war. Allerdings nur bis zum nächsten Tag, da wählt sich mein System neu ein und bekommt eine andere IP-Adresse. Zusammengefasst: Diese Adresse ist gültig, allerdings wird dort sicherlich kein System mehr erreichbar sein 😉

Diese IP täte bereits reichen und kann entsprechend verwendet werden. Das Linux-System bekommt bei jedem Neustart erneut diese Adresse zugewiesen. Der Trick ist ziemlich einfach: Unter OPNsense die Seite Services/ISC DHCPv6/Leases öffnen und man findet folgenden Eintrag:

 

 

IPv6-Leases

Unter Ubuntu ist es ebenfalls möglich eine eigene Adresse zu setzen, in dem man einen passenden Token definiert. Dieser Token wird einfach an das Prefix angefügt. In diesem Beispiel verwende ich hierfür diesen: 0000:0000:cafe:0001. Abgekürzt wird dies als ::cafe:0001 dargestellt. Dafür wird in der /etc/netplan/00-installer-config.yaml folgende Zeile ergänzt:

network:
ethernets:
ens34:
dhcp4: true
ipv6-address-token: "::cafe:0001"
version: 2

Dies ist eine weitere Möglichkeit eine "statische" IP zu erhalten, trotz wechselndem Prefix. Mittels "netplan apply" wird der Eintrag aktiviert.

Nochmals zusammengefasst: Das PREP Netzwerk erhält von OPNsense ein IPv6 Prefix welches in diesem Beispiel um df erweitert wurde um auf 64 Bit zu kommen. Die ersten 56 Bit sind dynamisch und ändern sich bei jeder Einwahl erneut. Die letzten 64 Bit können selbst vergeben werden. Wie oben gezeigt entweder per DHCPv6 oder per ipv6-address-token. Funktionieren tun beide Varianten.

Statische oder dynamische IPv6-Adresse

Sollte man, wie ich ein wechselndes IPv6 Prefix haben, sollte man die IP-Adresse über einen der gängigen DynDNS-Dienste erreichbar machen. Einfach dessen Anleitung befolgen, wie man einen IPv6 Eintrag anlegt. Hat man ein statisches Prefix, kann man den Eintrag direkt in der DNS-Verwaltung vornehmen.

OPNsense Alias

Nun benötigt man in der OPNsense Firewall noch eine Regel, welche übers WAN-Interface den Zugriff auf den Server erlaubt. In diesem Beispiel habe ich ein Apache auf dem Ubuntu installiert, welcher lediglich an Port 80 für http ran geht.

In der OPNsense verwende ich für interne Adressen ganz gerne Aliase. Hat man eine statische IP-Adresse, ist dieser rasch angelegt. Allerdings habe ich ein wechselndes Prefix. Hierfür hat OPNsense allerdings die passende Lösung parat: Ein Alias vom Typ "Dynamic IPv6 Host". Ich lege also unter Firewall/Aliase einen neuen Alias an, trage einen Namen ein, wählte den erwähnten Typ und setze als Content den Token welcher ebenfalls unter Ubuntu eingetragen wurde: ::cafe:0001 - oder gekürzt als ::cafe:1 dargestellt. Selbstverständlich funktioniert das ebenso für das oben gezeigte ::2000. Als Interface, damit OPNsense das passende Prefix wählt, gebe ich noch mein PREP Netzwerk an.

OPNsense IPv6 Alias

Funktionskontrolle gefällig? Hierzu unter Firewall/Diagnostic/Aliases wechseln und den neu angelegten Aliase auswählen. In der Liste der IP-Adressen steht bei mir der folgende Eintrag: 2a00:79c0:72b:2edf::cafe:1. Zu Beginn ist das Prefix welches ich von meinem Internetprovider erhalten habe, die Prefix-ID des PREP Interfaces ist df und als Token ist ::cafe:1 hinterlegt. Sobald sich OPNsense neu mit dem Internet verbindet, werden die ersten 56 Bit der Adresse automatisch angepasst.

 

Firewall Regel

Die Regel für die Firewall ist nun rasch erledigt. Auf dem WAN-Interface eingehend für IPv6, Quelle any und als Ziel der neu angelegte Alias eingetragen. Das war es.

OPNsense Firewall Regel

Funktionstest und Fazit

Zum Schluss ein kurzer Funktionstest: Der DNS-Aufruf zeigt die richtige IPv6-Adresse an, ein einfacher Aufruf via curl zeigt die Ausgabe vom Webserver an. Alternativ kann das natürlich ebenso mit einem Webbrowser geöffnet werden - falls man die Konsole nicht mag.

Wie gezeigt, ist es mit OPNsense rasch erledigt einen Homeserver via IPv6 im Internet erreichbar zu machen. Da man genügend öffentliche IPs erhält, kann man jeden Dienst mit einer eigenen IP ausstatten. Und, das angewendete Schema, kann man durchaus auf andere Systeme übertragen: Es muss kein Linux-Server sein, hier geht jedes andere IPv6 fähige Betriebssystem, welches den passenden Dienst anbietet. Ebenso kann OPNsense auf Firewall- bzw. Router-Seite durch alternativen ersetzt werden - solange diese mit wechselnden IPv6 Prefixen umgehen können.

Test
Postfix: IPv6 oder IPv4?

Postfix: IPv6 oder IPv4?

Mal wieder ein Problem zum Thema Email und Postfix. Neulich erst SMTPUTF8, jetzt wieder etwas was sich der Admin vor Ort nach Erklärungen und Lösungen sucht.

Fortune hat einmal zu mir folgendes gesagt:

The light at the end of the tunnel may be an oncoming dragon.

Für alle diejenigen die fortune nicht kennen: https://de.wikipedia.org/wiki/Fortune_(Computerprogramm).

Achtung!

Man sollte natürlich richtig prüfen, ob die IPv6 Auflösung eventuell sogar wirklich ein Problem hat. Da die Frage aufkam hier das grobe Vorgehen dazu: In der Fehlermeldung steht eine IPv6 Adresse drin. Diese per Reverse-DNS auflösen. Der Rechnername, der hierbei raus kommt sollte via Forward-DNS wieder zur gleichen IPv6 Adresse führen. Unterm Strich genauso, wie es auch für IPv4 der Fall sein sollte. Bitte dran denken. Nur wenn das alles passt und immer noch nichts hilft, dann kann dieses vorgehen wie hier beschrieben eine sinnvolle Variante sein.

Das Spiel beginnt

Bevorzugt kommen solche Fragen ja immer am spätem Nachmittag rein. Mal wieder das Thema Email. Mal wieder auf den ersten Blick dubios: Angeblich kann ein Emailserver keine Mails an eine bestimmte Empfangsdomain senden. Als Grund wird der fehlende Reverse DNS-Eintrag angegeben. Dieser ist aber gesetzt. So auf die schnelle passt hier irgendwas nicht zusammen, der detailliertere Blick ins Protokoll muss her. Hier findet sich folgendes - stark gekürzt und anonymisiert. Du weißt schon, Datenschutz und so 😉

May  7 14:12:37 methusalix postfix/smtp[587]: 0D2B11E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.57, delays=0.02/0.01/0.33/0.21, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00061t-DZ)
May  7 14:12:37 methusalix postfix/smtp[587]: 9600B1E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.35, delays=0.01/0/0.22/0.12, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00068z-RW)
May  7 14:13:23 methusalix postfix/smtp[587]: EAE621E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.4, delays=0.01/0/0.21/0.18, dsn=2.0.0, status=sent (250 OK id=1hNyyJ-0007Tp-6X)
May  7 14:55:19 methusalix postfix/smtp[6340]: A672D1E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.65, delays=0.01/0/0.5/0.14, dsn=2.0.0, status=sent (250 OK id=1hNzct-0006QR-6i)
May  7 15:13:07 methusalix postfix/smtp[8811]: 6C1A31E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1:1:1:1::1:1]:25, delay=0.39, delays=0.03/0.01/0.32/0.03, dsn=5.0.0, status=bounced (host mail.gatew.ay[1:1:1:1::1:1] said: 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1) 550 (methusalix.doma.in) [1:1:1:1::1]:44636 (in reply to RCPT TO command))

Aha... 4x geht es und einmal nicht. Was bei dem einen Versuch anders ist? Der war per IPv6, die anderen via IPv4. Ok, das mag ja jetzt sein: Reverse-DNS für IPv4 gesetzt, für IPv6 schlichtweg vergessen. Fix via host-Befehl im DNS abgefragt auf die IPv6 Adresse die laut Log keinen Reverse Eintrag haben soll: Oh wunder, der ist richtig auflösbar. Ab jetzt wird es seltsam. Aber wie so oft: Erstmal muss eine Lösung her. Die Suche nach der Ursache wird mal wieder hinten angestellt.

Also gut, das hier ist ganz klar ein Fall für den Blick in die Postfix Dokumentation bzw. in die aktuelle Konfiguration.

Recent Postfix SMTP clients randomly select between IPv4 and IPv6 so that mail won't get stuck when one of the two is down.

Wietse Zweitze Venema
Programmierer und Physiker

smtp_address_preference = any ist wie es sich gehört richtig gesetzt. Das macht so einfach mit am meisten Sinn und wird in der Dokumentation letztendlich genauso empfohlen. inet_protocols brauche ich gar nicht zu kontrollieren, muss auf any stehen. Sonst hätte es gar nicht die beiden unterschiedlichen Zustellvarianten geben dürfen. Um jetzt zu verstehen was da passiert sollte man die Doku kennen oder sich an das im Block links angeführte Zitat von Wietse erinnern.

Somit ist die Lösung für dieses Rätsel fix gefunden: Für diese eine Empfangsdomain sollte der Emailausgang ausschließlich auf IPv4 festgelegt werden. Nur kennt Postfix keine inet_protocol_map in der man dies festlegen könnte. Es ist also mal wieder die Frage nach etwas Kreativität um eine passende Lösung mit Postfix Mitteln entsprechend abzubilden.

Und der Weg zum Ziel ist unterm Strich mal wieder ganz einfach: Man definiert in der master.cf einen weiteren smtp Dienst welcher als Option das oben bereits erwähnte inet_protocols = ipv4 hat. Im zweiten Schritt noch fix einen passenden Eintrag für die Zieldomain in der transport Tabelle gesetzt welche genau diesen Dienst verwendet und voilà: Ziel erreicht.

Die Umsetzung

Die folgenden Beispiele zeigen an reinen Textdateien unter /etc/postfix die passende Konfiguration für die Empfängerdomain gehirn-mag.net. Wer dort bereits eine transport-Tabelle hat kann diese selbstverständlich nutzen. Wer ein Datenbank- oder LDAP-Backend hat kann diese Lösung sinngemäß übertragen. Hier aber, der Einfachheit wegen, das Beispiel an den "blanken" Textdateien. Und Du solltest logischerweise die Empfängerdomain richtig anpassen 🙂

Die erste Datei die geändert wird ist /etc/postfix/master.cf. Hier wird ein weiterer Dienst eingetragen. Eine Zeile analog zur ersten gibt es bereits. Wichtig ist, dass zu Beginn am Anfang und am Ende smtp steht und kein smtpd. Diese kopiert ihr, ändert den Namen (Zeile 2, Spalte 1) und fügt darunter den Inhalt der Zeile 3 ein.

Als nächstes ist /etc/postfix/main.cf dran. Hier ist zu prüfen ob es eine transport_maps Zeile gibt. Falls nicht fügt Ihr diese einfach ein.

Und zu guter Letzt ist die transport Tabelle /etc/postfix/transport selbst. Hier ist der Eintrag für die Zieldomain zu setzen, dass diese unseren neuen IPv4 smtp Dienst verwendet.

smtp      unix  -       -       y       -       -       smtp
smtp-ipv4 unix  -       -       y       -       -       smtp
    -o inet_protocols=ipv4
transport_maps = hash:/etc/postfix/transport
gehirn-mag.net           smtp-ipv4:

Nun müsst Ihr noch via postmap /etc/postfix/transport diese für postfix übersetzen und mit postfix reload den Mailserver neu starten. Postfix versendet nun für Eure Zieldomain alle Mails dorthin via IPv4 anstatt frei zu wählen was er jetzt verwenden könnte.

Und fertig!

Was eine Lösung. Ist das wirklich elegant gemacht auf diese Art und Weise? Ja, das ist Sie. Auf ihre ganz spezielle Art. Einen eigenen Dienst in der master.cf anzulegen macht man eigentlich öfters. Am häufigsten wohl als Ziel für irgendwelche Postfachsysteme wie IMAP/POP3 oder Groupware-Systeme. Wenn man diese externe Domain mit der sinngemäßen gleichen Logik betrachtet ist das schon sehr ähnlich: Ein Postfachspeicher welcher Emails via SMTP annimmt und obwohl er eine IPv6 Adresse hat kann der Dienst aber nur IPv4. Ich betreue Postfix Umgebungen bei denen aufgrund von der Vielzahl und der Größe der dahinter liegenden Groupware Lösungen die transport-Tabelle länger ist bei vielen anderen Installationen die virtual-Tabelle. Da erlebt man noch ganz andere Dinge...

In größeren Emailumgebungen ist man gefühlt nie am Ende mit der Konfiguration angekommen. Man mag sich in dem zu Beginn angesprochenen Tunnel fühlen. Sobald die Ursache aber sauber erfasst wurde ist die Lösung des Problems rasch erledigt und das Ende des Tunnels naht. Bis zum nächsten Anruf 😉

Aber morgen kontaktiere ich erstmals den Emailadmin auf der anderen Seite und frage nach den Gründen für diese Fehlermeldung - Feierabend für heute.

Quellen

  • GNU Bild: Wikimedia - kann aber genauso gut auf gnu.org direkt gezogen werden
  • Wietse Bild: Wikimedia - public domain