geschätzte Lesezeit: 15 min

Mit eini­gen Vor­keh­run­gen las­sen sich Let’s-Encrypt-Zertifikate auch für inter­ne Net­ze nut­zen, die nicht vom Inter­net erreich­bar sind.

Zer­ti­fi­ka­te von Let’s Encrypt

Let’s Encrypt [1] bie­tet schon seit eini­gen Jah­ren kos­ten­lo­se SSL-Zer­ti­fi­ka­te für ein­zel­ne Domains an. Seit kur­zem wer­den auch Wild­card-Zer­ti­fi­ka­te aus­ge­stellt, die für alle Sub­do­mains einer Domain gül­tig sind. Wird ein sol­ches Zer­ti­fi­kat zum Bei­spiel für *.home​.kunz​.de aus­ge­stellt, gilt es auch für alle Sub­do­mains, also zum Bei­spiel auch für hinz​.home​.kunz​.de.

Damit lässt sich rela­tiv ein­fach ein Zer­ti­fi­kat gene­rie­ren, dass für alle Ser­ver im Heim-Netz gül­tig ist und nicht - wie ein selbst­si­gnier­tes Zer­ti­fi­kat - von Web-Brow­sern als unsi­cher mar­kiert wird. Die Let’s-Encrypt-Zertifikate sind aller­dings nur jeweils 60 Tage gül­tig. Des­we­gen macht es Sinn, die Erneue­rung des Home-Zer­ti­fi­kats auto­ma­tisch ablau­fen zu lassen.

Über­prü­fungs-Pro­ze­du­ren (Chal­len­ges)

Wäh­rend der Bean­tra­gung oder Erneue­rung der Zer­ti­fi­ka­te muss der Let’s Encrypt Ser­ver über­prü­fen, dass  die Domain dem Bean­tra­ger gehört oder von ihm admi­nis­triert wird. Dafür gibt es meh­re­re Mög­lich­kei­ten, unter ande­rem die web­root- und die DNS-Prozedur.

Die web­root Pro­ze­dur erwar­tet eine Sei­te mit vor­ge­ge­be­nem Inhalt im Wur­zel-Ver­zeich­nis des Web­ser­vers. Das lässt sich zwar sehr leicht auto­ma­ti­sie­ren, aber zur Über­prü­fung muss der Ser­ver vom Inter­net aus erreich­barr sein, was im Heim­netz Port­wei­ter­lei­tun­gen auf dem Inter­net-Rou­ter erfor­der­lich macht.

Bei der DNS-Pro­ze­dur muss beim DNS-Ser­ver der Zone ein TXT-Record mit vor­ge­ge­be­nem Namen und Inhalt ein­ge­stellt wer­den. Die­ser Ein­trag wird bei der Bean­tra­gung vom Let’s Encrypt Ser­ver abge­ru­fen. Dafür muss die Domain selbst nicht erreich­bar sein, was die Nut­zung für Domains in pri­va­ten Net­zen sehr ver­ein­facht. Für Wild­card-Zer­ti­fi­ka­te ist die DNS-Chal­len­ge die ein­zig mög­li­che Überprüfungs-Prozedur.

Let’s Encrypt cert­bot installieren

Zunächst muss auf einem Ser­ver im Heim­netz das Let’s Encrypt cert­bot Paket instal­liert wer­den. Bei mir ist die­ser Ser­ver ein stän­dig lau­fen­der Raspber­ry­PI mit dem Debi­an-Stretch-basier­ten NAS-Sys­tem open­me­diavault 4 (omv).

Bei Debi­an Stretch befin­det sich das cert­bot-Paket im stretch-back­ports-Repo­si­to­ry, das bei omv 4 bereits in den Paket­quel­len ein­ge­tra­gen ist.

$ sudo apt-get install certbot -t stretch-backports

Das Zer­ti­fi­kat manu­ell beantragen

Jetzt kön­nen wir cert­bot benut­zen, um das Zer­ti­fi­kat zu bean­tra­gen. Der certonly Schal­ter bewirkt, dass das Zer­ti­fi­kat nur abge­ru­fen, aber nicht instal­liert wird. Wild­card-Zer­ti­fi­ka­te wer­den nur vom acme-v02 Ser­ver aus­ge­stellt, der mit dem ser­ver Schal­ter ange­ge­ben wer­den muss. Unter -d wird die Wild­card-Domain ange­ge­ben, für die das Zer­ti­fi­kat aus­ge­stellt wer­den soll.

Da die ein­zi­ge unter­stütz­te Prü­fungs­art die DNS-Chal­len­ge ist, muss sie mit pre­fer­red-chal­len­ges dns aus­ge­wählt wer­den. Der manu­al Schal­ter gibt an, dass der TXT-Record manu­ell ein­ge­tra­gen wird. Zur Auto­ma­ti­sie­rung spä­ter mehr.

# certbot certonly --server https://acme-v02.api.letsencrypt.org/directory -d *.home.kunz.de --email webmaster@kunz.de --preferred-challenges dns --manual
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for home.kunz.de
-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.
Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.home.kunz.de with the following value:
dhfjknfhuioOHoihHohoioioih568_nvihUGüj87ui87
Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Nach­dem man sein Ein­ver­ständ­nis mit der Auf­zeich­nung sei­ner IP-Adres­se erklärt hat, druckt der cert­bot Namen und Inhalt des TXT-Records aus, der nun beim zustän­di­gen DNS-Zonen­ver­wal­ter - bei mir FreeDNS - ein­ge­tra­gen wer­den muss. Dazu öff­nen wir ein zwei­tes Terminal.

