pixel
Seite wählen

NETWAYS Blog

Wireguard mit dynamischen DNS Namen

von | Jan 6, 2022 | ,

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. 😉️

Icinga Plugins in Golang

von | Jul 15, 2021 | , , , ,

Golang ist an sich noch eine relativ junge Programmiersprache, ist jedoch bei vielen Entwicklern und Firmen gut angekommen und ist die Basis von vielen modernen Software Tools, von Docker bis Kubernetes.

Für die Entwicklung von Icinga Plugins bringt die Sprache einige hilfreiche Konzepte mit. Golang baut fertige Binaries, Plugins können also zentral kompiliert und ohne große Abhängigkeiten verteilt werden. Alle Abhängigkeiten werden im Rahmen vom Bauprozess abgedeckt, die einzige Unterscheidung liegt in der Ziel Architektur, also Linux, Windows, Mac oder ähnliches, sowie ob 32 oder 64 bit.

Viele Funktionen und Packages (vergleichbar mit Libraries) kommen entweder direkt mit Golang mit oder können leicht aus der Open Source Community verwendet werden. Mit dem Package go-check von uns haben wir eine kleine Basis geschaffen, um leichter Plugins schreiben zu können, ohne sich zu sehr im Code wiederholen zu müssen.

Als ganz einfaches Go Plugin hier ein Beispiel eine „main.go“ Datei:

package main

import (
	"github.com/NETWAYS/go-check"
)

func main() {
	config := check.NewConfig()
	config.Name = "check_test"
	config.Readme = `Test Plugin`
	config.Version = "1.0.0"

	_ = config.FlagSet.StringP("hostname", "H", "localhost", "Hostname to check")

	config.ParseArguments()

	// Some checking should be done here, when --help is not passed

	check.Exitf(check.OK, "Everything is fine - answer=%d", 42)
}

Alles was man noch tun muss, ist das Plugin zu kompilieren oder direkt auszuführen:

go build -o check_test main.go && ./check_test --help
go run main.go

Ein guter Einstieg in Go findet man über die Dokumentation, die Tour und vor allem in dem man sich umschaut, was die Community an Packages zu bieten hat.

Natürlich bleibt die Frage, wie überwache ich das Ding was mir wichtig ist, wofür es aber noch kein Plugin gibt. Gerade dort helfen wir von NETWAYS mit unseren Consulting und Entwicklungsleistungen.  Beispiele unserer Go Plugins findet man auf GitHub unter der NETWAYS Organisation.

 

Kubernetes: Mehrere Cluster mit kubectl

von | Feb 11, 2021 | ,

Während man mit Kubernetes arbeitet oder entwickelt, wird man in den seltensten Fällen alles auf einem Cluster machen. Ob man ein lokales Minikube verwendet, oder Zugriff auf verschiedene Cluster für Produktion und Testing hat, muss man die Daten ja verwalten, und auswählen in welchem Kontext man gerade arbeitet.

Struktur der Konfiguration

Die Konfiguration für kubectl und andere Kubernetes Clients findet man normalerweise in $HOME/.kube/config. Ich möchte hier ein paar Beispiele zeigen, wie man hier neue Cluster hinzufügen kann. Der Inhalt sieht im einfachsten Fall so aus. Hier sind die Daten bzw. Secrets abgekürzt.

apiVersion: v1
kind: Config
current-context: my-cluster
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://my-cluster:6443
  name: my-cluster
contexts:
- context:
    cluster: my-cluster
    user: admin
  name: my-cluster
users:
- name: admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

Hier sind nun folgende Bereiche wichtig:

  • clusters definiert die bekannten Cluster mit API Endpunkt (URL) und dem passenden CA Zertifikat
  • users definiert Zugangsdaten und Authentifizierungsmechanismen, meistens ein Client Zertifikat, Auth-Tokens oder SSO Daten
  • contexts verbindet Cluster und Authentifizierung, und erlaubt auch das setzen des Namespaces
  • current-context zeigt an welcher Context gerade benutzt wird

Die aktuell verwendete Konfiguration kann man sich bequem anzeigen lassen, und dabei werden dann auch die Detaildaten zensiert – wie oben.

kubectl config view

Andere Konfigurations Dateien

Viele Kubernetes Anbieter stellen direkt die fertige Konfigurationsdatei zur Verfügung, die speichert man entweder direkt unter $HOME/.kube/config oder spezifiziert diese explizit.

kubectl --kubeconfig /tmp/my-config config view

