DDNS auf VServer installieren

[rmurp]

Hallo Forum,

nachdem nun DynDNS.org angekündigt hat den kostenlosen Dienst einzustellen, bin ich auf die Idee gekommen dies über meinen VServer selbst einzurichten.

Ich habe bei einem Hoster einen VServer mit Debian laufen und kann diesen unter mydomain.de erreichen. Jetzt möchte ich unter einer Sub-Domain eine Verbindung mit zuhause aufbauen können (z.B. home.mydomain.de).
Mein Router zuhause soll bei wechseln der IP-Adresse sich auf meinen VServer anmelden und die neue IP mitteilen.

Geht das überhaupt?

Danke

Ron

[Cae]

Du musst beachten, dass z.B. die DENIC authorative Domains nur dann erlaubt, wenn du mindestens zwei zuverlaessige DNS-Server in unterschiedlichen Netzen hast. Sprich, du kannst zwar statisch eine Domain example.org bei deinem Hoster/Domainverwalter einstellen, und auch home.example.org, aber du kannst nicht sagen "hey, alle Anfragen zu example.org sollen an meinen Server 192.0.2.42 delegiert werden" (damit du auf dem dortigen, unter deiner Kontrolle befindlichen DNS-Server entscheiden kannst, wohin home.example.org aufloesen soll).

Was dagegen funktionieren kann: Falls dein Domainverwalter ein API anbietet, mit der du Records aendern kannst, koenntest du home.example.org auf diesem Wege updaten lassen. Eventuell mit einem gefakten DDNS-Server auf 192.0.2.42, der die neue IP vom Router zuhause entgegennimmt und das API bespasst, worauf home.example.org auf die externe IP von deinem Router zeigt. Oder es gibt im LAN zuhause ohnehin eine Maschine, die direkt mit dem API sprechen koennte.

Eine andere Methode waere noch, dass du home.example.org statisch ebenfalls auf 192.0.2.42 legst und saemtliche "interessanten" Verbindungen transparent zu dir nach Hause schickst. Das kann relativ einfach per DNAT in der Firewall geschehen (wodurch allerdings die wahre IP-Adresse des Verbindungspartners durch 192.0.2.42 ersetzt wird) oder etwas komplexer per VPN-Tunnel. Die DNAT-Regel laesst sich relativ unspektakulaer per ssh plus Keyfile umsetzen (verlangt allerdings aehnlich wie die "API von zuhause"-Variante z.B. eine Shell/Crontab auf dem Router oder eine andere lokale Maschine).

Gruss Cae

[rendegast]

Im Netz stehen jedoch zahlreiche Alternativen wie Afraid.org, NoIP, spdns.de oder TwoDNS bereit, die gegen geringe Gebühren oder kostenlos die gleiche Aufgabe übernehmen
...
Selfhost.de (kostenlos oder ab 1,50 Euro/Monat)
Feste-ip.net (5 Euro/Jahr); Funktioniert laut FAQ auch mit Geräten, auf deren ein DynDNS-Anbieter vorgegeben ist.
Individual Network Berlin e.V., DynDNS-Dienst für Mitglieder und Teilnehmer (siehe Wiki)

ipv6?

[Meillo]

Du musst beachten, dass z.B. die DENIC authorative Domains nur dann erlaubt, wenn du mindestens zwei zuverlaessige DNS-Server in unterschiedlichen Netzen hast. Sprich, du kannst zwar statisch eine Domain example.org bei deinem Hoster/Domainverwalter einstellen, und auch home.example.org, aber du kannst nicht sagen "hey, alle Anfragen zu example.org sollen an meinen Server 192.0.2.42 delegiert werden" (damit du auf dem dortigen, unter deiner Kontrolle befindlichen DNS-Server entscheiden kannst, wohin home.example.org aufloesen soll).

Du musst dazu deinen eigenen Server fuer example.org oder eine Subdomain verantwortlich machen, also einen eigenen Nameserver betreiben. Den zweiten (notwendigen!) Nameserver stellt evtl. dein Serverprovider zur Verfuegung. Dieser kann dann automatisch synchronisiert werden. Nachteil: Du musst dann einen Nameserver administrieren und der sollte besser nicht ausfallen.