Die Heim­netz-Domain

Als Heim­netz-Domain wird eine Sub­do­main einer offi­zi­el­len Domain benutzt. Sie wird als Sub­do­main beim glei­chen Pro­vi­der ein­ge­tra­gen, der auch für die Basis-Domain ver­ant­wort­lich ist.

Wenn man vor­hat, auch vom Inter­net aus auf Ser­ver in der Heim-Domain zuzu­grei­fen, muss man auf die Diens­te eines dynDNS-Pro­vi­ders zurück­grei­fen. Ein­zel­hei­ten beschreibt der Arti­kel DynDNS für eine eige­ne Domain ein­rich­ten.

Im fol­gen­den arbei­ten wir mit dem DynDNS-Pro­vi­der FreeDNS, auf den die Namens­auf­lö­sung bei mei­nem Domain-Pro­vi­der dele­giert wurde.

Den DNS TXT-Record erzeugen

Nach Anmel­dung bei FreeDNS wäh­len wir aus dem Menü links den Ein­trag Dyna­mic DNS aus und kli­cken im Titel der Tabel­le der DNS-Records auf Add. Als Typ wäh­len wir TXT aus. Die Domain bleibt bei home​.kunz​.de. Unter Sub­do­main wird der gefor­der­te Chal­len­ge-Name und unter Desti­na­ti­on der Text in dop­pel­ten Anfüh­rungs­zei­chen eingetragen.

Nach dem Kli­cken auf Save che­cken wir per nslook­up, ob der TXT-Record schon ver­füg­bar ist, Das kann je nach TTL eini­ge Zeit dau­ern. Bei FreeDNS steht die TTL fest auf 60 Sekun­den, so dass spä­tes­tens nach etwa ein bis zwei Minu­ten der TXT-Record abruf­bar sein sollte.

$ nslookup
> set type=TXT
> _acme-challenge.home.kunz.de
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
_acme-challenge.home.kunz.de text = "dhfjknfhuioOHoihHohoioioih568_nvihUGüj87ui87"

Wei­ter mit cert­bot

Jetzt kann im ers­ten Ter­mi­nal der cert­bot mit Return fort­ge­setzt werden:

Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/home.kunz.de/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/home.kunz.de/privkey.pem
Your cert will expire on 2018-09-30. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
#

Geht alles gut, lie­gen am Ende Schlüs­sel­da­tei und Zer­ti­fi­kat unter /etc/letsencrypt/live/home.kunz.de und kön­nen direkt ver­wen­det werden.

Das Zer­ti­fi­kat in omv nutzen

Um das Zer­ti­fi­kat für open­me­diavault ver­füg­bar zu machen, wählt man im omv-Menü Zer­ti­fi­ka­te aus, klickt auf den SSL Tab und wählt unter Hin­zu­fü­gen den Ein­trag Impor­tie­ren aus. Unter Pri­va­ter Schlüs­sel wird der Inhalt von privkey.pem und unter Zer­ti­fi­kat der Inhalt von fullchain.pem ein­ge­tra­gen. In’s Kom­men­tar­feld gehört eine mög­lichst ein­deu­ti­ger Text, um das Zer­ti­fi­kat spä­ter iden­ti­fi­zie­ren zu können.

Zuletzt wählt man unter All­ge­mei­ne Ein­stel­lun­gen bei Siche­re Ver­bin­dung das neue Zer­ti­fi­kat aus und sichert die Einstellungen.

Ab jetzt soll­te der Brow­ser die omv-Sei­te als Sicher mar­kie­ren, wenn sie mit dem voll­stän­di­gen Namen, also zum Bei­spiel mit omv​.home​.kunz​.de,  auf­ge­ru­fen wird.

Die­ses Zer­ti­fi­kat kön­nen alle Ser­ver mit einer Sub­do­main unter home​.kunz​.de  benut­zen; sie wer­den dann eben­falls als Sicher eingestuft.

Auto­ma­ti­sie­rung der DNS-Challenge

Das Über­prü­fungs­ver­fah­ren der DNS-Chal­len­ge kann mit einem Script auto­ma­ti­siert wer­den. Der manu­al-auth-hook [2.1] wird auf­ge­ru­fen, bevor die Über­prü­fung der Chal­len­ge statt­fin­det. In die­sem Script muss der gefor­der­te TXT-Record beim DNS-Pro­vi­der erzeugt werden.

Für eini­ge, vor­wie­gend ame­ri­ka­ni­sche DNS-Pro­vi­der exis­tie­ren vor­de­fi­nier­te auth-Scripts [2.2]. Für alle ande­ren muss man das Script selbst erzeu­gen. Die nöti­gen Wer­te wie Name und Inhalt des TXT-Records wer­den vom cert­bot als Umge­bungs­va­ria­blen über­ge­ben [2.1]. Uns inter­es­siert im Moment ledig­lich die Varia­ble CERTBOT_VALIDATION, in der der erfor­der­li­che Inhalt des TXT-Records über­ge­ben wird.

Bei FreeDNS [3] kann der Inhalt eines bestehen­den TXT-Records mit fol­gen­dem CURL-Kom­man­do geän­dert werden:

