apache2 Proxy mit Cache

apache2 Proxy mit Cache

apache

Ich nutze im ioBroker als Wetter Adapter Weather Undergound. Damit rasch das eigene Wetter abgefragt und in vis-2 mit Material-Design als HTML-Ausgabe dargestellt. Einfach, schlicht – tut es mir. Nur beziehe ich die Icons direkt von Weather Underground. Das muss doch auch anders gehen: Also hab ich mal eben einen apache2 Proxy davorgesetzt. Damit sind meine Zugriffe lokal und zusätzlich noch mit einem Cache. Es lohnt ja nicht jedes Bild immer und immer wieder zu laden – wenn man es doch in einem Cache ablegen könnte.

Bevor einer fragt: Ja, das ist sicherlich nicht sicher einfach so alles ohne irgendwelche Sicherheitsmaßnahmen umzusetzen. Das weiß ich auch. Zum einen läuft das bei mir nur intern und nicht öffentlich im Internet, zum anderen ging es mir um die Funktion. Ich wollte das einfach mal mit apache2 umgesetzt haben. Nicht mehr, nicht weniger 😉 Und betrachte dies als Beispiel: Bei mir war die Ausgangslage ioBroker. Wer weiß, was es bei Dir ist 😛

Das hier will ich haben:

Weather Underground im ioBroker

Das aktuelle Wetter inklusive Vorhersage 😉

Und so ist es gelöst – einfach folgenden HTML-Code in einem „Vis 2 Material-Widgets HTML-Vorlage“ einfügen:

<style>
.grid-container {
    display: grid;
    grid-template-columns: 64px auto;
    gap: 5px;
    padding: 5px;
    font-size: 0.8em;
}
.grid-container div {
    margin: auto 0;
}
.grid-container img {
    width: 64px;
    height: 64px;
}
</style>

<div class="grid-container">
    <div>
        <img src="{v:weatherunderground.0.forecast.0d.iconURL;alt:0_userdata.0.Wetter.Tagesvorhersage.VorhersageIcon;v?v:alt}">
    </div>
    <div>
        <span style="font-weight:bold;">Jetzt</span><br>
        {weatherunderground.0.forecast.current.temp} °C
    </div>

    <div>
        <img src="{v:weatherunderground.0.forecast.0d.iconURL;alt:0_userdata.0.Wetter.Tagesvorhersage.VorhersageIcon;v?v:alt}">
    </div>
    <div>
        <span style="font-weight:bold;">Heute: {weatherunderground.0.forecast.0d.date;date(DD.MM.YYYY)}</span>
        <br>
        {weatherunderground.0.forecast.0d.tempMin}
        -
        {weatherunderground.0.forecast.0d.tempMax} °C
        ({weatherunderground.0.forecast.0d.cloudCover} % Wolkendichte)
        <br>
        Regen: {weatherunderground.0.forecast.0d.precipitationChance} % ({weatherunderground.0.forecast.0d.precipitationAllDay} mm)
        <br>
        {weatherunderground.0.forecast.0d.state}
    </div>

    <div>
        <img src="{weatherunderground.0.forecast.1d.iconURL}">
    </div>
    <div>
        <span style="font-weight:bold;">{weatherunderground.0.forecast.1d.date;date(DD.MM.YYYY)}</span>
        <br>
        {weatherunderground.0.forecast.1d.tempMin}
        -
        {weatherunderground.0.forecast.1d.tempMax} °C
        ({weatherunderground.0.forecast.1d.cloudCover} % Wolkendichte)
        <br>
        Regen: {weatherunderground.0.forecast.1d.precipitationChance} % ({weatherunderground.0.forecast.1d.precipitationAllDay} mm)
        <br>
        {weatherunderground.0.forecast.1d.state}
    </div>

    <div>
        <img src="{weatherunderground.0.forecast.2d.iconURL}">
    </div>
    <div>
        <span style="font-weight:bold;">{weatherunderground.0.forecast.2d.date;date(DD.MM.YYYY)}</span>
        <br>
        {weatherunderground.0.forecast.2d.tempMin}
        -
        {weatherunderground.0.forecast.2d.tempMax} °C
        ({weatherunderground.0.forecast.2d.cloudCover} % Wolkendichte)
        <br>
        Regen: {weatherunderground.0.forecast.2d.precipitationChance} % ({weatherunderground.0.forecast.2d.precipitationAllDay} mm)
        <br>
        {weatherunderground.0.forecast.2d.state}
    </div>

    <div>
        <img src="{weatherunderground.0.forecast.3d.iconURL}">
    </div>
    <div>
        <span style="font-weight:bold;">{weatherunderground.0.forecast.3d.date;date(DD.MM.YYYY)}</span>
        <br>
        {weatherunderground.0.forecast.3d.tempMin}
        -
        {weatherunderground.0.forecast.3d.tempMax} °C
        ({weatherunderground.0.forecast.3d.cloudCover} % Wolkendichte)
        <br>
        Regen: {weatherunderground.0.forecast.3d.precipitationChance} % ({weatherunderground.0.forecast.3d.precipitationAllDay} mm)
        <br>
        {weatherunderground.0.forecast.3d.state}
    </div>

    <div>
        <img src="{weatherunderground.0.forecast.4d.iconURL}">
    </div>
    <div>
        <span style="font-weight:bold;">{weatherunderground.0.forecast.4d.date;date(DD.MM.YYYY)}</span>
        <br>
        {weatherunderground.0.forecast.4d.tempMin}
        -
        {weatherunderground.0.forecast.4d.tempMax} °C
        ({weatherunderground.0.forecast.4d.cloudCover} % Wolkendichte)
        <br>
        Regen: {weatherunderground.0.forecast.4d.precipitationChance} % ({weatherunderground.0.forecast.4d.precipitationAllDay} mm)
        <br>
        {weatherunderground.0.forecast.4d.state}
    </div>        

    <div>
        <img src="{weatherunderground.0.forecast.5d.iconURL}">
    </div>
    <div>
        <span style="font-weight:bold;">{weatherunderground.0.forecast.5d.date;date(DD.MM.YYYY)}</span>
        <br>
        {weatherunderground.0.forecast.5d.tempMin}
        -
        {weatherunderground.0.forecast.5d.tempMax} °C
        ({weatherunderground.0.forecast.5d.cloudCover} % Wolkendichte)
        <br>
        Regen: {weatherunderground.0.forecast.5d.precipitationChance} % ({weatherunderground.0.forecast.5d.precipitationAllDay} mm)
        <br>
        {weatherunderground.0.forecast.5d.state}
    </div>

