Remote-Zugriff auf Netzwerk-Konsolen mit Raspberry Pi & WireGuard – Sicher, schlank und vollständig unter Kontrolle

Warum ich keine fertige Out-of-the-box-Lösung wollte

In unserer Infrastruktur gibt es Geräte, bei denen ein physischer Zugriff auf die Konsole im Notfall überlebenswichtig ist – Core-Router, Firewalls und Switches. Diese Geräte laufen abgeschottet vom Management-Netzwerk, und ich möchte unter gar keinen Umständen, dass jemand über reguläre IP-Netzwerke oder Protokolle auch nur in deren Nähe kommt.

Natürlich gibt es kommerzielle Out-of-Band-Managementlösungen. Aber: 

• Sie setzen häufig auf unzeitgemäße VPNs (z.B. IPsec oder gar OpenVPN),
• guter Remote Zugriff funktioniert meist nur über irgendwelche Hersteller Clouds,
• die Systemarchitektur und Software sind eine Blackbox
• ... und ich habe keine Kontrolle darüber, was die Lösung ins Netzwerk hinein oder heraus kommuniziert.

Mir war klar: Ich brauche etwas Eigenes. Etwas, das ich selbst verstehe, kontrolliere und absichern kann – minimalistisch, stabil und transparent. 

Die Antwort: eine Kombination aus Raspberry Pi, WireGuard, WLAN-Isolation und ser2net. Mit dieser Lösung sind meine Netzwerkgeräte über deren seriellen Konsolenports remote erreichbar – aber nur über mein VPN.

Die Anforderungen

Die Lösung musste:

• nur bei aktiver VPN-Verbindung erreichbar sein
• einen offenen Port im WLAN besitzen
• komplett abgeschottet vom lokalen Netzwerk laufen
• keine fremde Software enthalten, die ich nicht kenne
• jede serielle Schnittstelle eindeutig identifizierbar und zuverlässig zuordenbar machen

Und natürlich: Es soll auch in meinem Monitoring mit Zabbix auftauchen, aber das soll nicht Inhalt dieses Beitrags sein.

Let's jump in: Raspberry Pi als Remote-Konsolen-Server

Ich setze ein aktuelles Raspberry Pi OS Lite ein. SSH und WLAN sind initial deaktiviert.

System vorbereiten und absichern

1. System aktualisieren

#bash
sudo apt update && sudo apt upgrade -y

2. Automatische Sicherheitsupdates aktivieren

#bash
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

‍

3. WLAN einrichten (wenn LAN verwendet wird, natürlich hinfällig)

#bash
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

‍

#CONFIG
country=DE
update_config=1
network={
	ssid="deinSSID"
    psk="deinPasswort"
    key_mgmt=WPA2
}

‍

4. WireGuard einrichten – minimal und sicher

#bash
sudo apt install wireguard resolvconf -y

‍

5. Konfiguration anlegen

#bash
sudo nano /etc/wireguard/wg0.conf

‍

#CONFIG
[Interface]
PrivateKey = <PRIVATE_KEY>
Address = 10.100.100.2/32
DNS = 1.1.1.1‍‍

[Peer]
PublicKey = <SERVER_PUBKEY>
Endpoint = your-vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 10

‍

6. Rechte setzen

#bash
sudo chmod 600 /etc/wireguard/wg0.conf

‍

7. Autostart aktivieren

#bash
sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0

‍

8. iptables & Regeln: Nichts geht ohne VPN rein oder raus (Kill-Switch)

#bash
sudo apt install iptables iptables-persistent -y

‍

#bash
sudo nano /etc/iptables/rules.v4

‍

#CONFIG
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

‍‍

DHCP für WLAN

#CONFIG
-A OUTPUT -o wlan0 -p udp --sport 68 --dport 67 -j ACCEPT
-A INPUT -i wlan0 -p udp --sport 67 --dport 68 -j ACCEPT

‍

Optional - wenn der WG Server keine IP sondern einen DNS Namen hat, auch DNS erlauben

#CONFIG
-A OUTPUT -o wlan0 -p udp --sport 53 --dport 53 -j ACCEPT
-A INPUT -i wlan0 -p udp --sport 53 --dport 53 -j ACCEPT

‍

WireGuard Verbindung erlauben