curl -b "dns_cookie=XXXXXXXXXX" -d "type=TXT" -d "subdomain=_acme-challenge" -d "domain_id=0000" -d "data_id=0000" -d "address=%22some_text%22" https://freedns.afraid.org/subdomain/save.php?step=2

Die Varia­blen data_id, domain_id und dns_cookie müs­sen aus der FreeDNS Web-Sei­te abge­le­sen werden:

• Die data_id fin­det man unter dem Menu­ein­trag Sub­do­mains im Link zum edi­tie­ren des TXT-Records.
• Die domain_id steckt auf der glei­chen Sei­te im add Link hin­ter der Basis-Domain.
• Den Inhalt des DNS-Coo­kies kann man aus dem dns_cookie für freedns​.afraid​.org ablesen
  (Bei Chro­me: chrome://settings/cookies/detail?site=freedns.afraid.org).

Hat man alle Anga­ben zusam­men, kann man die Funk­ti­on zunächst auf der Kom­man­do­zei­le prü­fen. Im Erfolgs­fal­le erzeugt curl dabei kei­ne Aus­ga­be, son­dern kehrt Kom­men­tar­los zum Prompt zurück. Mit nslook­up kön­nen wir nach ein bis zwei Minu­ten prü­fen, ob der TXT-Record auch pro­pa­giert wird:

# nslookup -type=TXT _acme-challenge.home.kunz.de
Server: 192.168.2.1
Address: 192.168.2.1#53
Non-authoritative answer:
_acme-challenge.home.kunz.de text = "some_text"

Das curl Koman­do ste­cken wir nun in das Script freedns​-txt​.sh, dass der cert­bot dann als manu­al-auth-hook benut­zen kann:

#!/bin/bash
#
dns_cookie="xxxxxxxxxxxx"
domain_id="0000"
data_id="0000"
ttl=60
#
curl -S -b "dns_cookie=$dns_cookie" -d "type=TXT" -d "subdomain=_acme-challenge" -d "domain_id=$domain_id" -d "data_id=$data_id" -d "address=%22$CERTBOT_VALIDATION%22" https://freedns.afraid.org/subdomain/save.php?step=2
sleep $ttl

Der Schal­ter -S (oder --silent) bewirkt, dass curl kei­ne Fort­schritts­an­zei­ge, wohl aber Feh­ler­nach­rich­ten aus­gibt. Am Ende war­tet das Script, bis die TTL des (alten) DNS-Ein­trags abge­lau­fen ist, was bei FreeDNS nach 60 Sekun­den geschieht.

Auto­ma­ti­sche Zertifikats-Erneuerung

Das renew-Kom­man­do des cert­bot wird für einen Test mit dem Pfad zu obi­gem Script ergänzt und mit --dry-run getestet:

# certbot renew --manual-auth-hook=/root/freedns-txt.sh --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/home.kunz.de.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator manual, Installer None
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for home.kunz.de
Waiting for verification...
Cleaning up challenges
-------------------------------------------------------------------------------
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/home.kunz.de/fullchain.pem
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/home.kunz.de/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
-------------------------------------------------------------------------------

Wenn alles wie hier funk­tio­niert, kann die­ses Kom­man­do nun in die geplan­ten Auf­ga­ben des omv ein­ge­tra­gen wer­den, damit täg­lich über­prüft wird, ob das  Zer­ti­fi­kat erneu­ert wer­den muss.

Die Ver­tei­lung und Instal­la­ti­on des Zer­ti­fi­kats kann man eben­falls auto­ma­ti­sie­ren. Mit dem deploy-hook kann man ein Shell-Script ange­ben, dass nach einer erfolg­rei­chen Zer­ti­fi­kat­s­er­neue­rung auf­ge­ru­fen wird. Da mein pri­va­ter Ser­ver-Park aber noch über­schau­bar ist, ver­zich­te ich im Moment darauf.

Fazit

Mit einem Let’s Encrypt Zer­ti­fi­kat las­sen sich mit wenig Auf­wand auch Ser­ver absi­chern, die nicht vom Inter­net erreich­bar sind. Die Zer­ti­fi­kats-Erneue­rung lässt sich auto­ma­ti­sie­ren. Damit soll­ten auch im Heim­netz die Zei­ten unver­schlüs­sel­ter Über­tra­gun­gen vor­bei sein.

Nach­trag: crontab und sys­tem trigger

Das Debi­an-Paket cert­bot ent­hält schon sowohl einen crontab-Job als auch einen Sys­tem Trig­ger, die zwei mal täg­lich ver­su­chen, das Zer­ti­fi­kat zu erneu­ern. In mei­nem Fal­le läuft das schief, weil cert­bot ledig­lich mit

certbot renew -q

auf­ge­ru­fen wird. Wegen des feh­len­den manu­al-auth-hook schei­tert die­ser Ver­such immer mit einer Feh­ler­mel­dung in /var/log/letsencrypt/letsencrypt.log.

Man kann jetzt ent­w­der den Auf­ruf von cert­bot im Ser­vice cert­bot und im crontab ändern, oder bei­de stil­le­gen und wei­ter­hin den crontab-Ein­trag im omv benutzen.

Ich habe mich für letz­te­res ent­schie­den, weil dann alle cron-Jobs an einer Stel­le über­sicht­lich über die omv Web-Ober­flä­che zu ver­wal­ten sind.

Um den crontab-Ein­trag zu ent­fer­nen, löscht man ein­fach die Datei /etc/cron.d/certbot. Ser­vice und Trig­ger wer­den mit fol­gen­den Kom­man­dos entfernt:

systemctl stop certbot
systemctl stop certbot.timer
systemctl disable certbot
systemctl disable certbot.timer​
systemctl daemon-reload

Jetzt soll­te letsencrypt.log sau­ber bleiben.

Nach­trag 2: Umzug des certbot

[26.11.2018] Vor kur­zem war der Umzug des cert­bot auf einen ande­ren Ser­ver nötig. Dazu wird auf dem neu­en Ser­ver zunächst das cert­bot Paket installiert:

apt-get install certbot

Das manu­al-auth-hook Script wird vom alten Ser­ver an die glei­che Stel­le (bei mir: /root/freedns-txt.sh) auf dem neu­en Ser­ver kopiert. Zusätz­lich kopiert man die alten Zer­ti­fi­kats­da­ten aus /etc/letsencrypt des alten Ser­vers, am ein­fachs­ten per tar-Archiv:

cd /etc/letsencrypt
tar cfv trans.tar accounts archive csr keys live renewal

Das Archiv trans.tar wird in /etc/letsencrypt des neu­en Ser­vers kopiert und entpackt:

​cd /etc/letsencrypt
tar xvf trans.tar

Falls nicht ohne­hin vor­han­den, muss noch das beim manu­al-auth-hook benutz­te curl Paket nach­in­stal­liert werden:

apt-get install curl

Jetzt kann man die Auto­ma­ti­sche Zer­ti­fi­kats-Erneue­rung wie oben beschrie­ben tes­ten und als cron-Job eintragen.

1. Let’s Encrypt Home­page: let​sen​crypt​.org
2. Cert­bot Doku­men­ta­ti­on: cert​bot​.eff​.org/​d​o​c​s​/​u​s​i​n​g​.​h​tml
   1. Pre- and Post-Validation-Hooks
   2. DNS-Plugins
3. FreeDNS Hom­a­pa­ge: freedns​.afraid​.org

geschätzte Lesezeit: 14 min

Für vie­le Zwe­cke ist es prak­tisch, wenn man sein Heim­netz aus dem Inter­net über einen fes­ten Host­na­men errei­chen kann. Will man dafür kei­ne Sub­do­main des Dienste­be­trei­bers, son­dern eine eige­ne Domain benut­zen, erfor­dert das etwas mehr Aufwand.

Der Pio­nier DynDNS

DynDNS​.com war vor Jah­ren der Pio­nier der kos­ten­lo­sen Diens­te für die dyna­mi­sche Zuord­nung einer IP-Adres­se zu einem Host­na­men. Man benö­tigt einen sol­chen Dienst, wenn man sein Heim­netz aus dem Inter­net mit einem fes­ten Host­na­men errei­chen will, auch wenn der Inter­net-Pro­vi­der regel­mä­ßig die Ver­bin­dung trennt und eine neue IP-Adres­se für den Anschluss ver­gibt. Im Ide­al­fall über­nimmt der Inter­net-Rou­ter auto­ma­tisch die Aktua­li­sie­rung der Adres­se beim DynDNS-Provider.

DynDNS-Alter­na­ti­ven

Inzwi­schen ist DynDNS von Ora­cle auf­ge­kauft wor­den und bie­tet kei­ne kos­ten­lo­sen Diens­te mehr an. Dafür sind vie­le ande­re in die Bre­sche gesprun­gen, die gleich­wer­ti­ge oder sogar bes­se­re Ange­bo­te haben. Schwie­rig wird es aller­dings, wenn man ent­we­der kei­ne Sub­do­main des DynDNS-Pro­vi­ders, son­dern eine eige­ne Domain ver­wen­den will, oder wenn der Inter­net-Rou­ter den aus­ge­wähl­ten DynDNS-Dienst nicht anbietet.

Bei mir trifft lei­der bei­des zu. Für mein Heim­netz will ich eine von mei­ner öffent­li­chen Domain abge­lei­te­te Sub­do­main benut­zen, und der DynDNS-Dienst, der so etwas anbie­tet, wird von mei­nem Tele­kom-Speed­port-Rou­ter nicht angeboten.

Aus­wahl des DynDNS-Anbieters

Wie oben schon erwähnt, soll der DynDNS-Dienst zumin­dest für den Pri­vat­be­darf kos­ten­los sein. Das ist bei vie­len Anbie­tern mög­lich, die meist einen kos­ten­lo­sen Basis-Ser­vice neben kos­ten­pflich­ti­gen Pre­mi­um-Accounts offerieren.

Auch ein Inter­face, mit dem man die Adres­se von einem Rech­ner des Heim­net­zes aus aktua­li­sie­ren kann, bie­ten die meis­ten Pro­vi­der an.

Der Dienst­leis­ter soll aber zudem mit belie­bi­gen Domains arbei­ten kön­nen. Bei die­ser Bedin­gung fal­len lei­der die meis­ten Anbie­ter aus der Wahl, weil sie nur Sub­do­mains ihrer eige­nen Domain anbie­ten, etwa self​host​.eu oder no​-ip​.com.

Regis­trie­rung bei FreeDNS

Übrig blieb für mich der Anbie­ter FreeDNS. Nach Regis­trie­rung kann man dort in sei­nem kos­ten­lo­sen Kon­to eine belie­bi­ge Domain ein­tra­gen und über die Name­ser­ver des Anbie­ters eine über das dyndns1-Pro­to­koll dyna­misch änder­ba­re IP-Adres­se zuord­nen lassen.

Dafür legt man sich zunächst ein Kon­to bei FreeDNS an. Der Kos­ten­lo­se Star­ter-Account reicht dafür aus. Wenn man FreeDNS unter­stüt­zen will, kann man aber auch ein kos­ten­pflich­ti­ges Kon­to mit Pre­mi­um-Sup­port aus­wäh­len. Nach Absen­den des For­mu­lars und Akti­vie­rung per eMail kann man sich unter Dyna­mic DNS eine Domain ein­rich­ten, in unse­rem Bei­spiel home​.kunz​.de.

Danach wer­den auto­ma­tisch zur Basis­do­main vier Sub­do­mains (ftp, irc, mail, www) ange­legt, die alle auf die Adres­se der Basis­do­main zei­gen. Über den add Link im Tabel­len­kopf wird jetzt noch ein A Record für die Sub­do­main ein­ge­tra­gen, über die spä­ter unser Ser­vice vom Inter­net erreich­bar sein soll, etwa cloud​.home​.kunz​.de. Sie bekommt die glei­che Ziel­adres­se wie die ande­ren Subdomains.

DNS-Dele­gie­rung einrichten

Unse­re Heim­netz-Adres­se home​.kunz​.de ist jetzt zwar auf den FreeDNS-Ser­vern ein­ge­rich­tet, aber da FreeDNS nicht der Ver­wal­ter der Basis-Domain kunz​.de ist, wird sie noch nicht in’s Inter­net propagiert.

Beim Ver­wal­ter der Basis-Domain - das ist bei mir Hetz­ner - muss home​.kunz​.de als Sub­do­main von kunz​.de ein­ge­rich­tet und die Namens­auf­lö­sung an die Name­ser­ver von FreeDNS dele­giert werden.

Die Sub­do­main kann ganz nor­mal über die Web-Ober­flä­che der Kon­so­leH per Einstellungen->Konfiguration->Subdomains ein­ge­rich­tet wer­den. Auf wel­ches Ver­zeich­nis sie zeigt, ist nicht von Belang, da die Adres­se spä­ter nicht auf Hetz­ner zei­gen wird. Sie wird nach der Dele­gie­rung sogar wie­der aus de Sub­do­main-Lis­te verschwinden.

Für die Dele­gie­rung muss aller­dings die Zonen­da­tei direkt edi­tiert wer­den - die Web­ober­flä­che lässt die Erzeu­gung von NS-Records nicht zu. Die DNS-Kon­fi­gu­ra­ti­on erreicht man über Einstellungen->Konfiguration->DNS-Verwaltung. Klickt man im Kopf der Domain auf Erwei­ter­te Ansicht, prä­sen­tiert die Sei­te den Inhalt der Zonendatei.

Unter­halb der exis­tie­ren­den NS-Records fügen wir nun die Dele­gie­rung an FreeDNS mit fol­gen­den Zei­len ein:

home IN NS ns4.afraid.org.
home IN NS ns3.afraid.org.
home IN NS ns2.afraid.org.
home IN NS ns1.afraid.org.

Das dele­giert die Namens­auf­lö­sung für die Sub­do­main home an einen der vier Name­ser­ver von FreeDNS. Der Punkt am Ende der Zei­len ist übri­gens wich­tig, denn er ver­hin­dert die Suche nach den DNS-Ser­vern in unse­rer eige­nen Domain. Die Zei­le mit dem A-Record für home

home IN A <ip-address>

wird gelöscht. Mit Zone­fi­le spei­chern sichern wir die Ände­run­gen. Bis sie bei ande­ren DNS-Ser­vern wirk­sam wer­den, kön­nen eini­ge Stun­den ver­ge­hen, denn meist sind die A-Records mit einer TTL von 24 Stun­den ver­se­hen. Am bes­ten legen wir jetzt also eine Pau­se ein und arbei­ten am nächs­ten Tag weiter.

DynDNS-Cli­ent installieren

Wir benö­ti­gen jetzt noch eine Pro­ze­dur, die bei FreeDNS die IP-Adres­se für unse­re Domain aktua­li­siert, sobald sie sich geän­dert hat. Wer so glück­lich ist, einen Rou­ter zu besit­zen, der die freie Aus­wahl des DynDNS-Anbie­ters erlaubt, ist jetzt schon fast fer­tig: er muss am Rou­ter ledig­lich den DNS-Anbie­ter aus­ge­wäh­len oder Adres­se und Pro­to­koll sowie den Namen der Domain ein­ge­tra­gen. Dann mel­det sich der Rou­ter von selbst beim DynDNS-Pro­vi­der und ändert wenn nötig die Adresse.

Die Speed­port-Rou­ter der Tele­kom erlau­ben nur eine sehr beschränk­te Lis­te von DynDNS-Anbie­tern, zu der FreeDNS lei­der nicht gehört. Wir müs­sen also einen Host im Heim­netz zum DynDNS-Cli­ent machen. Bei mir soll ddcli­ent auf dem stän­dig lau­fen­den Raspber­ry­PI mit open­me­diavault lau­fen, das auf der Linux-Dis­tri­bu­ti­on Debi­an Stretch basiert.

Für Linux bie­tet sich als DynDNS-Cli­ent der bewähr­te ddcli­ent an, der unter sei­nen unter­stütz­ten DynDNS-Pro­vi­dern auch FreeDNS hat. Er ist für die meis­ten Linux-Dis­tri­bu­tio­nen als Paket ver­füg­bar. Das Debi­an-Paket wird mit dem fol­gen­den Befehl installiert:

apt install ddclient libio-socket-ssl-perl

Kon­fi­gu­ra­ti­on von ddclient

Wäh­rend der Instal­la­ti­on fragt die Pro­ze­dur schon eini­ge Para­me­ter ab. Man kann sie nach bes­tem Wis­sen beant­wor­ten, aber die Kon­fi­gu­ra­ti­ons­da­tei muss in jedem Fal­le noch­mals bear­bei­tet wer­den. Dazu öff­nen wir /etc/ddclient.conf und ändern sie auf fol­gen­den Inhalt:

# Configuration file for ddclient
#
# /etc/ddclient.conf
ssl=yes
syslog=yes
mail=<mail-address>
mail-failure=<mail-address>
protocol=freedns
use=web, web=checkip.dyndns.com/, web-skip='IP Address'
server=freedns.afraid.org
login=<freedns-account>
password='<freedns-password>'
home.kunz.de

Die Platz­hal­ter <mail-address>, <freedns-account> und <freedns-pass­word> müs­sen natür­lich ent­spre­chend ange­passt wer­den. Die Web­sei­te che​ckip​.dyndns​.com lie­fert uns unse­re eige­ne Inter­net-Adres­se, also die exter­ne Adres­se unse­res Inter­net-Rou­ters. ddcli­ent trägt die­se dann bei FreeDNS ein.

Jetzt kön­nen wir mit ddcli­ent einen Test­lauf auf der Kom­man­do­zei­le starten.

# ddclient
SUCCESS: update not necessary home.kunz.de: good: IP address already set to 1.2.3.4
#

Ein Update der Adres­se ist in die­sem Bei­spiel nicht nötig, weil sie schon kor­rekt ist. Man kann ihn aber pro­vo­zie­ren, indem man am Rou­ter die Inter­net-Ver­bin­dung kurz kappt und neu auf­bau­en lässt. Der Inter­net-Pro­vi­der weist dabei eine ande­re exter­ne Adres­se zu. Das erkennt ddcli­ent und setzt die Adres­se bei FreeDNS ent­spre­chend um.

# ddclient
SUCCESS: updating home.kunz.de: good: IP address set to 2.3.4.5
#

Der ddcli­ent läuft als Ser­vice und prüft nun regel­mä­ßig unse­re Adres­se auf Änderung.

Jetzt müs­sen nur noch die ent­spre­chen­den Port­wei­ter­lei­tun­gen am Inter­net-Rou­ter ein­ge­tra­gen wer­den. Danach kann man die gewünsch­ten Hosts vom Inter­net über die Domain home​.kunz​.de erreichen.

Inter­ne DNS-Auflösung

Will man den neu­en Ser­vice vom inter­nen Netz aus errei­chen, wür­de man über das DNS eben­so die exter­ne Adres­se des Rou­ters erhal­ten wie jeder Cli­ent aus dem Inter­net. Man wür­de also über den Rou­ter ins Inter­net gerou­tet wer­den, um dann wie­der am exter­nen Port des­sel­ben Rou­ters zu lan­den und über die Port­wei­ter­lei­tung zurück in das inter­ne Netz zu kommen.

Abge­se­hen davon, dass das natür­lich nicht viel Sinn macht, beherr­schen vie­le Rou­ter die­sen loo­p­back nicht. Beim Tele­kom Speed­port läuft man so ein­fach in einen Timeout.

Sinn­vol­ler ist es, für die inter­nen Cli­ents vom DNS gleich die inter­ne Adres­se des Ser­vice gelie­fert zu bekom­men. Das setzt aber vor­aus, dass man dem DNS-Resol­ver des inter­nen Net­zes sta­ti­sche Adres­sen „unter­schie­ben” kann. Wäh­rend das bei bes­se­ren Rou­tern mög­lich ist, muss der Speed­port auch hier passen.

Eige­ner DNS-Server…

Bleibt also nur die radi­ka­le Lösung: Statt des Speed­port wird ein ande­rer Ser­ver zum DNS-Resol­ver gemacht. Dafür bie­tet sich das NAS als stän­dig lau­fen­de Maschi­ne natür­lich an. Mit der omv-Erwei­te­rung open­me­diavault-dns­masq funk­tio­niert  das auch recht ein­fach: Erwei­te­rung instal­lie­ren und mit dem Akti­vie­ren Knopf scharf schal­ten. Bei Domain Name tra­gen wir unse­re home Domain ein, also home​.kunz​.de.

Auf der Sei­te Sta­tic Ent­ries kann man jetzt die inter­nen Adres­sen der Ser­ver unse­rer home Domain ein­tra­gen. Spei­chern wir jetzt für cloud​.home​.kunz​.de die inter­ne Adres­se ab, etwa 192.168.1.123, lan­den die inter­nen Cli­ents direkt am ent­spre­chen­den Ser­ver, wäh­rend die Cli­ents aus dem Inter­net vom DNS die exter­ne Adres­se unse­res Rou­ters gelie­fert bekommen.

Damit das funk­tio­niert, müs­sen die inter­nen Cli­ents natür­lich den neu­en DNS-Ser­ver ver­wen­den. Bei Cli­ents mit sta­ti­scher IP-Adres­se kann man den DNS-Ser­ver direkt in die Inter­face-Kon­fi­gu­ra­ti­on ein­tra­gen. Bei Cli­ents, die ihre Adres­se über DHCP erhal­ten funk­tio­niert das aber nicht.

… und eige­ner DHCP-Server

Der DNS-Ser­ver wird dem Cli­ent bei der Adress­ver­ga­be vom DHCP-Ser­ver über­ge­ben. Hat man am Rou­ter (wie beim Speed­port) kei­ne Chan­ce, die­sen Ser­ver zu ändern, muss auch ein eige­ner DHCP-Ser­ver auf­ge­setzt werden.

Glück­li­cher­wei­se ist im open­me­diavault-dns­masq Paket auch ein DHCP-Ser­ver ent­hal­ten. Er wird über die Start­sei­te des Local DNS/DHCP Diens­tes akti­viert. Bei Lea­se Net­work selek­tie­ren wir unse­re Netz­werk-Adres­se und -Mas­ke, also etwa 192.168.1.0/255.255.255.0 aus der Lis­te. Das Gate­way ist unser Speed­port-Rou­ter, also z.B. 192.168.1.1.

Unter First IP Address und Last IP Address wer­den die ers­te und letz­te Adres­se unse­res dyna­misch ver­ge­be­nen Adress­be­reichs ein­ge­tra­gen. Im Zwei­fel hilft ein Blick in die aktu­el­le Ein­stel­lung des Speed­ports - der Bereich soll­te 1:1 über­nom­men wer­den. Unter Lea­se Time kann zunächst der Stan­dard­wert ste­hen bleiben.

Als letz­tes wird unter DNS Server(s) noch die Adres­se unse­res Speed­ports ein­ge­tra­gen. Die­ser DNS-Ser­ver wird zum For­ward benutzt, wenn unser neu­er DNS-Ser­ver die Adres­se nicht selbst auf­lö­sen kann. Jetzt kann die Kon­fi­gu­ra­ti­on abge­spei­chert und akti­viert werden.

Der DHCP-Ser­ver des Rou­ters muss jetzt zwin­gend abge­schal­tet wer­den, ansons­ten wür­den die Cli­ents unvor­aus­sag­bar ihre Adres­se mal vom einen, mal vom ande­ren DHCP-Ser­ver bekom­men. Bei über­lap­pen­den Adress­be­rei­chen könn­te das sogar zur Mehr­fach­ver­ga­be von Adres­sen füh­ren und unser Netz poten­ti­ell lahmlegen.

Jeder Cli­ent, der sich ab jetzt neu mit dem Netz ver­bin­det, erhält sei­ne Adres­se und damit auch den DNS-Ser­ver vom neu­en DHCP-Ser­ver. Damit erreicht er die Ser­vices ohne den Umweg über exter­ne Adressen.

Win­dows-Cli­ents und IPv6

Bei Win­dows-Cli­ents mit sta­ti­schen Adres­sen kann man zwar auch den DNS-Ser­ver in der Inter­face-Kon­fi­gu­ra­ti­on ein­tra­gen, aber die Ein­tra­gung des IPv6-DNS-Ser­vers wird der des IPv4-Ser­vers vor­ge­zo­gen, so dass DNS-Abfra­gen wei­ter­hin beim Rou­ter lan­den wür­den. Der ein­zi­ge mir bekann­te funk­tio­nie­ren­de Work­around ist, das IPv6-Pro­to­koll für das Inter­face kom­plett abzuschalten.

Fazit

DynDNS kann ganz ein­fach funk­tio­nie­ren, wenn man mit einer vor­ge­ge­be­nen Domain zufrie­den ist und der Rou­ter den DynDNS-Pro­vi­der unter­stützt. Will man eine eige­ne Domain und/oder einen spe­zi­el­len DynDNS-Pro­vi­der ver­wen­den, ist die Sache etwas kom­li­zier­ter. Mit die­ser Anlei­tung schafft man es trotz­dem sicher.

geschätzte Lesezeit: 4 minHi zusammen,

entschuldigt erst einmal die späte Antwort. Direkt nach der Rückkehr war es hier etwas stressig und dann habe ich es einfach vergessen zu antworten.

Grundsätzlich

Die Ladesituation in Griechenland würde ich als durchwachsen bezeichnen. In den Städten gibt es relativ viele Ladestationen, zum Teil sogar (noch) kostenlos. Aber bspw. in Thessaloniki gibt es keine Probleme eine freie Ladestation zu finden.

Problematisch wird es auf der Autobahn. Gerade das Stück von Igoumenitsa nach Thessaloniki ist schwierig. Schnellladestationen waren noch relativ rar gesät und befinden sich primär in der Nähe der Städte.
Allerdings bauen aktuell einige Tankstellen (meist Avin) Ladestationen auf. Da wird sich also vermutlich einiges verbessern.
Ein großer Akku ist aber im Moment meiner Meinung nach noch ziemlich wichtig. Zumindest, wenn unterwegs keine Zwischenübernachtungen geplant werden sollen.

Unsere Tour

Fahrzeug: Hyundai Kona 64kWh Modell 2021.

Wir kamen mit der Fähre in Igoumenitsa an. Da wir von Ancona übergefahren sind und dort noch Zeit zum Laden hatten, kamen wir mit ca. 90% an.
Da die Fähre Verspätung hatte, mussten wir sowieso eine Übernachtung einplanen und haben diese ungefähr nach einem Drittel der Strecke zwischen Igoumentisa und Thessaloniki in Metsovo gemacht. Dort konnten wir kostenlos über Nacht laden, allerdings "nur" an einer normalen Steckdose in der Garage. Das Hotel (Aroma Dryos) kann ich sehr empfehlen, da der Inhaber sich sehr für Elektromobilität interessiert. Allerdings solltet ihr am besten vorher ankündigen, dass ihr laden wollt, da die Garage recht eng ist.
Am nächsten Morgen ging es weiter zur Fähre in Kavala. Dazu haben wir noch einen Stopp am Schnellader der Avin Tankstelle an der Raststätte kurz vor Thessaloniki (https://www.goingelectric.de/stromtanks ... -A2/58816/). Das hat auch problemlos funktioniert. Es ist nur etwas ungewöhnlich, dass die Ladung am Schalter gestartet werden muss. Als ich jedoch mit dem Elektroauto vor der Ladestation stand, waren direkt alle sehr interessiert und die Chefin hat direkt alle in Bewegung gesetzt um die Pylonen wegzustellen, mich einzuweisen und die Ladung zu starten. Also alles sehr vorbildlich.
Von da aus kamen wir dann relativ entspannt bis Kavala, mussten dort jedoch noch ein wenig laden, damit wir unser endgültiges Ziel auf Thassos mit einem guten Puffer erreichen konnten. In Kavala war es wieder etwas schwieriger eine Ladestation zu finden, da diese nur an Hotels waren. Allerdings gab es zumindest eine öffentlich zugängliche vor einem Hotel am Stadtrand (Egnatia City Hotel & Spa). Wir mussten uns zwar in der App registrieren und die Freischaltung der Station war etwas zickig, aber zu unserer Überraschung war der Ladevorgang sogar kostenlos.
Danach ging es mit der Fähre nach Thassos. Dort hatten wir als Ziel den Ort Potos auf der anderen Seite der Insel. Insgesamt ist die Ladesituation auf der Insel eher schlecht. Es gibt keine öffentlichen Ladestationen und die Stadtverwaltung hat mir leider auch nicht auf meine Anfrage geantwortet. Die meisten Ladestationen befinden sich in Hotels und sind häufig nur für Gäste gedacht. Am Alexandra Beach Hotel in Potos ist meines Wissens nach die einzige Ladestation die auch nicht Gäste nutzen können, wenn sie bspw. im Restaurant essen o.ä. Wir konnten allerdings zum Glück an unserem Ferienhaus (Scandia Villas) laden, sodass wir über den gesamten Zeitraum (Mitte Juni bis Ende September) immer gut mit Strom versorgt waren. Ich denke, dass es grundsätzlich kein Problem ist, an der Unterkunft zu laden, sofern eine Steckdose verfügbar ist. Die meisten Griechen, mit denen wir gesprochen haben, waren sehr interessiert was das Elektroauto anging und haben viele Fragen zu Reichweite, Ladedauer und Ladekosten gestellt. Von daher im Zweifelsfall einfach vor der Buchung anfragen, ob ihr dort Laden könnt. Wir haben am Ende unseren Aufenthalts einen kleinen Extra-Betrag für den zusätzlichen Verbrauch bezahlt, was ich durchaus fair fand und immer noch deutlich günstiger war, als der Haushaltsstrom in Deutschland.

Auf der Rückfahrt sind wir mit 100% von der Insel gestartet und sind dementsprechend relativ entspannt in Thessaloniki angekommen, wo wir noch zwei Tage verbringen wollten.
Anschließend haben wir auf dem Weg zur Fähre in Igoumenitsa noch einmal am Schnelllader bei Ioannina (https://www.goingelectric.de/stromtanks ... ina/40203/) geladen.
In Igoumenitsa gibt es zwar auch ein paar Ladestationen am Hafen, aber leider konnte uns dort niemand sagen, wie diese freigeschaltet werden. Unsere Frage beim Kiosk führte uns bis zur örtlichen Polizeistation, wo einer der freundlichen Beamten sogar noch ein wenig rumtelefoniert hat, aufgrund der Uhrzeit aber leider niemanden mehr erreichen konnte. Zum Glück hatten wir aufgrund des Ladestopps bei Ioannina noch genug Ladung im Akku um in Italien weiterzukommen. Möglicherweise werden die Stationen nächstes Jahr freigeschaltet, da sie noch sehr neu aussahen und vermutlich noch nicht eingerichtet waren.

Fazit

Insgesamt hat es bei uns gut geklappt. Vor allem durch den relativ großen Akku des Kona kamen wir gut durch. Zudem haben wir zu Beginn auch ziemlich konservativ geplant, da das Auto noch neu für uns war und zudem ziemlich schwer beladen war. Zudem ist der Verbrauch insgesamt geringer, da man aufgrund der Straßenverhältnisse und Geschwindigkeitsbegrenzungen in der Regel eine geringere Durchschnittsgeschwindigkeit hat als in Deutschland.
Es bleibt also zu sagen, dass Griechenland mit dem Elektroauto gut möglich ist, allerdings sollte vor der Fahrt doch ein wenig geplant werden und ggf. schon die entsprechenden Accounts bei den Ladeanbietern erstellt werden, um Überraschungen zu vermeiden. Außerdem war uns die PlugShare App eine große Hilfe.

Wenn ihr noch weitere Fragen habt, könnt ihr euch natürlich gern melden. Dann werde ich auch hoffentlich deutlich schneller antworten als jetzt.

Viele Grüße

David