Kategorie: Netzwerk

Ubiquiti UniFi Dream Machine Pro (UDM-PRO) – NAT deaktivieren

Ubiquiti Logo

Die Ubiquiti UniFi Dream Machine Pro (UDM-PRO) bietet ein gutes Preis-Leistungs-Verhältnis, weshalb sie oft im Privatgebrauch oder in kleinen Firmen zum Einsatz kommt. Idealerweise wird das Gerät direkt oder über ein Modem mit dem Internet verbunden. Hierfür stehen an der UDM-Pro die beiden WAN-Ports 9 (RJ45) und 10 (SFP) zur Verfügung. Auf beiden Ports ist die Network Address Translation (NAT) standardmäßig aktiviert. Innerhalb der Konfigurationsoberfläche besteht keine Möglichkeit NAT zu deaktivieren.

Falls die UDM-PRO unter bestimmten Voraussetzungen hinter einem Router, z.B. einer FRITZ!Box betrieben werden muss, dann hat man zwangsweise den Nachteil von doppeltem NAT. In vielen Fällen kann dieses Setup ohne weitere Einschränkungen genutzt werden. Doppeltes NAT führt aber oftmals bei Onlinespielen, Xbox, PlayStation und Co zu Problemen. Diese Probleme können jedoch behoben werden, indem die UDM-PRO in der FRITZ!Box als „Exposed Host“ konfiguriert wird. Das doppelte NAT ist dann aber trotzdem noch vorhanden.

Lange Rede kurzer Sinn: In diesem Artikel möchte ich euch zeigen, wie ihr NAT auf den WAN-Ports der UDM-Pro deaktivieren könnt.

SSH aktivieren und verbinden

Zunächst müsst ihr den SSH-Zugang aktivieren und ein Passwort setzen. Dies erfolgt über die Einstellungen der UDM-PRO unter dem Punkt „Adcanced“.

Anschließend könnt ihr euch z.B. mit PuTTY via SSH auf die UDM-PRO verbinden. Der Username ist „root“.

Mit folgendem Befehl können wir die aktuelle NAT-Konfiguration einsehen:

xtables-multi iptables -t nat -L -v --line-number

In der Chain „UBIOS_POSTROUTING_USER_HOOK“ stehen die relevanten Infos:

Chain UBIOS_POSTROUTING_USER_HOOK (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE all -- any eth8 anywhere anywhere /* 00000001095327760591 */
2 0 0 MASQUERADE all -- any eth9 anywhere anywhere /* 00000001095327760592 */

Hier ist ersichtlich, dass auf Port 9 (eth8) und Port 10 (eth9) NAT aktiviert ist.

„UDM / UDMPro Boot Script“ installieren

Voraussetzung für das Deaktivieren von NAT ist das „UDM / UDMPro Boot Script„, welches auch nach einem Neustart oder Firmwareupdate bestehen bleibt.

Für die Installation muss zunächst mit folgendem Befehl in die UnifiOS Shell gewechselt werden.

unifi-os shell

Anschließend wird das Boot Script heruntergeladen und installiert. Am Schluss muss die UnifiOS Shell verlassen werden.

curl -L https://udm-boot.boostchicken.dev -o udm-boot_1.0.4_all.deb
dpkg -i udm-boot_1.0.4_all.deb
exit

NAT deaktivieren

Jetzt könnt ihr eigene Shell Scripte in „/mnt/data/on_boot.d“ hinterlegen, die bei jedem UDM-PRO Start bzw. Reboot ausgeführt werden.

cd /mnt/data/on_boot.d

Dort erstellt ihr euer Skript zur Deaktivierung von NAT:

echo "#!/bin/sh
xtables-multi iptables -t nat -D UBIOS_POSTROUTING_USER_HOOK 2
xtables-multi iptables -t nat -D UBIOS_POSTROUTING_USER_HOOK 1" > ./delete-nat.sh

Dieses muss noch ausführbar gemacht werden:

chmod +x delete-nat.sh

Bei Bedarf könnt ihr das Skript direkt starten und prüfen, ob es funktioniert.

sh delete-nat.sh

Eine Überprüfung mit

xtables-multi iptables -t nat -L -v --line-number

zeigt, dass beide NAT-Regeln entfernt wurden:

Chain UBIOS_POSTROUTING_USER_HOOK (1 references)
num pkts bytes target prot opt in out source destination
Achtung, bei jeder Änderung im Routing oder bei den Firewall-Regeln werden die beiden NAT-Policies wiederhergestellt. Also entweder das Skript danach manuell starten oder die UDM-PRO rebooten.

Statische Route in der FRITZ!Box

Standardmäßig ist das FRITZ!Box Subnetz 192.168.178.0/24 und das Netz der UDM-PRO 192.168.1.0/24.

Damit Clients aus dem UDM-PRO-Subnetz auf das Internet oder die FRITZ!Box zugreifen können, wird noch eine statische Route auf der FRITZ!Box benötigt.

Diese könnt ihr unter „Heimnetz –> Netzwerke –> Netzwerkeinstellungen“ anlegen. Dazu ganz nach unten scrollen und auf den Button „IPv4-Routen“ klicken (siehe Bild).

Dort erstellt ihr eine neue Route und gebt folgende Daten ein:

  • Netzwerk: das Netz der UDM-PRO, standardmäßig 192.168.1.0
  • Subnetzmaske: die Subnetzmaske des vorher eingetragenen Netzes, standardmäßig 255.255.255.0
  • Gateway: die Adresse der UDM-PRO im FRITZ!Box Subnetz, diese kann unter „Heimnetzwerk“ in Erfahrung gebracht werden

Mit Klick auf „Übernehmen“ ist dieser Schritt erledigt.

Optional: Firewall-Regel in der UDM-PRO

Dieser Schritt ist nur notwendig, wenn ihr vom Subnetz der FRITZ!Box auf ein Subnetz „hinter“ der UniFi Dream Machine Pro zugreifen möchtet. Anders herum funktioniert es ohne weitere Konfiguration.

Die Kommunikation wird nämlich noch durch die Firewall der UDM-PRO blockiert. Um dies zu ändern, muss eine neue Regel erstellt werden. Zunächst muss der UniFi Network Controller auf der UDM-PRO geöffnet werden. Anschließend unter „Einstellungen –> Security –> Internet Threat Management –> Firewall“ auf den Button „Create new Rule“ klicken.

Exemplarisch habe ich jeglichen Traffic aus dem Subnetz der FRITZ!Box freigegeben. Sofern möglich solltet ihr die Freigabe jedoch spezifischer gestalten, z.B. auf einzelne IP-Adressen einschränken und nicht ganze Subnetze freigeben.

WireGuard – neues VPN-Protokoll mit großer Zukunft

WireGuard Logo

WireGuard erfreut sich seit geraumer Zeit wachsender Beliebtheit. Hinter WireGuard verbirgt sich sowohl ein VPN-Protokoll, als auch eine VPN-Software. Während es vor zwei Jahren quasi unbekannt war, hat die Bekanntheit in den letzten Monaten stark zugenommen. Grund dafür ist neben der guten Performance und dem schnellen Verbindungsaufbau sicherlich auch die Aufnahme in den stabilen Linux Kernel 5.6, welcher Anfang April 2020 erscheinen dürfte.

Ich selbst bin im Herbst 2019 auf WireGuard gestoßen, als jemand in einem Forum WireGuard vorstellte und als „heißen Scheiß“ bezeichnet hatte. Mittlerweile nutze ich WireGuard seit mehreren Monaten und kann dieser Aussage nur zustimmen :-)

Einleitung

Das VPN-Protokoll WireGuard und die gleichnamige Open Source Software wurden von Jason A. Donenfeld ins Leben gerufen. WireGuard sieht sich selber als extrem einfache, aber dennoch schnelle und moderne VPN-Lösung. Gleichzeitig soll es durch die Nutzung der neuesten Kryptographie-Techniken extrem sicher sein. Im direkten Vergleich mit IPsec und OpenVPN soll es leistungsfähiger, einfacher, schlanker und schneller sein.

Ursprünglich wurde WireGuard nur für den Linux-Kernel entwickelt, ist mittlerweile aber zudem für Windows, macOS, BSD, iOS und Android verfügbar.

Die ersten Snapshots wurden im Juni 2016 veröffentlich. Zwei Jahre später im Juni 2018 wurde der Code und das Protokoll als experimentell bezeichnet und darauf hingewiesen, dass noch kein stabiles Release existiert. Dies trifft bis zum heutigen Tag zu, könnte sich aber bald ändern.

Rund eineinhalb Jahre nach dem Vorschlag von Donenfeld zur Aufnahme in den Hauptzweig ist es nun soweit. Linus Torvalds hat vor wenigen Tagen den Entwicklungszweig Net-Next in den Hauptzweig der Kernel-Entwicklung integriert. Damit wird WireGuard erstmals Teil eines stabilen Linux-Kernels. Der Kernel 5.6 wird für Anfang April erwartet. Grund der langen Verzögerung war der Crypto-Unterbau von WireGuard, welcher einen anderen Ansatz als die Crypto-API des Linux-Kernels verfolgt und deshalb für Unstimmigkeiten gesorgt hatte. Letztlich wurden die neuen Crypto-Funktionen aber im kürzlich veröffentlichten Kernel 5.5 umgesetzt.

Technik