#CONFIG
-A OUTPUT -o wlan0 -p udp -d <VPN_SERVER_IP> --dport 51820 -j ACCEPT
-A INPUT -i wlan0 -p udp -s <VPN_SERVER_IP> --sport 51820 -j ACCEPT
-A INPUT -i wlan0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

‍

‍Nur VPN-Traffic über WireGuard Interface erlauben

#CONFIG
-A INPUT -i wg0 -j ACCEPT
-A OUTPUT -o wg0 -j ACCEPT‍

COMMIT

‍

#bash
sudo iptables-restore < /etc/iptables/rules.v4
sudo netfilter-persistent save

‍

10. SSH absichern und an WG IP binden, somit kann defacto keine SSH Verbindung über WLAN oder LAN aufgebaut werden.

#bash
sudo nano /etc/ssh/sshd_config

‍

#CONFIG
ListenAddress 10.100.100.2
PasswordAuthentication no
PermitRootLogin no
UseDNS no
PubkeyAuthentication yes
AllowUsers pi

‍

Wichtig!

SSH darf erst starten, wenn WireGuard Online ist, sonst schlägt der Start fehl, da sich SSH nicht an die WireGuard IP binden kann. 

‍

#bash
sudo systemctl edit ssh

‍

#CONFIG
[Unit]
After=wg-quick@wg0.service
Requires=wg-quick@wg0.service

‍

#bash
sudo nano /home/pi/.ssh/authorized_keys
chmod 600 /home/pi/.ssh/authorized_keys
chown pi:pi /home/pi/.ssh/authorized_keys

‍

System Deamon neuladen & SSH neustarten:

#bash
sudo systemctl daemon-reload
sudo systemctl restart ssh

‍

11. Konsolenports konsistent benennen und stabil erkennen mit udev

#bash
sudo nano /etc/udev/rules.d/99-usb-serial.rules

‍

#CONFIG
SUBSYSTEM=="tty", ATTRS{serial}=="A12345B", SYMLINK+="console-router1"
SUBSYSTEM=="tty", ATTRS{serial}=="A12345C", SYMLINK+="console-fw1"

‍

#bash
sudo udevadm control --reload
sudo udevadm trigger

‍

‍

12. ser2net für den Konsolenzugriff installieren und konfigurieren

#bash
sudo apt install ser2net -y

‍

#bash
sudo nano /etc/ser2net.conf

‍

#CONFIG
BANNER:banner:\r\nKonsolenzugriff über Raspberry Pi [\B]\r\n\r\n
2001:telnet:0:/dev/console-router1:115200 8DATABITS NONE 1STOPBIT banner kickolduser telnet-brk-on-sync
2002:telnet:0:/dev/console-fw1:115200 8DATABITS NONE 1STOPBIT banner kickolduser telnet-brk-on-sync

‍

‍

13. ser2net Service Config auf altes Config File Format anpassen

Nicht optimal, ich mag es aber einfach mit schlichten Config-Files, bei denen ich nicht die Anzahl der Leerzeichen zählen muss.

Hier im Service die Config Datei angeben.

‍

#bash
sudo nano /lib/systemd/system/ser2net.service

‍

#CONFIG
[Unit]
Description=ser2net.service - Serial port to network proxy
After=network.target‍

[Service]
ExecStart=/usr/sbin/ser2net -c /etc/ser2net.conf -n
Restart=always‍

[Install]
WantedBy=multi-user.target

‍

System Deamon neuladen & SSH neustarten:

#bash
sudo systemctl daemon-reload
sudo systemctl restart ser2net
sudo systemctl status ser2net

‍

14. Neustart & Test

#bash
sudo reboot

‍

Fazit: Volle Kontrolle, maximale Sicherheit

Diese Lösung ist klein, stabil, sicher und vollständig nachvollziehbar. Keine versteckten Dienste, keine Abhängigkeiten von Drittherstellern. Und vor allem: Sie schützt den Zugang zu meinen kritischsten Systemen – selbst, wenn mein Management-Netz kompromittiert wäre.

Mir persönlich gefällt die Lösung inzwischen so gut, dass ich an einer LTE-Version arbeite, die ich an bestimmte Kunden in besonders kritischen Standorten, zusammen mit unseren Secure-Link SD-WAN Routern ausrolle.

Ich hoffe, dieser etwas andere Blogbeitrag in Form eines Erfahrungsberichts samt DIY-Anleitung hat euch gefallen. 

- Cheers, Jens

‍