Was dagegen funktionieren kann: Falls dein Domainverwalter ein API anbietet, mit der du Records aendern kannst, koenntest du home.example.org auf diesem Wege updaten lassen. Eventuell mit einem gefakten DDNS-Server auf 192.0.2.42, der die neue IP vom Router zuhause entgegennimmt und das API bespasst, worauf home.example.org auf die externe IP von deinem Router zeigt. Oder es gibt im LAN zuhause ohnehin eine Maschine, die direkt mit dem API sprechen koennte.

Gute Idee. Gibt es Domainverwalter die solch eine API anbieten?

Eine andere Methode waere noch, dass du home.example.org statisch ebenfalls auf 192.0.2.42 legst und saemtliche "interessanten" Verbindungen transparent zu dir nach Hause schickst. Das kann relativ einfach per DNAT in der Firewall geschehen (wodurch allerdings die wahre IP-Adresse des Verbindungspartners durch 192.0.2.42 ersetzt wird) oder etwas komplexer per VPN-Tunnel. Die DNAT-Regel laesst sich relativ unspektakulaer per ssh plus Keyfile umsetzen (verlangt allerdings aehnlich wie die "API von zuhause"-Variante z.B. eine Shell/Crontab auf dem Router oder eine andere lokale Maschine).

Das hoert sich fuer mich sehr sinnvoll an. Nun nochmal zum Verstaendnis:

Auf meinem Homeserver lege ich einen Cronjob an, der sich via ssh mit Key Authentication auf dem oeffentlich erreichbaren Server (hier 205.254.211.17) einloggt und dort folgende Befehle mit der aktuellen dynamischen IP-Adresse (hier 130.120.110.99) periodisch neu eintraegt:

Code: Alles auswählen

[root@real-server]# iptables -t nat -A PREROUTING -d 205.254.211.17 -j DNAT --to-destination 130.120.110.99
[root@real-server]# iptables -t nat -A POSTROUTING -s 192.168.100.17 -j SNAT --to-destination 130.120.110.99

