Dieses Paket erlaubt es, gesicherte Verbindungen zwischen privaten Netzwerken über öffentliche, aber unsichere Netzwerke aufzubauen.
PPTP1.1 bietet eine Möglichkeit, einen privaten Kanal über ein öffentliches Netzwerk aufzubauen. Dabei wird der Tunnelaufbau und -abbau über ein spezielles TCP/IP-Kontrollprotokoll gesteuert. Die eigentlichen Nutzdaten werden in PPP-Paketen verpackt, die über einen GRE-Tunnel1.2 geschickt werden.
In Österreich (und anderen europäischen Ländern) wird PPTP zusätzlich als Protokoll zwischen Router und DSL-Modem verwendet. Im Gegensatz zu PPPoE und PPPoA, die beide noch unterhalb der IP-Ebene arbeiten (Sicherungsschicht, “Link Layer”), gibt es bei PPTP wie oben beschrieben zwei Datenströme. Somit benötigt man für DSL über PPTP im Gegensatz zu anderen DSL-Zugangsmethoden auch für die für PPTP reservierte Ethernet-Karte eine IP-Adresse. Die ist je nach Provider entweder fest vorgegeben oder muss via DHCPv4 konfiguriert werden. Mehr dazu steht in der Beschreibung der Variable CIRC_x_PPP_PPTP_PEER.
Ist man auf Grund eines DSL-Anschlusses oder einer veralteten VPN-Gegenstelle nicht gezwungen, PPTP zu nutzen, so wird davon abgeraten, PPTP als VPN-Lösung zu verwenden. Die Verschlüsselung in PPTP gilt als geknackt1.3, so dass man über PPTP-Tunnel nicht sicherheitskritische Daten verschicken sollte. Für einen solchen Einsatzweck bilden Tunnel auf der Basis von OpenVPN sicherlich die bessere Wahl.
Generell werden ausgehende PPTP-Verbindungen als PPP-Circuits konfiguriert (siehe Circuits vom Typ “ppp”), d. h. es gilt:
CIRC_x_TYPE='ppp'
Zusätzlich muss das OPT_PPP_PPTP
aktiviert werden:
Diese Variable aktiviert die Unterstützung für PPTP. Damit auch tatsächlich eine PPTP-Verbindung genutzt werden kann, muss mindestens ein PPP-Circuit den Typ “pptp” besitzen, d. h. es muss zusätzlich gelten
CIRC_x_TYPE='ppp' CIRC_x_PPP_TYPE='pptp'
(wobei “x” einen gültigen Circuit-Index darstellt).
Standard-Einstellung: OPT_PPP_PPTP='no'
Beispiel: OPT_PPP_PPTP='yes'
Diese Variable definiert, wer die PPP-Datenpakete in GRE-Paketen kapselt und über die Leitung schickt. Dies kann durch ein Benutzerprogramm (pptp) oder durch den Kern erfolgen. Mittels CIRC_x_PPP_PPTP_TYPE wird die Art und Weise der GRE-Paketerzeugung definiert, siehe hierzu Tabelle 1.1.
Momentan ist “daemon” die einzige unterstützte Methode (und somit auch Standard, falls der Typ nicht angegeben wird). Eine Erweiterung des Pakets um das Nutzen des entsprechenden pptp-Kernel-Moduls steht noch aus.
Standard-Einstellung: CIRC_x_PPP_PPTP_TYPE='daemon'
Hier wird die IP-Adresse der PPTP-Gegenstelle eingetragen.
Nutzt man PPTP für einen DSL-Internet-Zugang, muss dazu passend die IP-Adresse der fli4l-PPTP-Ethernet-Karte gewählt werden. In Tabelle 1.2 sind bekannte Konfigurationsvarianten aufgelistet.
|
Für den Fall, dass DHCP zur Konfiguration der lokalen Netzwerk-Karte benötigt wird, ist das dhcp_client-Paket zu installieren und ein entsprechender DHCPv4-Circuit für die jeweilige Ethernet-Karte (in der Regel eth1) einzurichten. Ein Beispiel für Inode xDSL findet sich am Ende des Abschnitts.
Der PPTP-Client muss unter Umständen Pakete zwischenpuffern und umordnen. Normalerweise wartet er 0,3 Sekunden auf ein ausstehendes Paket. Mit dieser Variable kann man den Timeout zwischen 0.00 (gar nicht puffern) und 10.00 (max. 10 Sekunden warten) variieren. Die Zeiten müssen immer mit Punkt und zwei Nachkommstellen angegeben werden.
Standard-Einstellung: CIRC_x_PPP_PPTP_REORDER_TIMEOUT='0.30'
Beispiel: CIRC_1_PPP_PPTP_REORDER_TIMEOUT='1.00'
Mit dieser Variable kann konfiguriert werden, wieviel Ausgaben der PPTP-Client produziert. Möglich sind 0 (wenig), 1 (mittel) und 2 (viel).
Standard-Einstellung: CIRC_x_PPP_PPTP_LOGLEVEL='1'
Beispiel: CIRC_1_PPP_PPTP_LOGLEVEL='2'
Der fli4l kann auch konfiguriert werden, eingehende PPTP-Verbindungen anzunehmen, also als ein Server zu fungieren. Solche PPTP-Verbindungen werden ebenfalls als PPP-Circuit konfiguriert (siehe Circuits vom Typ “ppp”), d. h. es gilt:
CIRC_x_TYPE='ppp'
Zusätzlich muss das OPT_PPP_PPTP_SERVER
aktiviert werden:
Mit dieser Variable wird die Unterstützung für eingehende PPTP-Verbindungen aktiviert. Damit auch tatsächlich PPTP-Verbindungen angenommen werden können, muss mindestens ein PPP-Circuit den Typ “pptp-server” besitzen, d. h. es muss zusätzlich gelten
CIRC_x_TYPE='ppp' CIRC_x_PPP_TYPE='pptp-server'
(wobei “x” einen gültigen Circuit-Index darstellt).
Standard-Einstellung: OPT_PPP_PPTP_SERVER='no'
Beispiel: OPT_PPP_PPTP_SERVER='yes'
Zu den allgemeinen Circuit-Variablen kommen die folgenden, für PPP-Circuits des Typs “pptp-server” spezifischen Variablen hinzu:
Mit dieser Variable kann die IPv4-Adresse festgelegt werden, an welcher der PPTP-Server horcht. Wird diese Variable weggelassen, horcht der PPTP-Server an allen Schnittstellen des Routers.1.4
Mit Hilfe der hier konfigurierten Adresse wird im Falle von PF_INPUT_ACCEPT_DEF='yes' bzw. PF_OUTPUT_ACCEPT_DEF='yes' die Firewall in den INPUT- und OUTPUT-Ketten sowohl für das PPTP-Kontrollprotokoll auf TCP-Port 1723 als auch für die GRE-Pakete geöffnet. Fehlt diese Variable, wird die Firewall so konfiguriert, dass die Kontroll- und Daten-Pakete an jeder Adresse des PPTP-Servers empfangen werden können.
Beispiel: CIRC_1_PPP_PPTP_SERVER_LISTEN='IP_NET_1_ADDR'
Dieses Array enthält eine Liste von IPv4-Netzadressen, für die ein Zugriff auf den PPTP-Server in der Firewall erlaubt wird. Mit Hilfe der hier konfigurierten Adressen wird im Falle von PF_INPUT_ACCEPT_DEF='yes' bzw. PF_OUTPUT_ACCEPT_DEF='yes' die Firewall in den INPUT- und OUTPUT-Ketten sowohl für das PPTP-Kontrollprotokoll auf TCP-Port 1723 als auch für die GRE-Pakete geöffnet. Fehlt dieses Array, wird die Firewall so konfiguriert, dass die Kontroll- und Daten-Pakete von bzw. nach überall akzeptiert werden.
Beispiel:
CIRC_1_PPP_PPTP_SERVER_ALLOW_FROM_N='3' CIRC_1_PPP_PPTP_SERVER_ALLOW_FROM_1='IP_NET_1' CIRC_1_PPP_PPTP_SERVER_ALLOW_FROM_2='10.1.2.0/24' CIRC_1_PPP_PPTP_SERVER_ALLOW_FROM_3='{Labor}'
Diese Variable enthält die Anzahl der Verbindungen, die dieser PPTP-Server maximal gleichzeitig verwalten kann. Maximal werden 255 Tunnel unterstützt. 1.5
Standard-Einstellung: CIRC_x_PPP_PPTP_SERVER_SESSIONS='100'
Beispiel: CIRC_1_PPP_PPTP_SERVER_SESSIONS='200'
Beispiel 1 (Internet-Zugang über PPTP mit fester lokaler Adresse):
IP_NET_N='2' # (mindestens) zwei Netze (LAN + PPTP) IP_NET_1='192.168.6.0/24' # lokales Netz, wie benötigt konfigurieren IP_NET_1_DEV='eth0' # lokales Netz hängt an erster Karte IP_NET_2='10.0.0.140/29' # unsere Adresse im PPTP-Netz IP_NET_2_DEV='eth1' # Internet-Modem hängt an zweiter Karte # OPT_PPP='yes' # PPP-Circuits aktivieren OPT_PPP_PPTP='yes' # PPTP-Client-Circuits aktivieren # CIRC_N='1' CIRC_1_NAME='DSL-mxstream' # beliebig, aber eindeutig CIRC_1_TYPE='ppp' # das ist ein PPP-Circuit CIRC_1_ENABLED='yes' CIRC_1_NETS_IPV4_N='1' CIRC_1_NETS_IPV4_1='0.0.0.0/0' # Default-Route ins Internet CIRC_1_CLASS_N='1' CIRC_1_CLASS_1='internet' # Klasse für Internet-Anbindung CIRC_1_UP='yes' # beim Booten aktivieren CIRC_1_TIMES='Mo-Su:00-24:0.0:Y' CIRC_1_USEPEERDNS='yes' # DNS-Server des Providers nutzen CIRC_1_PPP_TYPE='pptp' # PPTP-Client CIRC_1_PPP_USERID='anonymer' # Benutzername zur Authentifizierung CIRC_1_PPP_PASSWORD='surfer' # Passwort zur Authentifizierung CIRC_1_PPP_PPTP_PEER='10.0.0.138' # Adresse des Internet-Modems im PPTP-Netz # CIRC_CLASS_N='1' CIRC_CLASS_1='internet' # Klasse aller Internet-Circuits
Beispiel 2 (Internet-Zugang über PPTP mit dynamisch zugewiesener lokaler Adresse):
IP_NET_N='2' # (mindestens) zwei Netze (LAN + PPTP) IP_NET_1='192.168.6.0/24' # lokales Netz, wie benötigt konfigurieren IP_NET_1_DEV='eth0' # lokales Netz hängt an erster Karte IP_NET_2='{DHCP-Inode}' # PPTP-Netz, via DHCP konfiguriert IP_NET_2_DEV='eth1' # Internet-Modem hängt an zweiter Karte # OPT_DHCP_CLIENT='yes' # DHCP-Circuits aktivieren OPT_PPP='yes' # PPP-Client-Circuits aktivieren OPT_PPP_PPTP='yes' # PPTP-Client-Circuits aktivieren # CIRC_N='2' # zwei Circuits: DHCP und PPTP # CIRC_1_NAME='DHCP-Inode' # beliebig, aber eindeutig CIRC_1_TYPE='dhcp' # das ist ein DHCP-Circuit CIRC_1_ENABLED='yes' CIRC_1_NETS_IPV4_N='1' # hierüber soll die PPTP-Gegenstelle CIRC_1_NETS_IPV4_1='10.0.0.138/32'# (= Internet-Modem) erreichbar sein CIRC_1_DHCP_DEV='IP_NET_2_DEV' # die PPTP-Ethernet-Karte CIRC_1_UP='yes' # beim Booten aktivieren # CIRC_2_NAME='PPTP-Inode' # beliebig, aber eindeutig CIRC_2_TYPE='ppp' # das ist ein PPP-Circuit CIRC_2_ENABLED='yes' CIRC_2_PPP_TYPE='pptp' # PPTP-Client CIRC_2_PPP_USER='anonymer' # Benutzername zur Authentifizierung CIRC_2_PPP_PASS='surfer' # Passwort zur Authentifizierung CIRC_2_PPP_FILTER='yes' # Datenverkehr-Filter aktivieren CIRC_2_PPP_PPTP_PEER='10.0.0.138' # Adresse des Internet-Modems im PPTP-Netz CIRC_2_NETS_IPV4_N='1' CIRC_2_NETS_IPV4_1='0.0.0.0/0' # Default-Route ins Internet CIRC_2_USEPEERDNS='yes' # DNS-Server des Providers nutzen CIRC_2_HUP_TIMEOUT='600' # nach 10 Minuten Inaktivität auflegen CIRC_2_UP='yes' # beim Booten aktivieren CIRC_2_DEPS='DHCP-Inode' # PPTP benötigt DHCP-Konfiguration
Beispiel 3 (VPN-Client):
IP_NET_N='1' # (mindestens) ein (lokales) Netz IP_NET_1='192.168.6.0/24' # lokales Netz, wie benötigt konfigurieren IP_NET_1_DEV='eth0' # lokales Netz hängt an erster Karte # OPT_PPP='yes' # PPP-Circuits aktivieren OPT_PPP_ETHERNET='yes' # PPPoE-Client-Circuits aktivieren (DSL) OPT_PPP_PPTP='yes' # PPTP-Client-Circuits aktivieren (VPN) # CIRC_N='2' # zwei Circuits: PPPoE (Internet) und PPTP # CIRC_1_NAME='DSL-Telekom' # beliebig, aber eindeutig CIRC_1_TYPE='ppp' # das ist ein PPP-Circuit CIRC_1_ENABLED='yes' CIRC_1_NETS_IPV4_N='1' CIRC_1_NETS_IPV4_1='0.0.0.0/0' # Default-Route ins Internet CIRC_1_CLASS_N='1' CIRC_1_CLASS_1='internet' # Klasse für Internet-Anbindung CIRC_1_UP='yes' # beim Booten aktivieren CIRC_1_TIMES='Mo-Su:00-24:0.0:Y' CIRC_1_USEPEERDNS='yes' # DNS-Server des Providers nutzen CIRC_1_PPP_TYPE='ethernet' # PPPoE-Client CIRC_1_PPP_USERID='anonymer' # Benutzername zur Authentifizierung CIRC_1_PPP_PASSWORD='surfer' # Passwort zur Authentifizierung CIRC_1_PPP_ETHERNET_TYPE='kernel' # Kernel soll PPPoE-Pakete packen CIRC_1_PPP_ETHERNET_DEV='eth1' # DSL-Modem hängt an zweiter Karte # CIRC_2_NAME='VPN-Firma' # beliebig, aber eindeutig CIRC_2_TYPE='ppp' # das ist ein PPP-Circuit CIRC_2_ENABLED='yes' CIRC_2_NETS_IPV4_N='1' CIRC_2_NETS_IPV4_1='10.11.12.0/24'# Firmennetz CIRC_2_DEPS='internet/ipv4' # Verbindung zur Firma benötigt # IPv4-Internet CIRC_2_UP='yes' # beim Booten aktivieren CIRC_2_TIMES='Mo-Su:00-24:0.0:Y' CIRC_2_PPP_TYPE='pptp' # PPTP-Client CIRC_2_PPP_USERID='mustermann' # Benutzername zur Authentifizierung CIRC_2_PPP_PASSWORD='geheim' # Passwort zur Authentifizierung CIRC_2_PPP_PPTP_PEER='192.0.2.1' # Adresse des PPTP-Servers der Firma # CIRC_CLASS_N='1' CIRC_CLASS_1='internet' # Klasse aller Internet-Circuits
Beispiel 4 (VPN-Server):
OPT_PPP='yes' # PPP-Circuits aktivieren OPT_PPP_PPTP_SERVER='yes' # PPTP-Server-Circuits aktivieren OPT_PPP_PEERS='yes' # zum Speichern der Anmeldedaten PPP_PEER_N='1' # 1x Anmeldedaten hinterlegen PPP_PEER_1_USERID='user' # Benutzername vom Client PPP_PEER_1_PASSWORD='pass' # Passwort vom Client PPP_PEER_1_CIRCUITS='pptp-eth1' # Anmeldedaten gelten für PPTP-Circuit # CIRC_N='1' CIRC_1_NAME='pptp-eth1' # beliebig, aber eindeutig CIRC_1_TYPE='ppp' # das ist ein PPP-Circuit CIRC_1_ENABLED='yes' CIRC_1_UP='yes' # beim Booten aktivieren CIRC_1_TIMES='Mo-Su:00-24:0.0:Y' CIRC_1_PROTOCOLS='ipv4' # IPv4 soll über die Verbindung laufen CIRC_1_PPP_TYPE='pptp-server' # PPTP-Server CIRC_1_PPP_PEER_AUTH='yes' # Client-Authentifizierung ist Pflicht CIRC_1_PPP_COMP_MPPE='yes' # benutze Verschlüsselung CIRC_1_PPP_LOCALIP='192.168.222.1' # IP-Adresse des Servers CIRC_1_PPP_REMOTEIP='192.168.222.2' # Start-IP-Adresse der Clients CIRC_1_PPP_PPTP_SERVER_SESSIONS='10' # max. 10 Tunnel
Mit fastd1.6 steht eine schnelle und kleine Alternative zu bekannten VPN-Lösungen bereit. Ziele bei der Entwicklung waren folgende Punkte:
In vielen Freifunk-Projekten ist fastd Bestandteil der auf Gluon basierenden Firmware. Während dort in der Regel klar ist, was Client und Server ist, wird dies nicht durch das verwendete Protokoll bestimmt, sondern nur durch die Nutzung. Für fastd werden daher neben der Serverinstanz bei jedem beteiligten Kommunikationspartner ein oder mehrere sogenannte Peers definiert. Für die Konfiguration der jeweiligen Gegenstelle kehren sich damit die Rollen um: was auf der einen Seite Serverdaemon ist, muss auf der anderen Seite als Peer konfiguriert werden und umgekehrt.
Diese Variable aktiviert den fastd. Um tatsächlich Verbindungen aufzubauen, müssen diese natürlich noch entsprechend konfiguriert werden.
Standard-Einstellung: OPT_FASTD='no'
Beispiel: OPT_FASTD='yes'
Setzt den geheimen Schlüssel dieser fastd-Instanz. Ein Schlüsselpaar kann beispielsweise mit dem Programm fastd erzeugt werden, welches auf dem Router oder auf einem beliebigen anderen Linux-Rechner laufen kann:
# fastd --generate-key 2016-01-06 18:54:13 +0100 --- Info: Reading 32 bytes from /dev/random... Secret: d8dec7f65c89a39561ecde12623e8051d1d7c4286253b119f155e3fe169cd161 Public: e89e34e53c35bd6d750558a5e747fa72f25fbc922c86625b705ef1aa1865e32a
Wird diese Variable leer gelassen, erzeugt das Startscript ein Schlüsselpaar und legt den Inhalt in der Datei /tmp/fastd.secret ab, die man sich dann vom Router runter kopieren kann. Der fastd Service wird dann nicht gestartet!
Standard-Einstellung: FASTD_SECRET=”
Beispiel: FASTD_SECRET='d8dec7f65c89a39561ecde12623e8051d1d7c4286253b119f155e3fe169cd161'
WireGuard1.7 ist eine recht neue Alternative zu bekannten VPN-Lösungen wie OpenVPN oder IPSec. Ziel ist ein modernes, schnelles, einfaches VPN, das state-of-the-Art Verschlüsselung einsetzt. IPv4, IPv6 und auch Dual-Stack sind mit WireGuard kein Problem.
Ziele bei der Entwicklung waren unter anderem
Diese Einfachheit zeigt sich auch in der Konfiguration unter fli4l.
Standard-Einstellung: OPT_WIREGUARD='no'
Diese Variable aktiviert das Paket WireGuard. Zusätzlich müssen die einzelnen Verbindungen oder Clients (peers) konfiguriert werden.
Beispiel: OPT_WIREGUARD='yes'
WireGuard VPNs sind kein Client-Server-Modell im eigentlichen Sinne. Vielmehr werden VPN-Verbindungen immer zwischen zwei Peers aufgebaut. Dies bringt den Vorteil mit sich, dass die IP-Adressen beider Peers floating sein können. Beide Peers werden Änderungen der IP-Adresse automatisch übernehmen ohne weitere Konfiguration. Entscheidend ist nur, dass die ankommenden UDP-Pakete richtig signiert und verschlüsselt sind (siehe Private/Public Key unten). Weder im fli4l noch bei den Peers ist hierfür spezielle Konfiguration erforderlich.
Der Einfachheit halber sprechen wir im Weiteren teils dennoch von Server (damit ist der fli4l gemeint) und Client (damit ist dann die Gegenstelle wie z. B. das Handy, der PC oder auch ein anderer fli4l gemeint)
Achtung:
Zusätzlich zur Konfiguration von WireGuard in
vpn.txt muss der Paketfilter entsprechend konfiguriert
werden. Dies geschieht über die normalen Wege in base.txt.
Wichtig sind v. a.:
PF_INPUT[]='prot:udp 50002 ACCEPT' # in base.txt
Legt fest wie viele WireGuard Konfigurationen ('Server') wir haben wollen.
Beispiel: WIREGUARD_N='1'
Der Name dieser WireGuard-Instanz
Lokale IP-Adresse (bei \32) oder Netzwerk (z. B. \24) dieser WireGuard-Instanz
Port, auf dem WireGuard lauschen soll. Der Port muss zusätzlich in base.txt geöffnet werden, z. B.:
WIREGUARD_1_LISTEN_PORT='50002' # in vpn.txt PF_INPUT[]='prot:udp 50002 ACCEPT' # in base.txt
Standardwert: WIREGUARD_x_PRIVATE_KEY='auto'
Der private Schlüssel dieser WireGuard-Instanz.
Es gibt zwei Möglichkeiten:
Der Key kann manuell auf dem fli4l per
wg genkey > privatekey
erstellt werden. Einfacher ist es aber sicherlich, beim ersten Start hier 'auto' zu konfigurieren und den erstellten Private Key dann nach Start aus dem Webinterface des fli4l zu übernehmen. Anders als die Private Keys der Peers muss der Private Key des Servers auf dem fli4l verbleiben.
Standardwert: WIREGUARD_DEFAULT_OPEN_PORT='yes'
Optional: Legt fest ob im Paketfilter automatisch Regeln angelegt werden sollen, um eingehende WireGuard-Pakete zu akzeptieren. Damit werden alle in WIREGUARD_x_LISTEN_PORT definierten UDP-Ports automatisch geöffnet.
Optional: Anzahl der IPs bzw. Netzwerke, die den Peers vorgegeben werden sollen, diese durch den VPN-Tunnel zu routen.
Standardwert: WIREGUARD_x_DEFAULT_ALLOWED_IPS_N='0'
Optional: IPs bzw. Netzwerke, die für alle Peers durch den VPN-Tunnel geroutet werden sollen. Hier angegebene Netze werden in der Peer-Config, die im Webinterface als QR-Code oder Datei einsehbar ist, entsprechend übernommen. Bei manueller Konfiguration der Peers wären diese Werte in AllowedIPs anzugeben.
Es können sowohl IPv4- als auch IPv6-Netzwerke angegeben werden. Interne Identifier wie IP_NET_x und IP6_NET_x sind ebenfalls möglich.
Beispiel:
WIREGUARD_1_DEFAULT_ALLOWED_IPS_N='2' WIREGUARD_1_DEFAULT_ALLOWED_IPS_1='IP_NET_1' WIREGUARD_1_DEFAULT_ALLOWED_IPS_2='10.0.0.2/24'
Standard-Einstellung: WIREGUARD_x_KEEP_ALIVE='0'
Optional: Intervall in Sekunden, in dem WireGuard UDP-Pakete versendet, um die Verbindung aufrecht zu erhalten. Da UDP an sich zustandslos ist, ist dies im Normalfall nicht notwendig.
Standard-Einstellung: WIREGUARD_x_LOCAL_HOST=”
Optional: Der DNS-Name, unter dem fli4l im Internet erreichbar ist. Für die Funktion von WireGuard nicht erforderlich. Allerdings bietet es sich an, die Variable auf einen Hostname zu setzen, der z. B. von OPT_DYNDNS aktualisiert wird. Die Peer-Konfiguration für die Gegenstellen im WebInterface (QR-Code bzw. Downlaod der Config-Datei) enthält dann diesen Wert als Gegenstelle.
WIREGUARD_x_LOCAL_HOST='some.domain.de'
Optional: IPv6-Adresse des Servers.
Standard-Einstellung: WIREGUARD_x_PUBLIC_KEY=”
Optional: Public Key der lokalen WireGuard-Instanz (Server).
Da der Public Key aus dem Private Key errechnet werden kann, ist der Public Key optional.
Die allermeisten Nutzer werden diese Variable nicht benötigen und stattdessen den Private Key beim ersten Start automatisch erstellen lassen und danach den Private Key aus dem Webinterface in die Konfiguration übernehmen. Der Public Key wird dabei automatisch aus dem Private Key abgeleitet.
WIREGUARD_x_PRIVATE_KEY='auto'
Optional: Anzahl der DNS-Server, die dem Peer in der Konfiguration mitgegeben werden.
Achtung:
WireGuard unterstützt kein Push
von Netzwerkparametern beim Verbindungsaufbau. Die DNS-Server werden
in der Peer-Config, die im Webinterface als QR-Code und Download
verfügbar ist, hinterlegt.
Standardwert: WIREGUARD_x_PUSH_DNS_N='0'
Optional: IPs von DNS-Servern, die in der Peer-Konfiguration hinterlegt werden. Achtung: WireGuard unterstützt kein Push von Netzwerkparametern beim Verbindungsaufbau. Die DNS-Server werden in der Peer-Config, die im Webinterface als QR-Code und Download verfügbar ist, hinterlegt und somit erst angewendet, wenn der Peer diese Konfiguration neu bekommt.
Es können sowohl IPv4- als auch IPv6-Adressen angegeben werden.
Beispiel:
WIREGUARD_1_PUSH_DNS_N='2' WIREGUARD_1_PUSH_DNS_1='10.0.0.1' WIREGUARD_1_PUSH_DNS_2='2001:4860:4860::8888'
Standardwert: WIREGUARD_x_PEER_N='0'
Legt fest wie viele Peers wir konfigurieren wollen.
Beispiel: WIREGUARD_1_PEER_N='3'
Der Name des WireGuard Peers. Dient nur zur Identifikation z. B. im Webinterface.
IP-Adresse (bei \32) des WireGuard Peers bzw. Netzwerk (z. B. \24), das sich hinter dem Peer verbirgt (z. B. bei Site-2-Site VPN). Die Adresse muss im selben Netzwerk liegen, wie die IP-Adresse des zugehörigen WireGuard Servers WIREGUARD_x_LOCAL_IP4
Beispiel:
WIREGUARD_1_LOCAL_IP4='10.0.0.1/24' WIREGUARD_1_PEER_1_LOCAL_IP4='10.0.0.2/32' WIREGUARD_1_PEER_2_LOCAL_IP4='10.0.0.3/32'
Der Public Key des WireGuard Peers.
Zum Verbindungsaufbau benötigt WireGuard zwar den Private Key der lokalen Instanz, vom Peer ist jedoch natürlich nur der Public Key erforderlich.
Es gibt zwei Möglichkeiten:
Optional: Anzahl der IPs bzw. Netzwerke, die diesem einzelnen Peer vorgegeben werden sollen, diese durch den VPN-Tunnel zu routen.
Standardwert: WIREGUARD_x_PEER_x_ALLOWED_IPS_N='0'
Optional: IPs bzw. Netzwerke, die der jeweilige Peer durch den VPN-Tunnel routen soll. Hier angegebene Netze werden in der Peer-Config, die im Webinterface als QR-Code oder Datei einsehbar ist, entsprechend übernommen. Bei manueller Konfiguration der Peers wären diese Werte in AllowedIPs anzugeben. Die hier für jeden einzelnen Peer konfigurierten Netzwerke werden mit den Netzen aus WIREGUARD_x_DEFAULT_ALLOWED_IPS zusammengeführt und als AllowedIPs in der jeweiligen Peer-Config hinterlegt.
Es können sowohl IPv4- als auch IPv6-Netzwerke angegeben werden. Interne Identifier wie IP_NET_x und IP6_NET_x sind ebenfalls möglich.
Beispiel:
WIREGUARD_1_PEER_1_ALLOWED_IPS_N='2' WIREGUARD_1_PEER_1_ALLOWED_IPS_1='IP_NET_2' WIREGUARD_1_PEER_2_ALLOWED_IPS_2='192.168.1.0/24'
Optional: IPv6-Adresse des Servers. Die Adresse muss im selben Netzwerk liegen wie die Adresse des zugehörigen WireGuard Servers WIREGUARD_x_LOCAL_IP6.
Optional: Der Private Key des Peers. Im Gegensatz zum Public Key ist dieser nicht erforderlich. Falls man die Konfiguration allerdings per QR-Code oder Download der Config-Datei im Webinterface auf den übernehmen möchte, ist es sinnvoll, den Private Key des Peers hier anzugeben.
WIREGUARD_x_PEER_x_PUBLIC_KEY='auto'
So erzeugte Private (und evtl. Public Keys des Peers sollten statisch in die Konfigurationsdatei übernommen werden, da sonst bei jedem Neustart neue Keys erzeugt werden und der Client sich erst wieder verbinden kann, wenn diese Keys entsprechend übertragen wurden.
Bei Private Keys der Peers sollte man sich überlegen, ob diese wirklich dauerhaft auf dem fli4l verbleiben sollen. Für die VPN-Verbindung sind nur die Public Keys des Peers notwendig (sowie Private Key des Servers). Man kann also durchaus die Keys der Peers automatisch erstellen lassen, dann aber nur die jeweiligen Public Keys in die statische Konfiguration übernehmen. Selbst wenn Angreifer dann Zugriff auf auf den fli4l hätten, könnten sie keine VPN-Verbindung erstellen, da der Private Key des Peers fehlt.
Allerdings leidet darunter etwas die Einfachheit: Wenn der Private Key des Peers nicht auf dem fli4l bekannt ist, ist die Peer-Konfiguration, die per QR-Code und Download angeboten wird, unvollständig und kann je nach Betriebssystem nicht eingelesen werden.
Man muss sich also entscheiden:
Optional: mittels eines zusätzlichem Preshared Keys zwischen Server und Client kann die Sicherheit noch weiter erhöht werden.
Es gibt zwei Möglichkeiten:
Wie auch die übrigen automatisch erstellten Keys, sollte auch der Preshared Key nach Erstellung beim ersten Start statisch in die Konfiguration übernommen werden, da ansonsten nach dem nächsten Reboot (und damit verbundener automatischer Neuerstellung der Keys) keine Verbindung mehr zum fli4l möglich ist.
Optional: DNS-Name oder IP-Adresse des Peers. Der WireGuard Server nutzt dies, um die Verbindung zu initiieren. Falls nicht gesetzt, wartet der WireGuard Server auf eingehende gültige (verschlüsselte und signierte) Pakete von Peers und antwortet an die IP-Adresse, von der das Paket kam.
Optional: Der Port, auf dem der jeweilige Peer lauscht. Der WireGuard Server nutzt dies zum initialen Verbindungsaufbau.
Standard-Einstellung: WIREGUARD_x_PEER_x_REMOTE_PORT='51820'
Optional: Die Anzahl der Netzwerke, die über diese VPN-Verbindung zum Peer geroutet werden sollen.
Standardwert: WIREGUARD_x_PEER_x_ROUTE_TO_N='0'
Optional: Die einzelnen Netzwerke, die über diesen Peer geroutet werden sollen.
Beispiel: Hinter Peer 1 sind die beiden Netzwerke 192.168.1.1/24 und 192.168.188.1/24 erreichbar:
WIREGUARD_1_PEER_1_ROUTE_TO_N='2' WIREGUARD_1_PEER_1_ROUTE_TO_1='192.168.1.1/24' WIREGUARD_1_PEER_1_ROUTE_TO_2='192.168.188.1/24'
Bitte die entsprechenden Forward- und Post-Routing-Regeln in base.txt nicht vergessen (ggf. auch auf der Gegenseite).
Zur Verwaltung einiger Grundfunktionen bringt Wireguard auf fli4l das Kommandozeilenwerkzeug wg-tool mit:
fli4l-rgb 4.0.0-r59812M # wg-tool This is a helper script to start and stop WireGuard connections Usage: wg-tool <wg interface> <up|down> wg-tool <wg interface> reresolve <peerName> where <peerName> is the name defined in WIREGUARD_x_PEER_x_NAME example: wg-tool wg1 down example: wg-tool wg1 reresolve peer5Name
Im Normalbetrieb ist die Nutzung des Tools nicht erforderlich. Es erlaubt bei Bedarf jedoch auf einfache Art das Starten und Stoppen konfigurierter WireGuard-Instanzen.
Beispiel:
wg-tool wg1 down
wg interface ergibt sich aus der Konfiguration in vpn.txt wobei die Zählung der Schnittstellen mit 0 beginnt. WIREGUARD_1 resultiert also in wg0.
Zusätzlich erlaubt wg-tool die erneute Auflösung des DNS-Namens eines Peers ohne den Server neu starten zu müssen, also ohne Unterbrechung der Verbindungen eventueller weiterer Peers, die mit der selben Server-Instanz verbunden sind. Im Normalbetrieb sollte auch dies nicht erforderlich sein.
Eine bekannte Ausnahme ist, wenn der DNS-Name des Peers zum Boot-Zeitpunkt des fli4l nicht aufgelöst werden kann. In diesem Fall wird zwar der WireGuard Server gestartet, die Gegenstelle dieses einen Peers jedoch nicht gesetzt. Falls der Peer von sich aus die Verbindung initiiert, ist auch dies kein Problem, da bei WireGuard ein Verbindungsaufbau grundsätzlich von beiden Seiten (Peers) gleichermaßen initiiert werden kann.
Ansonsten bietet es sich an, entweder wg-tool manuell aufzurufen oder - meist einfacher - über Paket easycron zu automatisieren.
Die Parameter ergeben sich wieder aus der Konfiguration in vpn.txt:
Beispiel:
WIREGUARD_2_PEER_3_NAME='peerTestName' WIREGUARD_2_PEER_3_REMOTE_HOST='somehost.dyndns.de' wg-tool wg1 reresolve peerTestName
Oder alternativ per cron-Job über Paket easycron alle 6 Stunden:
EASYCRON_x_COMMAND='wg-tool wg1 reresolve peerTestName' EASYCRON_x_TIME='* */6 * * *'
OPT_WIREGUARD='yes' WIREGUARD_N='1' WIREGUARD_1_NAME='RoadWarriors' WIREGUARD_1_LOCAL_IP4='10.0.0.1/24' WIREGUARD_1_LISTEN_PORT='50002' WIREGUARD_1_PEER_N='1' WIREGUARD_1_PEER_1_NAME='peer1' WIREGUARD_1_PEER_1_LOCAL_IP4='10.0.0.2/32'
Diese Konfiguration erzeugt eine lokalen WireGuard-Endpunkt auf dem fli4l mit Namen RoadWarriors sowie einen Peer mit Namen peer1.
Alle notwendigen Krypto-Schlüssel (jeweils private und public key für Server und Peer) werden automatisch erstellt und können später im Webinterface eingesehen und in die Konfiguration übernommen werden.
Zusätzlich wird die Peer-Konfiguration im Webinterface
bereitgestellt.
Die automatisch erstellten private Keys sollten nach dem ersten Start statisch in die Konfigurationsdatei vpn.txt übernommen werden. Ansonsten werden sie bei jedem Neustart des Routers neu erzeugt und die WireGuard-Verbindung kann erst wieder aufgebaut werden, wenn die entsprechenden Parameter an den Peer neu übertragen wurden.
Eine vollständige, minimale Konfiguration, die auch Neustarts problemlos übersteht sieht wie folgt aus:
OPT_WIREGUARD='yes' WIREGUARD_N='1' WIREGUARD_1_NAME='RoadWarriors' WIREGUARD_1_LOCAL_IP4='10.0.0.1/24' WIREGUARD_1_LISTEN_PORT='50002' WIREGUARD_1_PRIVATE_KEY='+PxRP6JmwDyM1R+KdeN+vIL2UY2WB+eG/AHLJ/OdsHo=' WIREGUARD_1_PEER_N='1' WIREGUARD_1_PEER_1_NAME='peer1' WIREGUARD_1_PEER_1_LOCAL_IP4='10.0.0.2/32' WIREGUARD_1_PEER_1_PUBLIC_KEY='gP+moyiQtfeO07UH3ASGAy1tX0sLhivLIXGNP0IKbG8='
Die folgende Konfiguration zeigt ein typisches Roadwarrior-Beispiel um von unterwegs jederzeit Zugriff aufs heimische Netz haben zu können. Sicherer Zugriff auf die Heimautomatisierung, den Fileserver zu Hause den digitalen Videorekorder, etc. können so umgesetzt werden.
Die notwendigen Private und Public Keys werden automatisch beim Booten erstellt und sollten nach dem ersten Start aus dem WireGuard Webinterface in die Konfigurationsdatei übernommen werden. Sonst werden beim nächsten Start neue Keys erzeugt und man kommt mit den vorherigen Keys von extern nicht mehr ins VPN.
Folgende Ziele wollen wir mit der Beispiel-Konfiguration erreichen
Folgende Annahmen zu internen Netzen, IPs, etc. wurden getroffen
Um diese Konfiguration umzusetzen, müssen folgende Dateien angepasst werden
Konfiguration Wireguard Server und Peer in vpn.txt
:
OPT_WIREGUARD='yes' WIREGUARD[] { NAME='RoadWarriors' LOCAL_IP4='{wg-RoadWarriors}+0.0.0.1/24' LOCAL_IP6='{wg-RoadWarriors}+::1/64' PRIVATE_KEY='auto' LISTEN_PORT = '50002' LOCAL_HOST='router.dyndns.name' DEFAULT_ALLOWED_IPS[]='IP_NET_1' PUSH_DNS[]='10.0.0.1' PUSH_DNS[]='fd00:cfcf:abcd::1' PEER[] { NAME='Peer1' LOCAL_IP4='{wg-RoadWarriors}+0.0.0.2/32' LOCAL_IP6='{wg-RoadWarriors}+::2/128' PRIVATE_KEY='auto' } }
Konfiguration der IPv4- und IPv6-Netze mittels Network Prefixes in base.txt
:
OPT_NET_PREFIX='yes' NET_PREFIX { [] { NAME='wg-RoadWarriors' # Netzwerk-Präfix für den WireGuard-Tunnel TYPE='static' STATIC_IPV4='10.0.0.0/24' STATIC_IPV6='fd00:cfcf:abcd::/48' } }
Paketfilter-Regeln für IPv4 in base.txt
:
# IPv4 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF_INPUT[]='{wg-RoadWarriors.prefix} ACCEPT' { COMMENT='Zugriff WireGuard RoadWarriors auf fli4l' } # IPv4 Forward-Regel, um Zugriff auf das Netz hinter dem fli4l zu erlauben PF_FORWARD[]='{wg-RoadWarriors.prefix} IP_NET_1 ACCEPT' { COMMENT='Weiterleitung WireGuard RoadWarriors in IP_NET_1 zulassen' } # IPv4 Postrouting-Regel, um Netz hinter fli4l ohne Masquerading zu erreichen PF_POSTROUTING[]='{wg-RoadWarriors.prefix} IP_NET_1 ACCEPT' { COMMENT='Zugriff WireGuard RoadWarriors auf IP_NET_1 ohne Masquerading' }
Paketfilter-Regeln für IPv6 in base.txt
:
# IPv6 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF6_INPUT[]='{rgb-RoadWarriors.prefix} ACCEPT' { COMMENT='Zugriff WireGuard RoadWarriors auf fli4l' } # IPv6 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF6_FORWARD[]='{rgb-RoadWarriors.prefix} IPV6_NET_1 ACCEPT' { COMMENT='Zugriff WireGuard RoadWarriors auf IPV6_NET_1' } # IPv6 Postrouting-Regel, um Netz hinter fli4l ohne Masquerading zu erreichen PF6_POSTROUTING[]='{rgb-RoadWarriors.prefix} IPV6_NET_1 ACCEPT' { COMMENT='Zugriff WireGuard RoadWarriors auf IPV6_NET_1 ohne Masquerading' }
Falls der komplette Traffic des mobilen Geräts immer durch den WireGuard-Tunnel gehen soll (Default-Route durch den VPN-Tunnel), lässt sich dies mit wenigen Anpassungen entsprechend ändern.
Konfiguration der Default-Routen des Peers. Die so erstellte Konfiguration muss per Download oder erneutem Einlesen des QR-Codes erneut auf das mobile Gerät übertragen werden
Neuer Peer in vpn.txt
PEER[] { NAME='Peer2' LOCAL_IP4='{wg-RoadWarriors}+0.0.0.3/32' LOCAL_IP6='{wg-RoadWarriors}+::3/128' PRIVATE_KEY='auto' ALLOWED_IPS[] = '0.0.0.0/0' ALLOWED_IPS[] = '::/0' }
Ergänzung der Paketfilter-Regeln für IPv4 und IPv6 in base.txt
:
# IPv4-Regel, um Zugriff auf Netze und Internet hinter dem fli4l zu erlauben PF_FORWARD[]='{wg-RoadWarriors.prefix} ACCEPT' { COMMENT='Weiterleitung WireGuard RoadWarriors in alle Netze des fli4l' } # IPv4-Regel, um Pakete ins Internet zu maskieren PF_POSTROUTING[]='{wg-RoadWarriors.prefix} {DHCPv4-cable} MASQUERADE' { COMMENT='MASQ WireGuard RoadWarriors to Internet' } # IPv6-Regel, um Zugriff auf Netze und Internet hinter dem fli4l zu erlauben PF6_FORWARD[]='{wg-RoadWarriors.prefix} ACCEPT' { COMMENT='Weiterleitung WireGuard RoadWarriors in alle Netze des fli4l' } # IPv6-Regel, um Pakete ins Internet zu maskieren PF6_POSTROUTING[]='{wg-RoadWarriors.prefix} {DHCPv6-cable} MASQUERADE' { COMMENT='MASQ WireGuard RoadWarriors to Internet' }
Wir gehen dabei davon aus, dass in circuits.txt
:
Die Beispiel-Konfiguration geht von einem fli4l hinter einer FritzBox aus wie im Wiki1.8 beschrieben
Die folgende Konfiguration zeigt ein typisches Beispiel, um zwei Standorte per WireGuard VPN-Tunnel zu verbinden. An beiden Standorten kümmert sich ein fli4l um Routing und verwaltet jeweils weitere interne Netze.
Folgende Ziele wollen wir mit der Beispiel-Konfiguration erreichen
Folgende Annahmen zu internen Netzen, IPs, etc. wurden getroffen
Standort A:
DOMAIN_NAME
in base.txt
)
Standort B:
Um diese Konfiguration umzusetzen, müssen auf beiden Seiten folgende Dateien angepasst werden
Netze in base.txt
:
OPT_NET_PREFIX='yes' NET_PREFIX { [] { NAME='fli4a-intern' TYPE='static' STATIC_IPV4='192.168.1.0/24' STATIC_IPV6='fd5e:aaaa:aaaa::/48' } [] { NAME='fli4b-intern' TYPE='static' STATIC_IPV4='192.168.2.0/24' STATIC_IPV6='fd5e:bbbb:bbbb::/48' } [] { NAME='wg-Site2Site' TYPE='static' STATIC_IPV4='10.0.0.0/24' STATIC_IPV6='fd5e:cccc:cccc::/48' } }
WireGuard VPN-Tunnel Standort A in vpn.txt
::
OPT_WIREGUARD='yes' WIREGUARD[] { NAME='Site2Site-VPN' LOCAL_IP4='{wg-Site2Site}+0.0.0.1/24' LOCAL_IP6='{wg-Site2Site}+::1/64' PRIVATE_KEY='iFwKnsJo/NO0WWiuMPxugdPOq9jqYhIP46uQi1AZj3E=' # unbedingt ändern LISTEN_PORT='50002' DEFAULT_ALLOWED_IPS[]='{fli4a-intern.prefix}' # von allen Peers Pakete # für dieses Netz erlauben PEER[] { NAME='fli4l-B' LOCAL_IP4='{wg-Site2Site}+0.0.0.2/32' LOCAL_IP6='{wg-Site2Site}+::2/128' REMOTE_HOST='fli4lb.somedomain.org' REMOTE_PORT='50000' PUBLIC_KEY='eYyUIGxafeJwLC+BbFTJZ45CtKvCU3TlZ0DFCx9MlD0=' ROUTE_TO[]='{fli4b-intern.prefix}' # Pakete in dieses Netz durch den # Tunnel routen } }
Paketfilter-Regeln Standort A für IPv4 und IPv6 in base.txt
:
# IPv4 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF_INPUT[]='{fli4b-intern.prefix} ACCEPT' { COMMENT='IPv4 Zugriff von Standort B auf fli4l' } # IPv4 Forward-Regel, um Zugriff auf das Netz hinter dem fli4l zu erlauben PF_FORWARD[]='{fli4b-intern.prefix} IP_NET_1 ACCEPT' { COMMENT='IPv4 Weiterleitung von Standort B auf IP_NET_1 zulassen' } # IPv4 Postrouting-Regel, um Netz hinter fli4l ohne Masquerading zu erreichen PF_POSTROUTING[]='{fli4b-intern.prefix} IP_NET_1 ACCEPT' { COMMENT='IPv4 Zugriff von Standort B auf IP_NET_1 ohne Masquerading' } # IPv6 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF6_INPUT[]='{fli4b-intern.prefix} ACCEPT' { COMMENT='IPv6 Zugriff von Standort B auf fli4l' } # IPv6 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF6_FORWARD[]='{fli4b-intern.prefix} IPV6_NET_1 ACCEPT' { COMMENT='IPvv Weiterleitung von Standort B auf IPV6_NET_1 zulassen' } # IPv6 Postrouting-Regel, um Netz hinter fli4l ohne Masquerading zu erreichen PF6_POSTROUTING[]='{fli4b-intern.prefix} IPV6_NET_1 ACCEPT' { COMMENT='IPv6 Zugriff Zugriff Standort B auf IPV6_NET_1 ohne Masquerading' }
DNS Zone Delegation an Standort A in dns_dhcp.txt
, um auch DNS-Namen des Netzes hinter fli4l-B aufzulösen:
OPT_DNS='yes' DNS_ZONE_DELEGATION_N='1' DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_N='1' DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_IP='192.168.2.1' # an fli4l-B delegieren DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_QUERYSOURCEIP='IP_NET_1_IPADDR' DNS_ZONE_DELEGATION_1_DOMAIN_N='1' DNS_ZONE_DELEGATION_1_DOMAIN_1='standortb.domain.de' DNS_ZONE_DELEGATION_1_NETWORK_N='1' DNS_ZONE_DELEGATION_1_NETWORK_1='192.168.2.0/24'
WireGuard VPN-Tunnel Standort B in vpn.txt
::
OPT_WIREGUARD='yes' WIREGUARD_N='1' WIREGUARD_NAME='Site2Site-VPN' WIREGUARD_LOCAL_IP4='{wg-Site2Site}+0.0.0.2/24' WIREGUARD_LOCAL_IP6='{wg-Site2Site}+::2/64' WIREGUARD_PRIVATE_KEY='eJ8s8+oyItWPUSs/5TDBroGWleEV7W/4p98qUY2xD2I=' WIREGUARD_LISTEN_PORT='50002' WIREGUARD_1_PEER_N='1' WIREGUARD_1_PEER_1_NAME='fli4l-A' WIREGUARD_1_PEER_1_LOCAL_IP4='{wg-Site2Site}+0.0.0.1/32' WIREGUARD_1_PEER_1_LOCAL_IP6='{wg-Site2Site}+::1/128' WIREGUARD_1_PEER_1_REMOTE_HOST='fli4lA.dyndns.name' WIREGUARD_1_PEER_1_REMOTE_PORT='50002' WIREGUARD_1_PEER_1_PUBLIC_KEY='S9GsipIvFl36HkcXaET8v0G+UuAw6onDiC+22jJJjVs=' WIREGUARD_1_PEER_1_ALLOWED_IPS__N='1' WIREGUARD_1_PEER_1_ALLOWED_IPS_1='{fli4a-intern.prefix}' WIREGUARD_1_PEER_1_ROUTE_TO_N='1' WIREGUARD_1_PEER_1_ROUTE_TO_1='{fli4a-intern.prefix}'
Paketfilter-Regeln Standort B für IPv4 und IPv6 in base.txt
:
# IPv4 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF_INPUT[]='{fli4a-intern.prefix} ACCEPT' { COMMENT='IPv4 Zugriff von Standort A auf fli4l' } # IPv4 Forward-Regel, um Zugriff auf das Netz hinter dem fli4l zu erlauben PF_FORWARD[]='{fli4a-intern.prefix} IP_NET_1 ACCEPT' { COMMENT='IPv4 Weiterleitung von Standort A auf IP_NET_1 zulassen' } # IPv4 Postrouting-Regel, um Netz hinter fli4l ohne Masquerading zu erreichen PF_POSTROUTING[]='{fli4a-intern.prefix} IP_NET_1 ACCEPT' { COMMENT='IPv4 Zugriff von Standort A auf IP_NET_1 ohne Masquerading' } # IPv6 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF6_INPUT[]='{fli4a-intern.prefix} ACCEPT' { COMMENT='IPv6 Zugriff von Standort A auf fli4l' } # IPv6 Input-Regel, um Zugriff auf fli4l-Router zu erlauben PF6_FORWARD[]='{fli4a-intern.prefix} IPV6_NET_1 ACCEPT' { COMMENT='IPvv Weiterleitung von Standort A auf IPV6_NET_1 zulassen' } # IPv6 Postrouting-Regel, um Netz hinter fli4l ohne Masquerading zu erreichen PF6_POSTROUTING[]='{fli4a-intern.prefix} IPV6_NET_1 ACCEPT' { COMMENT='IPv6 Zugriff Zugriff von Standort A auf IPV6_NET_1 ohne Masquerading' }
DNS Zone Delegation an Standort B in dns_dhcp.txt
, um auch DNS-Namen des Netzes hinter fli4l-A aufzulösen:
OPT_DNS='yes' DNS_ZONE_DELEGATION_N='1' DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_N='1' DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_IP='192.168.1.1' # an fli4l-A delegieren DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_QUERYSOURCEIP='IP_NET_1_IPADDR' DNS_ZONE_DELEGATION_1_DOMAIN_N='1' DNS_ZONE_DELEGATION_1_DOMAIN_1='standortA.home.somedomain.net' DNS_ZONE_DELEGATION_1_NETWORK_N='1' DNS_ZONE_DELEGATION_1_NETWORK_1='{fli4a-intern.prefix}'