</div>

Im Objekt {weatherunderground.0.forecast.0d.iconURL} stehen URLs wie diese hier: https://www.wunderground.com/static/i/c/v4/28.svg. Und ich hätte gerne, dass daraus das hier wird: https://10.96.100.66:8082/proxy.0/img/https://www.wunderground.com/static/i/c/v4/28.svg. Damit vis-2 keinen externen Apache direkt aufruft, nutze ich den Proxy-Adapter. In diesem ist folgender Pfad gesetzt: aus /proxy.0/img/… mache https://10.96.100.66:4444/img/… wie in folgendem Screenshot gezeigt:

ioBroker Proxy-Adapter

ioBroker Proxy-Adapter Pfad-Einstellung

So wie ich vis-2 in meinem Webbrowser öffne und mir die Wettervorhersage anschaue, werden im Webbrowser die Bilder über die gleiche Adresse geladen, wie vis-2 selbst. Im Hintergrund setzt der Proxy-Adapter, wie oben gezeigt, die Anfragen auf den lokal installieren apache2 um – welcher die Proxy Anfragen an Port 4444 annimmt.

Dazu habe ich in der apache2 Konfig einen neuen vhost angelegt. Dieser lauscht auf Port 4444 und ist via https erreichbar. Als Cache nutze ich das apache2 Modul cache_disk. Damit das korrekt funktioniert, lasse ich die eventuell von der eigentlichen Anfrage gelieferten Header zum Caching durch meine eigenen überschreiben. Als nächstes wird die URL umgeschrieben. Aus https://<meine ioBroker>:4444/img/<https://das eigentliche Bild> soll einfach der Teil nach /img/ extrahiert und als eigentliche Bild-Quelle verwendet werden. Hier gibt es lediglich einen kleinen Haken: apache2 ersetzt // bei https:// durch einen /. Es wird aus der URL also http:/<wohin auch immer>. Deswegen wird die neue URL aus dem Protokoll, verbunden durch einen / und der eigentlichen Anfrage, zusammengesetzt. Sollte es zu einem Fehler kommen, lasse ich ein fallback.svg anzeigen. Und zuletzt lasse ich noch in die Standardlogdaten entsprechende Hinweise eintragen.