Der Grundgedanke hinter WireGuard ist erfrischend neu und simpel. WireGuard arbeitet ausschließlich auf Schicht 3 des OSI-Modells und ermöglicht die Netzwerkkopplung auf Peer-to-Peer-Basis. Softwareseitig gibt es keine Unterschiede zwischen den Teilnehmern. Alleine die Konfiguration entscheidet, ob ein Peer als Client oder Server arbeitet. Aus diesem Grund sind sogenannte Road-Warrior-Szenarien mit einem zentralen Server und mehreren Clients kein Problem.

Unterstützt wird neben IPv4 auch IPv6. Des Weiteren kann IPv4 in IPv6 getunnelt werden und umgekehrt. Die Verbindung zwischen zwei Peers wird über einen einzelnen, frei wählbaren UDP-Port geregelt. Standardmäßig ist dies UDP-Port 51820.

Zum Verbindungsaufbau wird auf beiden Seiten der VPN-Verbindung lediglich ein Schlüsselpaar benötigt. Der private Schlüssel bleibt dabei lokal, der öffentliche Schlüssel wird der Gegenstelle bekannt gemacht. Auf eine Zertifikat-Infrastruktur kann getrost verzichtet werden. Außerdem kann optional ein symmetrischer Schlüssel (PSK) verwendet werden, der die Verbindung zusätzlich sichert.

Andere VPN-Protokolle unterstützen eine Vielzahl von Algorithmen zum Schlüsselaustausch, zum Chiffrieren und zur Hash-Berechnung. WireGuard geht einen anderen Weg und kennt für jede Aufgabe nur einen fest codierten Algorithmus. Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung, Poly1305 für die Authentifizierung, BLAKE2 für das Hashing und SipHash24 für die Hashtable.

Durch die vollständige Neuentwicklung und den Fokus auf Grundfunktionen kann komplett auf Altlasten verzichtet werden, was sich auch im Quelltext zeigt. Während OpenVPN und IPSec auf mehrere Hunderttausend Zeilen Code kommen, begnügt sich WireGuard mit ca. 7.000 Zeilen.

Ein weiteres Merkmal ist das eingebaute „Roaming“. Wechselt ein Peer (Client), also z.B. ein Smartphone, zwischen WLAN und Mobilfunknetz, bleibt die WireGuard-Verbindung bestehen und der Anwender bekommt davon nichts mit. Selbst wenn es in seltenen Fällen zu einem Verbindungsabbruch führt, ist die Verbindung fast unmittelbar wiederhergestellt. Andere VPN-Protokolle wie IPSec oder OpenVPN sind im direkten Vergleich quälend langsam.

Die gute Performance ist unter anderem darin begründet, dass WireGuard unter Linux direkt im Kernel arbeitet. Somit entfallen häufige Kontextwechsel zwischen Userland und Kernel und die Datenpakete können deutlich schneller abgearbeitet werden. Zudem besitzt WireGuard spezielle Optimierungen für die MIPS-Prozessor-Architektur, sodass es auch für leistungsschwache Geräte interessant ist.

Fazit

Ich habe WireGuard vor ca. fünf Monaten auf meinem Raspberry Pi und meinem Smartphone installiert. Seitdem ist mein Smartphone zu 100% über den WireGuard-VPN-Tunnel online. Weder daheim noch unterwegs musste ich bisher irgendwelche Probleme feststellen. Die Performance ist super und das Roaming-Verhalten spitze. Wie vom Entwickler versprochen gibt es hier keine Abbrüche oder Verzögerungen. Einziger Negativpunkt ist das spärliche Logging auf beiden Seiten.

In einem weiteren Artikel werde ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehen. Stay tuned!

Cisco und der Verpackungswahn

Cisco Logo

Cisco bietet die Möglichkeit nur wenige Monate oder Wochen benutzte Hardware zu signifikant günstigeren Preisen zu erwerben. Diese Cisco Refresh Produkte sind generalüberholt, vollständig zertifiziert und von neuer Hardware quasi nicht zu unterscheiden. Auch bei der Garantie und Lizenzierung gibt es keine Nachteile. Gute Gründe, um bei Neuanschaffungen über entsprechende Produkte nachzudenken.

Anhand einiger SFP-Module (GLC-LH-SMD), die via Cisco Refresh bezogen wurden, möchte ich euch gerne den Verpackungswahn bei Cisco zeigen. Die SFPs werden einzeln verpackt geliefert. Im größeren Karton befindet sich zunächst ein kleinerer Karton. Dort ist das Modul in einer antistatischen Verpackung enthalten. Das letzte Bild zeigt 20 ausgepackte SFPs und den entstandenen Kartonabfall. Den Plastikabfall habe ich dabei noch gar nicht berücksichtigt.

Ich stelle mir gerade vor, wie viel Verpackungs- und Transportkosten sich einsparen ließen. Geschweige denn von der unnötig verbrauchten Arbeitszeit während dem Auspacken ;-)