Seite wählen

NETWAYS Blog

Wireguard mit dynamischen DNS Namen

Seit einiger Zeit bin ich großer Fan von Wireguard als VPN Lösung um meine Server und Notebooks zu verbinden. Auch Patrick hatte schon mal über DNS Privacy mit Wireguard geschrieben.

Dabei ist mir ein kleines Problem begegnet, Wireguard hat kein automatisches Handling wenn sich Endpoint Adressen über DNS ändern. In meinem Fall verbinde ich:

  • Server im Rechenzentrum mit fester IP Adresse
  • Notebook irgendwo unterwegs, muss sich zu allen anderen Verbinden
  • Server zuhause, Verbindung nur über DynDNS möglich

Auf dem Bild kann man in etwa die aufgebauten Verbindungen erkennen, nun besteht das Hauptproblem darin, dass der Server zuhause nur über die Auflösung des dynamischen DNS Namens erreichbar ist. Wireguard löst DNS Namen nur beim laden der Konfiguration auf. Sollte sich die IP Adresse ändern funktioniert die Verbindung nicht mehr.

Ein Beispiel meiner Konfiguration:

[Interface]
# Notebook
Address = 10.99.0.3/24
PrivateKey = BASE64
ListenPort = 51820

[Peer]
# Server at home
PublicKey = BASE64
AllowedIPs = 10.99.0.1/32
Endpoint = home.example.com:51820

[Peer]
# hosted VM
PublicKey = BASE64
AllowedIPs = 10.99.0.2/32
Endpoint = server.example.com:51820

#[Peer]
## Notebook Entry on other nodes
#PublicKey = BASE64
#AllowedIPs = 10.99.0.3/32
## No endpoint defined for this peer

Nachdem Wireguard noch keine eingebaute Lösung dafür hat, braucht man ein Script, welches DNS Namen neu auflöst und dann anwendet. Ich verwende das Beispielskript reresolve-dns.sh aus den contrib Skripten.

Die Installation ist relativ einfach:

curl -LsS -o /usr/local/bin/wireguard-reresolve-dns https://github.com/WireGuard/wireguard-tools/raw/master/contrib/reresolve-dns/reresolve-dns.sh
chmod 0755 /usr/local/bin/wireguard-reresolve-dns

Im Anschluss kann das Skript manuell oder per Cron (als root) ausgeführt werden:

wireguard-reresolve-dns wg0

Oder was ich bevorzuge, als Systemd Service und Timer wie folgt.

/etc/systemd/system/wireguard-reresolve-dns.service

[Unit]
Description=Wireguard Re-Resolve DNS of endpoints

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wireguard-reresolve-dns wg0

/etc/systemd/system/wireguard-reresolve-dns.timer

[Unit]
Description=Runs Wireguard Re-Resolve DNS every 5 Minutes

[Timer]
OnUnitActiveSec=300s
OnActiveSec=300s

[Install]
WantedBy=multi-user.target

Anschließend muss man den Timer nur aktivieren und kann den Status des Service jederzeit checken:

