Das hier bereitgestellte Beispiel bezieht sich spezifisch auf den Zugang, der von der Amateurfunk-Gruppe der RWTH Aachen zur Verfügung gestellt wird.
Aufgrund der aktuellen Einschränkungen im Betrieb mit PPTP und IPsec (FritzBox) habe ich mich dazu entschlossen, den Beitrag bereits im Status „Draft“ zu veröffentlichen.
Die Überlegung dabei ist, dass notwendige Informationen schneller bereitgestellt werden, auch wenn die Inhalte noch nicht vollständig sind und weiteren Updates unterliegen.
Es lohnt sich, regelmäßig auf die Seite zu schauen.
Warnung!
Diese Anleitung beschreibt die Einrichtung einer VPN-Verbindung in das HAMNET. Das HAMNET ist ein spezielles, nicht öffentliches Netzwerk, das ausschließlich Funkamateuren vorbehalten ist. Die Teilnahme am Amateurfunk sowie die Nutzung des HAMNET setzen den Besitz einer gültigen Lizenzurkunde voraus, die von der Bundesnetzagentur ausgestellt wird. Weitere Informationen dazu findet ihr unter folgendem Link:
Bundesnetzagentur – Amateurfunk.
Wichtiger Hinweis zur Verschlüsselung:
Im Amateurfunk gelten strikte Einschränkungen in Bezug auf die Nutzung von Verschlüsselungstechnologien. Daher kann das vorgestellte Beispiel nicht für den allgemeinen Gebrauch verwendet werden! L2TP ohne die Verwendung von IPsec ist grundsätzlich unsicher und nicht verschlüsselt!
Das hier bereitgestellte Beispiel bezieht sich auf die Konfiguration eines Core-Routers. Das bedeutet, der OpenWRT-Router befindet sich hinter dem regulären Hausanschlussrouter, z. B. einer FritzBox. Dies hat den Vorteil, dass die bestehende Internetkonfiguration kaum verändert wird. Dadurch lassen sich mögliche Störungen minimieren und Diskussionen mit dem Internetanbieter vermeiden. Darüber hinaus bietet OpenWRT deutlich mehr Flexibilität bei VPN- und Routing-Funktionen.
Weitere Erläuterungen finden ihr hier: Black Hole/ Null Routing
- Gegebenenfalls müssen entsprechende Routing-Regeln auf der FritzBox (Edge-Router) eingerichtet werden, um das HAMNET zu erreichen. Ein Beispiel dazu wird später bereitgestellt.
- Das Setup wird an einem Anschluss der Deutschen Glasfaser betrieben, der mit einem Carrier-grade NAT (CGN) arbeitet.
Vorbereitung
Die Beantragung eines Benutzeraccounts erfolgt über die Amateurfunkgruppe. Ein Benutzeraccount kann hier beantragt werden: https://www.afu.rwth-aachen.de/vpn-zugang
Grundvoraussetzung für dieses Setup ist ein vorhandener OpenWRT-Router. Informationen zum OpenWRT-Projekt und zur Bereitstellung eines OpenWRT-basierten Routers finden ihr hier: OpenWRT
Für die Installation des L2TPs muss sichergestellt werden, dass die notwendigen Pakete auf dem OpenWRT-Router installiert sind.
Die Installation kann entweder über die GUI (LuCI) im Menü System → Software oder über die Kommandozeile (nach einem SSH-Login) erfolgen.
- xl2tpd: erforderlich für L2TP
- mtr-json: hilfreich für das Troubleshooting und zur Validierung der Routen
opkg update
opkg install xl2tpd mtr-json
Ein Neustart des Systems kann dabei helfen, die L2TP-Option im LuCI-Dialog verfügbar zu machen.
Konfiguration
Zugang
Der VPN-Zugang wird über den folgenden Endpunkt bereitgestellt:
DNS = vpn.afu.rwth-aachen.de
IP = 137.226.79.99
L2TP
L2TP Interface in LuCI anlegen
Create L2TP Interface
Im OpenWRT-Konfigurationsinterface LuCI kann im Bereich Network -> Interfaces ein neues L2TP-Interface erstellt werden.
Der Name des Interfaces sollte nicht länger als acht Zeichen sein. Zwar habe ich das nicht ausführlich getestet, aber bei mir traten bei längeren Namen Probleme mit den Startskripten auf.
L2TP Advanced Settings
Im folgenden kann die MTU an eure Bedürfnisse angepasst werden, sollte jedoch 1420 nicht überschreiten.
Das Feld „Use custom DNS servers“ kann in meinem Fall leer bleiben. In diesem Beispiel nutze ich den DNSMASQ-Daemon, der von allen Clients in meinem Netzwerk verwendet wird. Eine entsprechende Regel wird dort in die Konfiguration eingetragen – dazu später mehr.
Zur Kontrolle:
...
config interface 'HAM_L2TP'
option proto 'l2tp'
option server 'vpn.afu.rwth-aachen.de'
option username 'dg2eki'
option password '*******'
option ipv6 '0'
option mtu '1320'
option delegate '0'
option defaultroute '0'
...
L2TP Firewall Settings
OpenWRT verwendet eine zonenbasierte Firewall. Um den Zugriff der Clients auf das HAMNET zu ermöglichen, muss das L2TP-Interface einer Zone zugeordnet werden, beispielsweise der Zone HAMNET.
Der Zugriff wird durch die Beziehungen zwischen den Zonen geregelt.
Ein empfehlenswertes Erklärvideo zur Funktionsweise der Firewall finden Sie hier: https://youtu.be/UvniZs8q3eU?feature=shared
Firewall – Zone Settings
In Network -> Firewall -> “Firewall – Zone Settings” sollte die Option “Allow forward to destination zones:” leer bleiben, wenn keine Verbindungen aus dem HAMNET ins eigene Netzwerk erlaubt sein sollen.
- Masquerading: Aktivieren
- MSS Clamping: Bei Bedarf aktivieren
Die Option “Allow forward from source zones:” ermöglicht Zugriff aus der Zone DATA auf das HAMNET.
Achtung: Gegebenenfalls sollte dieser Eintrag leer bleiben, und ein Forwarding stattdessen über die “Firewall – Traffic Rules” definiert werden. Dabei kann der Zugriff auf spezifische Benutzer oder Hosts eingeschränkt werden.
Wichtig: Es muss sichergestellt werden, dass nur lizenzierte Funkamateure das HAMNET nutzen können.
Überprüfen der L2TP und PPP Settings
xl2tpd.conf
[global]
port = 1701
auth file = /etc/xl2tpd/xl2tp-secrets
access control = yes
debug network = no
debug tunnel = no
Genauer Information zu den Parametern gibt es hier: https://linux.die.net/man/5/xl2tpd.conf
options
debug
logfile /tmp/ppp.log
noaccomp
nopcomp
nocrtscts
noccp
lock
maxfail 0
#refuse-chap
refuse-eap
refuse-mschap
#nomppe
noipv6
Genauere Information zu den Parametern gibt es hier: https://linux.die.net/man/8/pppd
Routing
HAMNET-Adressbereiche
44.0.0.0/9 [HAMNET US]
44.128.0.0/10 [HAMNET Rest of the World - ROW]
44.192.0.0/10 [Amazon]
Hausanschlussrouter
Da das HAMNET nicht über das öffentliche Internet erreichbar sein soll, ist es notwendig die Routen zum OpenWRT-Router umzuleiten. Dieser stellt die Verbindung zum HAMNET bereit.
In meinem Fall ist der Hausanschlussrouter – auch als Edge-Router bezeichnet – eine FritzBox. Im Bild ist exemplarisch dargestellt, wie statische Routen angelegt werden können. Als Ziel-Gateway dient die IP-Adresse 192.168.172.2, die den OpenWRT-Router repräsentiert. Dieser stellt die Verbindung zum HAMNET über einen L2TP-Tunnel her.
OpenWRT-Router
Für die Routingaufgaben auf meinem OpenWRT-Router verwende ich das FRRouting (FRR) Project. Diese Entscheidung basiert auf einer Vielzahl von VPN-Verbindungen zu Hyperscalern, Lab-Umgebungen und privaten Netzwerken, die ein dynamisches Routing erforderlich gemacht haben.
Daher definiere ich die notwendigen statischen Routen für das HAMNET in der Datei frr.conf, der zentralen Konfigurationsdatei der FRR-Suite.
Gegebenenfalls müsstet ihr einen anderen Weg wählen.
ip route 44.128.0.0/10 44.148.186.1 l2tp-HAM_L2TP
ip route 44.0.0.0/9 44.148.186.1 l2tp-HAM_L2TP
Den Interfacenamen kann man mittels ifconfig ermitteln:
# ifconfig
l2tp-HAM_L2TP Link encap:Point-to-Point Protocol
inet addr:44.148.184.162 P-t-P:44.148.186.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1320 Metric:1
RX packets:151 errors:0 dropped:0 overruns:0 frame:0
TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:11290 (11.0 KiB) TX bytes:11426 (11.1 KiB)
DNS
# Interface HAM_L2TP
nameserver 44.148.186.1
Beim Verbindungsaufbau wird der DNS-Server für das L2TP-Interface automatisch in die Datei /etc/resolv.conf
eingetragen.
DNSMASQ-Forwarder
Um die DNS-Auflösung auch für andere Hosts in meinem Netzwerk verfügbar zu machen, verwende ich Dnsmasq als zentrale Komponente. Über entsprechende Einträge (Forwarder) in der dnsmasq.conf
lassen sich für spezifische Domains und IP-Adressen individuelle DNS-Server definieren.
Im folgenden Beispiel sind die Parameter für den DNS-Server aus Aachen angegeben.
...
server=/ampr.org/44.148.186.1
rev-server=44.128.0.0/10,44.148.186.1
rev-server=44.0.0.0/9,44.148.186.1
...
Für weitere Domains wie hamnet.cloud und hamnet.radio habe ich noch keine Forwarder angelegt, da diese anscheinend auch von außen erreichbar sind:
root@thewall:~# nslookup db0sda.hamnet.radio 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1:53
Non-authoritative answer:
Non-authoritative answer:
Name: db0sda.hamnet.radio
Address: 44.149.166.2
root@thewall:~# nslookup db0sda.hamnet.radio 44.148.186.1
Server: 44.148.186.1
Address: 44.148.186.1:53
Non-authoritative answer:
Name: db0sda.hamnet.radio
Address: 44.149.166.2
Um die Veränderungen zu aktivieren.
service dnsmasq restart
L2TP Service durchstarten
service xl2tpd restart
Validierung
Interface über prüfen
- Mit den Kommandos
ifdown
undifup
kann das L2TP-Interface gestoppt bzw. gestartet werden. - Mit dem Kommando
ifstatus
kann der aktuelle Status überprüft werden.
ifdown HAM_L2TP
ifstatus HAM_L2TP
{
"up": false,
"pending": false,
"available": true,
"autostart": false,
"dynamic": false,
"proto": "l2tp",
"data": {
}
}
ifup HAM_L2TP
ifstatus HAM_L2TP
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 2,
"l3_device": "l2tp-HAM_L2TP",
"proto": "l2tp",
"updated": [
"addresses",
"routes"
],
"metric": 0,
"dns_metric": 0,
"delegation": false,
"ipv4-address": [
{
"address": "44.148.184.162",
"mask": 32,
"ptpaddress": "44.148.186.1"
}
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "44.128.0.0",
"mask": 10,
"nexthop": "44.148.186.1",
"type": 2,
"source": "0.0.0.0/0"
},
{
"target": "44.0.0.0",
"mask": 9,
"nexthop": "44.148.186.1",
"type": 2,
"source": "0.0.0.0/0"
}
],
"dns-server": [
"44.148.186.1"
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
{
"target": "0.0.0.0",
"mask": 0,
"nexthop": "44.148.186.1",
"source": "0.0.0.0/0"
}
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
}
}
Route(n) überprüfen
MTR ist ein hervorragendes Werkzeug, um das Routing zu überprüfen. Sollte etwas nicht funktionieren, lässt sich schnell erkennen an welcher Stelle im Pfad ein Problem besteht.
sudo mtr 44.149.166.2
Finale
Wenn alles gut gelaufen ist, besteht jetzt eine Verbindung zum HAMNET.
Was mich bei der Konfiguration und der Erstellung der Dokumentation überrascht hat: Anfangs bin ich von einem L2TP/IPsec-VPN ausgegangen. Letztendlich ist mir jedoch aufgefallen, dass IPsec zu keiner Zeit verwendet wurde – es besteht nur ein L2TP-Tunnel. Ob es sich um einen Bug oder ein Feature handelt, versuche ich noch herauszufinden.
Grundsätzlich ist im Amateurfunk die Verwendung von Verschlüsselung untersagt. Ob dieses Verbot auch für die Verbindung über das öffentliche Internet bis zum Gateway gilt entzieht sich derzeit meiner Kenntnis.
Falls jemand genauere Informationen hat, freue ich mich über eure Hinweise. Schreibt mir gerne Rufzeichen @dieschmitterlinge.de
73, de DG2EKI
Troubleshooting
Debug ppp.log
...
debug
logfile /tmp/ppp.log
...
# tail -f /tmp/ppp.log
Using interface l2tp-HAM_L2TP
Connect: l2tp-HAM_L2TP <-->
Overriding mtu 1500 to 1320
Overriding mru 1500 to mtu value 1320
CHAP authentication succeeded
local LL address fe80::xxxx:xxxx:xxxx:xxxx
remote LL address fe80::xxxx:xxxx:xxxx:xxxx
local IP address 44.148.184.206
remote IP address 44.148.186.1
primary DNS address 44.148.186.1
Logread
logread -e xl2tpd
logread -e ppp
logread -f | grep xl2tpd