So sieht das ganze aus:

Listen 4444
<VirtualHost *:4444>
    ServerName imgprx.gehirn-mag.net.internal

    SSLEngine on
    SSLCertificateFile  /etc/apache2/ssl/fullchain.pem
    SSLCertificateKeyFile /etc/apache2/ssl/key.pem

    # --- Caching ---
    Header unset Cache-Control
    Header unset Pragma
    Header set Cache-Control "public, max-age=86400"
    CacheQuickHandler off
    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheIgnoreHeaders Set-Cookie Cache-Control Pragma Expires
    CacheRoot /var/cache/apache2/mod_cache_disk
    CacheEnable disk /
    CacheDisable /fallback.svg
    CacheDefaultExpire 604800
    CacheMaxExpire 604800

    # --- URL Rewrite für /img/<https://asfasfdsa> ---
    # Apache macht aus https://bla... https:/bla... <-- Split in zwei Teile
    SSLProxyEngine On
    RewriteEngine On
    RewriteRule ^/img/(https?:)(.+)$ - [E=TARGET:$1/$2,E=TPROTO:$1,E=TURL:$2]
    RewriteCond %{ENV:TARGET} !=""
    RewriteRule ^(.*)$ %{ENV:TARGET} [P,L]

    # --- Fallback bei Fehlern ---
    ProxyErrorOverride On
    ErrorDocument 404 /fallback.svg
    ErrorDocument 500 /fallback.svg
    ErrorDocument 502 /fallback.svg
    ErrorDocument 503 /fallback.svg
    ErrorDocument 504 /fallback.svg
    Alias /fallback.svg /var/www/vhosts/proxy/fallback.svg

    # --- Log ---
    CustomLog /var/log/apache2/other_vhosts_access.log "%h %l %u %t \"%r\" %>s %b \"cache:%{cache-status}e\" \"target:%{TARGET}e\""
    ErrorLog  /var/log/apache2/error.log
</VirtualHost>

Im HTML-Vorlage Widget vom ioBroker habe ich die URLs nun wie folgen geändert: <img src=“/proxy.0/img/{weatherunderground.0.forecast.1d.iconURL}“>. Also lediglich ein /proxy.0/img vorangestellt. Bekommen habe ich also, dass im Webbrowser die externen Bilder ebenfalls über vis-2 geladen werden. Allerdings geht im Hintergrund ein apache2 ran, welcher die gewünschten Bilder aus dem Internet im Sinne eines Proxys lädt und diese sogar noch in einem Cache ablegt.

Und, nochmals erwähnt: Das läuft bei mir nur intern. Letztendlich lädt dieser Proxy alles aus dem Netz, was hinter /img/ steht. Sollte man das also wirklich ungeschützt ins Internet packen wollen, dann wären noch diverse weitere Einstellungen zum Thema Sicherheit sehr sinnvoll. Für meine Zwecke, wo ich im ersten Schritt nur wissen wollte, ob und wie man so etwas in apache2 lösen kann, tut es das mehr wie Dicke. Ich weiß, dass es geht – denn ich habe eine lauffähige Konfig 😀

by Mai 03, 2026 Keine Kommentare
Nextcloud: aus Alt mach Neu

Nextcloud: aus Alt mach Neu

Nextcloud

Eine nette, kleine Aufgabe: Ziehe ein Nextcloud-System von einem Webserver auf einen anderen um. Klingt zu einfach – der Haken an der Geschichte war rasch gefunden: Nextcloud „alt“ ist Version 24, aktuell ist die Version 29. Somit „alt“ PHP 7.4, „neu“ PHP 8.3. Auf dem alten System kann man nicht updaten, da das PHP zu alt und keine ausreichend neue Version vorhanden ist – auf dem neuen System kann man kein altes Nextcloud installieren, da das PHP dort zu neu und kein ausreichend altes PHP vorhanden ist. Dann halt ganz anders.

Achtung: ein sauberes Update von Nextcloud wird, gemäß Dokumentation, immer von einer auf die nächste Hauptversion gemacht. Also zuerst die aktuell laufende Version auf den letzten Patchstand gehoben, dann der Wechsel der Hauptversion. Also 24.x aktualisieren, dann der Wechsel auf 25. 25.x aktualisieren, dann der Wechsel auf 26. Und dies macht man so lange, bis man bei der aktuellsten Version angekommen ist.