(von http://linux-ip.net/html/nat-dnat.html )

(Muss ich die vorigen Routen noch rausloeschen oder werden die automatisch ueberschrieben?)

Das hoert sich ja einfach und unkompliziert an im Vergleich zum eigenen Betrieb eines Nameservers. Seltsam, dass ich diesen Ansatz hier zum ersten Mal lese, den Ansatz mit dem eigenen Betrieb eines Nameservers aber schon vielfach gehoert habe. Wie wenn es alltaeglich waere einen Nameserver zu betreiben ...

[ThorstenS]

Ich hab mir vor Jahren bei Hetzner einen Zugang zum domain-robot ( https://robot.your-server.de/ ) gekauft.
Den primären DNS Server betreibe ich selbst, den Dienst des secondary kaufe ich bei Hetzner ein.
Dann reicht mir ein kleines Script, damit sich der Heim-Rechner im DNS per dnssec registriert:

Code: Alles auswählen

HORST=$(hostname)
_IP=$(wget -q http://ip.example.com -O - || exit 1)
_OLDIP=$(dig +short A $HORST.example.com)
_OLDIP=${_OLDIP:-127.0.0.1}

function NSupdate {
        nsupdate -k /etc/ksan//dnsupdate/Knsup.example.com.+157+35682.key
}

if [ "$_IP" == "$_OLDIP" ]; then
        # IPs sind identisch
        :
else
        # IPs sind nicht identisch - Neueinwahl
        echo -e "update delete $HORST.example.com\nsend" | NSupdate
        echo -e "update add $HORST.example.com 60 IN A $_IP\nsend" | NSupdate
        echo -e "update add $HORST.example.com 60 TXT $(date --utc "+%Y-%m-%d-%H%M-UTC")\nsend" | NSupdate
        echo -e "update add $HORST.example.com 86400 MX 50 mx0.example.com\nsend" | NSupdate
fi 

Der „Dienst“ hinter ip.example.com ist recht trivial:

Code: Alles auswählen

<?php echo $_SERVER['REMOTE_ADDR'];?>

[Cae]

Was dagegen funktionieren kann: Falls dein Domainverwalter ein API anbietet, mit der du Records aendern kannst, koenntest du home.example.org auf diesem Wege updaten lassen. Eventuell mit einem gefakten DDNS-Server auf 192.0.2.42, der die neue IP vom Router zuhause entgegennimmt und das API bespasst, worauf home.example.org auf die externe IP von deinem Router zeigt. Oder es gibt im LAN zuhause ohnehin eine Maschine, die direkt mit dem API sprechen koennte.

Gute Idee. Gibt es Domainverwalter die solch eine API anbieten?

Bei Regfish hab' ich sowas gesehen, aber nicht ausprobiert.

Eine andere Methode waere noch, dass du home.example.org statisch ebenfalls auf 192.0.2.42 legst und saemtliche "interessanten" Verbindungen transparent zu dir nach Hause schickst. Das kann relativ einfach per DNAT in der Firewall geschehen (wodurch allerdings die wahre IP-Adresse des Verbindungspartners durch 192.0.2.42 ersetzt wird) oder etwas komplexer per VPN-Tunnel. Die DNAT-Regel laesst sich relativ unspektakulaer per ssh plus Keyfile umsetzen (verlangt allerdings aehnlich wie die "API von zuhause"-Variante z.B. eine Shell/Crontab auf dem Router oder eine andere lokale Maschine).

Das hoert sich fuer mich sehr sinnvoll an. Nun nochmal zum Verstaendnis:

Auf meinem Homeserver lege ich einen Cronjob an, der sich via ssh mit Key Authentication auf dem oeffentlich erreichbaren Server (hier 205.254.211.17) einloggt und dort folgende Befehle mit der aktuellen dynamischen IP-Adresse (hier 130.120.110.99) periodisch neu eintraegt:

Code: Alles auswählen

[root@real-server]# iptables -t nat -A PREROUTING -d 205.254.211.17 -j DNAT --to-destination 130.120.110.99
[root@real-server]# iptables -t nat -A POSTROUTING -s 192.168.100.17 -j SNAT --to-destination 130.120.110.99

(von http://linux-ip.net/html/nat-dnat.html )

(Muss ich die vorigen Routen noch rausloeschen oder werden die automatisch ueberschrieben?)

Ich hab' dazu einfach 'ne eigene Kette genommen, die vom Update-Client immer komplett geleert wird. Ein SNAT braucht's hier nicht, weil ich keine Dienste mit kaputtem Protokoll wie aktives FTP oder SIP drueber laufen lasse. Die Sitzungen werde immer vom Client initiiert, von example.org (sei der Host im Internet mit home.example.org drauf) auf die eigene IP umgeschrieben und an die eingetragene IP des Update-Clients geschickt.

Ausschnitt vom Haupt-Firewallskript:

Code: Alles auswählen

iptables -t nat -N fwd

iptables -t nat -A PREROUTING -m state --state NEW -p tcp --dport 1234 -j fwd
iptables -t nat -A PREROUTING -m state --state NEW -p tcp --dport 1235 -j fwd # and so on

/root/.ssh/authorized_keys von example.org:

Code: Alles auswählen

command="/root/update-forwarding", ssh-rsa {pub-key vom Client}...

/root/update-forwarding von example.org:

Code: Alles auswählen

#!/bin/sh
set -e

newip="${SSH_CONNECTION%% *}"

case "$newip" in
*.*.*.*)
        iptables -t nat -F fwd
        iptables -t nat -A fwd -m state --state NEW -p tcp --dport 1234 -j DNAT --to-destination "$newip";
        iptables -t nat -A fwd -m state --state NEW -p tcp --dport 1235 -j DNAT --to-destination "$newip"; # and so on...
        printf "forwarding set to '%s'\n" "$newip";
        exit 0;
        ;;
esac

printf "failed."
exit 1;

(eigentlich braucht man --dport nicht nochmal, weil in die Kette ohnehin keine anderen Pakete gekommen sein sollten. Es schadet allerdings nicht und erinnert daran, was da alles umgeleitet wird.) Weil man sich drauf verlassen kann, dass der erste Block in $SSH_CONNECTION die Client-IP enthaelt, kann der Client auch gar nix sonst an der Firewall kaputtspielen (oder am Rest vom System, da befehlsgebundener SSH-Key).
Crontab:

Code: Alles auswählen

10 3 * * * ssh -i /home/foobar/update-forward-id_rsa root@example.org

Bis auf den erwaehnten Nachteil, dass man auf home.example.org nicht weiss, welcher Client eigentlich anfragt, sind mir noch keine Probleme aufgefallen. Allerdings hat man dadurch auch den Vorteil, dass ein Client nicht herausfindet, wohin er weitergeleitet wurde.

Ich seh' gerade, das ist jetzt doch eine Menge Text geworden, vielleicht eignet sich eine Wiki-Seite zum Thema besser.

Gruss Cae