export KUBECONFIG=/tmp/my-config
kubectl config view

Dabei wird nun diese Datei alleine geladen und ist direkt benutzbar. KUBECONFIG gilt dann für alle weiteren Befehle in der Shell auch.

Verbinden der Konfiguration

Um mehrere Dateien zusammenzuführen kann man nun auch mehrere Dateien laden, und so zusammenführen.

cp ~/.kube/config ~/.kube/config.bak
KUBECONFIG=~/.kube/config.bak:/tmp/my-config kubectl config view --raw >~/.kube/config

Bitte unbedingt die Datei vor dem speichern prüfen, doppelte Namen können zu Fehlern führen und der Context wird dann neu gesetzt.

Für kleinere Korrekturen kann man dann auch problemlos die Datei nachträglich von Hand editieren.

Tools und Shell Erweiterungen

Ich nutze gerne die Tools kubectx und kubens um schnell zwischen verschiedenen Kontexten umschalten zu können, bzw. zu sehen mit was ich gerade arbeite. Dazu gibt es auch die praktische Auto-Vervollständigung für die Shell.

Welchen Kontext bzw. Namespace ich gerade nutze, zeigt mir außerdem mein Bash Prompt auch an. Hier am Beispiel von powerline-shell mit meinen Modifikationen.

Es existieren auch einfachere Möglichkeiten, wie die kube-ps1 von jonmosco auf GitHub.

Mehr Infos

Wir bereiten gerade unsere neue Kubernetes Quick Start Schulung vor um den Teilnehmern einen schnellen Einstieg in die Benutzung von Kubernetes zu bringen. Wenn du Interesse hast mehr mit uns in Kubernetes einzusteigen, schau doch mal nach den Terminen.

Das Headerbild stammt von Loik Marras via unsplash.

Computer Viren in der Cloud

von | Sep 18, 2020 | ,

Verschiedene Anbieter von Anti-Virus Produkten bieten mittlerweile SaaS Platformen an um eine zentrale Übersicht über den Status aller Systeme zu bekommen. Dort wird dann neben allen Details eine Übersicht von Alarmen bzw. Bedrohungen verfügbar.

Ein Kunde stellte mich vor die Herausforderung aus diesen Platformen per API die aktuellen Alarme und Probleme abzufragen, daraus sind zwei neue Plugins entstanden.

Hinweis: Wir machen hier keine Werbung für die Produkte, nur unsere Plugins. Wir stehen aktuell in keiner Geschäftsbeziehung zu beiden Anbietern.

mehr lesen…

HP controller firmware issues to check

von | Apr 13, 2020 | ,

Just about a week ago I posted a short blog post introducing a new check to verify firmware of SSD disks by HPE. Since our customer informed us about another bulletin he has to take care of, we extended the check to support RAID controllers, and verify if a problematic firmware needs to be patched.

HPE says about the issue in bulletin a00097210:

HPE Smart Array SR Gen10 Controller Firmware Version 2.65 (or later) provided in the Resolution section of this document is required to prevent a potential data inconsistency on select RAID configurations with Smart Array Gen10 Firmware Version 1.98 through 2.62, based on the following scenarios. HPE strongly recommends performing this upgrade at the customer’s earliest opportunity per the „Action Required“ in the table located in the Resolution section. Neglecting to perform the recommended resolution could result in potential subsequent errors and potential data inconsistency.

Important: Please read the full document and verify with your used hardware.

For controllers, the check will alert you with a CRITICAL when the firmware is in the affected range with:

  • if you have RAID 1/10/ADM – update immediately!
  • if you have RAID 5/6/50/60 – update immediately!

And it will add a short note when firmware older than affected or firmware has been updated. At the moment the plugin does not verify configured logical drives, but we believe you should update in any case.

Please see the repository and README on GitHub for all details, you can download the binaries from releases.

All information about affected disks can be found on GitHub or the previous blogpost.

OK - All 2 controllers and 33 drives seem fine
[OK] controller (0) model=p816i-a serial=XXX firmware=1.65 - firmware older than affected
[OK] controller (4) model=p408e-p serial=XXX firmware=1.65 - firmware older than affected
[OK] (0.9 ) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (0.11) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.12) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.14) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (4.0 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.1 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.2 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.3 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.4 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.5 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.6 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.24) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.25) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.26) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.27) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.28) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.29) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.30) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.31) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.50) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.51) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=7568
...

Trainings

Web Services

Events