# systemctl daemon-reload
# systemctl enable wireguard-reresolve-dns.timer
# systemctl status wireguard-reresolve-dns.timer
* wireguard-reresolve-dns.timer - Runs Wireguard Re-Resolve DNS every 5 Minutes
Loaded: loaded (/etc/systemd/system/wireguard-reresolve-dns.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Thu 2021-12-30 15:40:09 CET; 6 days ago
Trigger: Wed 2022-01-05 15:50:48 CET; 3min 1s left
Triggers: * wireguard-reresolve-dns.service

Dec 30 15:40:09 notebook systemd[1]: Started Runs Wireguard Re-Resolve DNS every 5 Minutes.

# systemctl status wireguard-reresolve-dns.service
* wireguard-reresolve-dns.service - Wireguard Re-Resolve DNS of endpoints
Loaded: loaded (/etc/systemd/system/wireguard-reresolve-dns.service; static)
Active: inactive (dead) since Wed 2022-01-05 15:45:48 CET; 2min 1s ago
TriggeredBy: * wireguard-reresolve-dns.timer
Process: 3600033 ExecStart=/usr/local/bin/wireguard-reresolve-dns wg0 (code=exited, status=0/SUCCESS)
Main PID: 3600033 (code=exited, status=0/SUCCESS)
CPU: 17ms

Jan 05 15:45:48 notebook systemd[1]: Starting Wireguard Re-Resolve DNS of endpoints...
Jan 05 15:45:48 notebook systemd[1]: wireguard-reresolve-dns.service: Succeeded.
Jan 05 15:45:48 notebook systemd[1]: Finished Wireguard Re-Resolve DNS of endpoints.

Ich wünsche viel Spaß beim Ausprobieren.

Wer gerne automatisiert, dem kann ich die Ansible Rolle von githubixx empfehlen, so spart man sich das müssige Erstellen und Verteilen von Keys. Leider habe ich noch keine fertige Rolle für reresolve DNS. 😉️

VPN-Einrichtung leicht gemacht

Ziel des IT Service Managements ist es, Nutzer*innen durch automatisierte Prozesse möglichst viel Arbeit abzunehmen. NETWAYS hat bereits vor geraumer Zeit auf die aktuelle Corona-Situation reagiert und alle Mitarbeitenden ins Home Office geschickt.

Um auch Zuhause weiterhin auf firmeninterne Adressen zugreifen zu können, ist ein VPN (Virtuelles Privates Netzwerk) nötig und die Mehrheit nutzt eine „openVPN“-Lösung, welche aufgrund unserer Netzgegebenheiten aber weniger leistungsstark, als ein „L2TP“ abschneiden kann. Um den Kolleg*innen den Umstieg von openVPN auf L2TP zu erleichtern, haben wir es uns zum Ziel gesetzt, einen automatisierten Ablauf zu schaffen, welcher dem*r User*in im Grunde genommen ermöglicht, den VPN-Zugang lediglich per „Knopfdruck“ auf dem eigenen Windows-Gerät zu installieren.

 

Die Umsetzung

Da wir uns auf einer Windows-Plattform bewegen, stand außer Frage, dass ein Powershell-Script benötigt wird, um unsere VPN-Verbindung in das System einzubinden. Microsoft bietet unter “docs.microsoft.com” eine wundervolle Dokumentation zum Thema Powershell an. Unter anderem kann man dort nach einzelnen “tags” suchen und sich die dazu passenden Funktionen samt Syntax anzeigen lassen. Und so habe ich nach kurzer Suche die Funktion “Add-VpnConnection” gefunden!

Schnell wurde mir klar, dass ich fast mein gesamtes Konzept in einer Zeile Powershell umsetzen konnte. Es ist möglich, die Funktion mit verschiedensten Parametern zu beeinflussen. Man kann zum Beispiel den Namen, Typ des VPNs, einen Pre-Shared-Key (PSK) und noch vieles mehr einbinden. Eine besondere Erwähnung meinerseits erhält an dieser Stelle der Parameter “-SplitTunneling”, welcher erlaubt, das VPN nur dann zu nutzen, wenn die Netzwerkressourcen auch wirklich benötigt werden. Beim Verbinden zu nicht-internen Internetdiensten werden die Standardrouten des Clients und Providers genutzt. Dieses Feature war für mich bei der herkömmlichen Einrichtung eines VPNs, unter der grafischen Oberfläche von Windows, nicht ersichtlich. Nachdem man die einzelnen Routen in das Script mit aufgenommen hat, funktioniert das Ganze auch problemlos.

 

Die Herausforderung

Nachdem ich das VPN Script getestet hatte und die Einrichtung ohne Hindernisse funktionierte, stellten sich mir zwei Fragen: Wie meldet sich der*die Endbenutzer*in mit seinem AD-Account in dem VPN an und wie lässt sich ein Powershellscript ausführen ohne Powershell nutzen zu müssen?

Das Problem mit dem User-Login löste sich beim Probieren von selbst: Sobald das VPN installiert ist und der*die Nutzer*in auf “Verbinden” drückt, startet Windows eine Benutzer/Passwortabfrage. Wenn man in der Funktion noch den Parameter “-RememberCredential“ implementiert hat, werden die eingegebenen Daten automatisch gespeichert und aus dem Cache entnommen.

Bei dem Ausführen der .ps1 Powershell-Datei gab es für mich nun zwei Möglichkeiten: Es gibt eine Vielzahl an Konvertern, die eine .ps1-Datei in ein .exe Format umwandeln. Dabei könnte die Datei aber durch eventuelle Fremdsysteme laufen. Da ich einen PSK zur Authentifizierung in das Script eingebunden habe, entschied ich mich gegen diese Lösung. Dafür fiel meine Wahl auf die zweite Option, nämlich eine Batch-Datei (.bat) anzulegen, mit der man die .ps1 in Powershell ausführt.

 

In der .bat-Datei selbst befinden sich drei Komponenten

Der Pfad zu Powershell, in dem unsere Datei ausgeführt werden soll:

  • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Ein Kommando zum Ausführen:

  • executionpolicy bypass

Und dieser kryptische Name:

  • %~dp0%~n0.ps1

 

Diese Bezeichnung macht das Batch-Script zu einem dynamischen Script, welches, unabhängig von Location, ausgeführt werden kann ohne im eigentlichen Script etwas ändern zu müssen.

Wir haben zwei Batch-Variablen, die wir uns dafür zu Nutze machen. Mit “%~dp0 “ sucht man im aktuellen Pfad, in welchem die Batch ausgeführt wurde, nach dem Namen, den die Batch-Datei trägt (“%~n0”) . Da ich aber nicht die Batch-Datei selber öffnen möchte, nutze ich das “.ps1 “ Anhängsel unserer Powershell-Datei.

# Batch-Script zum Ausführen
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass %~dp0%~n0.ps1

Und damit kommen wir zu den Voraussetzungen, die erfüllt sein müssen, damit die Batch- und Powershell-Datei funktionieren: Beide müssen denselben Namen tragen und sich im selben Verzeichnis befinden!

Fast geschafft! Am Ende lässt sich das Script einfach ausführen und kann – ohne weitere Eingaben in die Powershell/CMD – den VPN-Zugang anlegen. Die beiden Dateien müssten sich – wie oben beschrieben – nur im selben Pfad befinden und die Batch-Datei ausgeführt werden.

 

Das Script

#Add VPN

Add-VpnConnection -Name "L2TP-VPN" -Server_Address "Server_adresse" -TunnelType "L2tp" -EncryptionLevel "Required" -L2tpPsk "Generic_Key" -Force -RememberCredential -PassThru

#Setting Name
$MyVPNName = "L2TP-VPN"

#Call VPN via Name + SplitTunneling
Set-VpnConnection -Name $MyVPNName -SplitTunneling $TRUE;

#Routes
Add-VpnConnectionRoute -ConnectionName $MyVPNName -PassThru -DestinationPrefix IP.IP.IP.IP/Netzanteil #Beispiel-Route
André Paskowski
André Paskowski
Systems Engineer

Als Fachinformatiker für Systemintegration bei NETWAYS kann André seine Leidenschaft für Technologie voll ausleben. Vor seiner Ausbildung hat er bereits im sozialen Bereich gearbeitet und dort wertvolle Erfahrungen gesammelt. Sein beruflicher Werdegang hat ihn nicht davon abgehalten, seine großen Leidenschaften neben der Arbeit zu verfolgen: Als begeisterter Gamer findet André Entspannung und Herausforderung in virtuellen Welten, während er sich in seiner restlichen Freizeit gerne in strategischen Tabletop-Spielen verliert. Aber seine Interessen beschränken sich nicht nur auf digitale und physische Spiele. Als stolzer Besitzer von Reptilien als Haustieren ist er fasziniert von der exotischen Tierwelt und investiert viel Zeit und Sorgfalt...

NETWAYS Cloud: Sichere Tunnel mit VPNaaS

Wenn eigentlich nur intern genutzte Systeme in die Cloud transferiert werden, kommt man fast zwangsläufig auf das Thema VPN. Die sichere und verschlüsselte Kommunikation zwischen dem firmeninternen Netz und dem Cloudanbieter ist unerlässlich. Darüber hinaus können auf diese Weise zwei Netzwerke sicher miteinander verbunden werden, so dass dies für den Anwender im Firmennetzwerk völlig intransparent ist. Alle Anwendungen fühlen sich an, also ob sie noch im eigenen Netzwerk laufen würden.

Wir bieten in der NETWAYS Cloud VPNaaS (VPN as a Service) und somit kann man bei uns leicht im Self-Service (Weboberfläche) einen VPN-Tunnel zu seinen virtuellen Maschinen, die nur intern erreichbar sein sollen, aufbauen. Du brauchst dafür niemanden anrufen oder einem Service-Provider ein Ticket erstellen, sondern du bedienst dich einfach selbst und erstellst einen sicheren VPN-Tunnel.

Warum will ich das haben?
Dein Mehrwert besteht vor allem in der einfachen und schnellen Bereitstellung, der Zuverlässigkeit von OpenStack und den niedrigen Kosten – bei uns läuft die Abrechnung nur nach Verbrauch!

Wer ist die Zielgruppe?
Kunden, die ihre(n) Standort(e), die Produktion oder ganz allgemein ein internes Netzwerk mit Services, die bei NETWAYS gehostet sind, sicher verbinden möchten.

Bekomme ich auch Unterstützung?
Natürlich, unsere Kollegen stehen als MyEngineer jederzeit als helfende Hand zur Verfügung. Nimm einfach Kontakt mit uns auf oder melde dich direkt in den NETWAYS Cloud an.

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Ihre Server schwitzen? AKCP sensorProbe 2+

AKCP-SP2plus
Ich gebe zu: Die AKCP sensorProbe 2+ wird Ihre Server nicht vom Schwitzen abhalten. Dafür vielleicht Ihre KollegInnen, die genannte Server beaufsichtigen und für ihre Sicherheit zuständig sind. Durch das Thermal Mapping kann nämlich jetzt noch viel gezielter überwacht werden (siehe Skizze weiter unten). Aber von vorne: In unserem Online-Store spielen die Umweltmonitore von AKCP schon immer eine bedeutende Rolle. Versehen mit einer exzellenten Qualität, begeistert diese Monitoringhardware unsere Kunden schon sehr lange Jahre.
Die AKCP sensorProbe2 wurde komplett überarbeitet und nennt ihre Nachfolgerin nun sensorProbe2+. Alle bekannten Features blieben erhalten und auch die Kompatibilität mit allen Sensoren der sensorProbe-Reihe bleibt gegeben.
Jetzt kann auch endlich ein GSM-Modem direkt integriert werden, wobei dies bei der Erstbestellung der AKCP sensorProbe2+ zwingend mit angegeben werden muss. Ein Nachrüsten ist leider nicht möglich. Außerdem sind bei allen Geräten der AKCP sensorProbe2+– Reihe die VPN Funktion und ein Upgrade auf SNMPv3 optional bestellbar. Neuheit: Bei der E-Mail-Alarmierung wird nun auf TLS-Verschlüsselung gesetzt, die es bislang nur bei den securityProbes gab.
Zusätzlich zu den bekannten RJ45-Sensoren, von denen bei der AKCP SP2+ insgesamt 4 angeschlossen werden können (Vorgängerin SP2 konnte nur 2 verarbeiten), können auch bis zu 20 potentialfreie Kontakte genutzt werden. Für den Anschluss der potentialfreien Kontakte ist sowohl der Kauf des Sensors: Inputs für potentialfreie Kontakte (5 potentialfreie Kontakte) als auch eine Lizenz, die jeweils für 5 potentialfreie Kontakte gilt, erforderlich.
Technische Daten AKCP sensorProbe2+

  • Anschlüsse: 4 RJ45 Ports, für sämtliche AKCP-Sensoren der sensorProbe-Reihe, bis zu 20 potentialfreie Kontakte (über speziellen Sensor + Lizenz)
  • Maße/Gewicht: (ca. BxHxT in cm) 11,5 x 6,35 x 3,2/ 0,3 kg
  • GSM-Modem: optional, inklusive externer Antenne
  • sensorProbe2+ Expansion: mit Expansion Unit für bis zu 100 Sensoren
  • Stromversorgung: 12 VDC, 1 Amp; inkl Modem: 12 VDC, 2 Amp
  • Arbeitsumgebung: Temperatur: -35 bis +80 C / Luftfeuchte: 20 bis 80 % (ohne Kondensation)

Intelligente Erweiterung: AKCP sensorProbe2+ Expansion
Sie wollen mehr als 4 Sensoren anschließen? Gerne doch! Bei der AKCP sensorProbe2+ Expansion kann einer der 4 RJ45 Ports dazu genutzt werden, die von der AKCP securityProbe Reihe bekannten Expansion Units anzuschließen. Somit kann eine Erweiterung um 8 Ports und/oder die Erweiterung um 16 potentialfreie Kontakte vollzogen werden. Im Daisy Chain Verfahren können somit bis zu 100 Sensoren angeschlossen werden. Ausnahme: Die o.g. VPN Funktion wurde zusätzlich eThermal Map Sensoringekauft. Damit verringert sich die Anzahl der Sensoren auf 50.
Thermal Mapping: Noch genauere Überwachung Ihrer Serverschränke möglich
Kommen wir nochmal auf das Thermal Mapping zu sprechen: Die genauere Auswertung und Erfassung thermischer Bedingungen eines Serverracks wird nun durch den neuen Thermal Map Sensor ermöglicht. Dabei wird der Sensor wie im Schaubild rechts zu sehen, an unterschiedlichen Stellen des Racks positioniert. So können „Hot-Spots“ leicht lokalisiert werden, was ein gezieltes Eingreifen schneller ermöglicht. Hier kann durch effizientes Kühlen an den besonders warmen und kühlen Stellen, bares Geld gespart werden. Der Thermal Map Sensor kann separat gekauft werden, es gibt aber auch ein Bundle in Form der AKCP sensorProbe2+ inkl. Thermal Map Sensor (Temperatur + Luftfeuchte).
 
Also: Auf in den NETWAYS Online Store und noch heute die AKCP sensorProbe 2+ sichern!

Jetzt neu: OpenVPN auf der AKCP SecurityProbe

akcp securityprobe 5e standard
Für alle AKCP SecurityProbes gibt es ab der Firmware 405J jetzt das OpenVPN Feature.
Mittels Wizzards lässt sich die OpenVPN-Verbindung nun im Handumdrehen über das Webinterface einrichten. AKCP setzt bei den Standards auf: peer Authentication, digitale Zertifikate und eine starke Verschlüsselung mit 256 Bit.
Für Anwendungsfälle mit eingeschränkter Bandbreite wie Remote-Monitoring über GSM, wird die Tunnelung von UDP unterstützt.
Die SecurityProbe eignet sich von daher als großer Ableger (mehr Sensoren, mehr Sensorports, ggf. Kameras) gegenüber der Geräte HWgroup Ares und Sequioa Argon. Für den Betrieb via GSM benötigen Sie noch das separate Modem.
Die neue Firmware ist ab sofort auf der AKCP-Website erhältlich.
Fragen? Wir helfen gern. Nehmen Sie doch mit uns Kontakt auf, wir helfen Ihnen sehr gern weiter.