Den Weg wollte ich allerdings nicht gehen – die Quelldistribution war mit RHEL 7 mindestens genauso alt wie Nextcloud 24, somit kam ein Update auf Ubuntu 24.04. Egal welche Distribution: die alte Umgebung hat ein altes PHP, die neue ein neues. Und irgendwie sind die nur bedingt kompatibel zueinander. Also hätte ich im ersten Schritt ein Ubuntu nehmen können, welches ebenfalls PHP 7.4 anbietet. Das grundlegend einrichten, Nextcloud 24 darauf migrieren. Solange Nextcloud Updates machen wie Nextcloud das zulässt. Sobald das Ende erreicht ist, kann man das Ubuntu auf das nächste Release heben. Mit dem nun aktuelleren PHP kann man Nextcloud weiter updaten. Bis auch hier nichts mehr geht, da das PHP zu alt ist. Also wieder Ubuntu auf die nächste Variante bringen und das Spiel nochmals von vorn.

Das wäre „sauber“. Und wäre auch konsequenterweise richtig, wenn am Quellsystem regelmäßig Updates eingespielt worden wären. Dem war aber nicht so, ich bin derjenige der es korrigieren darf. Der obige Weg dauert mir zu lange, deswegen habe ich eine alternative Lösung gesucht.

Nextcloud ist eines der Systeme, welches nach einem Update erkennt, dass die Datenbank eine Aktualisierung braucht. Gegebenenfalls darf man via CLI und occ Befehl noch ein paar Indizies einfügen oder die ein oder andere Anpassung vornehmen. Das war es. Und an genau der Stelle setze ich an:

  • Ich installiere auf dem neuen Server ein aktuelles, leeres Nextcloud. Grundlegende Dinge richte ich bereits ein, allerdings nur das allernötigste. Die meisten Einstellungen werden durch die Übernahme der Daten aus dem Altsystem eh überschrieben. Du bist unsicher, was man bereits jetzt tun kann oder nicht? Dann warte bis zum Schluss.
  • Nun lösche ich die Datenbank und lege eine neue, aber leere Datenbank an.
  • Vom alten System kopiere ich die Datenbank auf den neuen Server.
  • Ebenso kopiere ich vom data Verzeichnis die Verzeichnisse der Benutzer. Achtung: Nicht alles, sondern wirklich nur dass, was ein Benutzer ist. Solche Dinge wie die Update-Daten sollte man wirklich überspringen.
  • Und nun beginnt die Magie: Es gibt Fälle, da ging der folgende Schritt per WebUI schief. Deswegen lieber die Kommandozeile verwenden. Sobald die Installation etwas größer wird, macht dies eh mehr Sinn. Also an die CLI gewechselt und occ upgrade aufgerufen. Nextcloud entdeckt, dass die Datenbankversion zu alt ist und beginnt deswegen mit den notwendigen Aktualisierungen.
  • Im nächsten Schritt meldete ich mich an der WebUI an. Ein grober Blick über die sichtbaren Daten sowie die Benutzer sollte jetzt bereits wieder erfolgreich sein.
  • Als Nächstes habe unter Administrationseinstellungen/Verwaltung/Übersicht die Sicherheits- und Einrichtungswarnungen angeschaut und entsprechend alles umgesetzt.
  • Hat das alte System Apps, die noch fehlen? Oder das neue, ein paar zu viel davon? Jetzt ist eine gute Gelegenheit.
  • Neue Systeme kennen neue Einstellungen. Mal alles auf Plausibilität prüfen – ob das so noch alles heute passt wie damals erdacht.
  • Testen, testen, testen …
  • Fertig

Das System läuft und ist zudem auf den aktuellsten Stand. Damit das so bleibt, kann man zum Beispiel folgenden Beitrag noch umsetzen: https://gehirn-mag.net/nextcloud-auto-update-via-cli/

Das Kopieren der Daten braucht halt die Zeit, die das Kopieren der Daten nun mal braucht. Allerdings habe ich mir die Update-Orgie erspart. Mal wieder die Welt eines Kunden gerettet, dieser ist glücklich. Mal schauen, welche Herausforderung mich als nächstes erwartet.

by Juni 04, 2024 Keine Kommentare
Ein IPv6 Homeserver via OPNsense

Ein IPv6 Homeserver via OPNsense

Firewall

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

by März 30, 2024 Keine Kommentare