< Startseite >

 

Einrichten eines via Bridging arbeitenden OpenVPN-Gateways, um externe (mobile) Geräte über das Internet in das heimische Netzwerk als reguläre LAN-Clients zu integrieren.

Der wichtigste Hinweis gleich zu Beginn: Dieses Tutorial baut auf wesentlichen Teilen meines OpenVPN-Routing-Tutorials auf, wie zum Beispiel bei der Verwendung des selbst erstellten aktuellen OpenVPN-Binarys, Erstellung einer Certificate Authority und der Port-Einstellungen im DSL-Router, weswegen ich diese Komponenten jetzt hier als „fertig erstellt“ deklariere. Die dazu notwendigen Schritte sind im Artikel http://www.thlu.de/openvpn.html umfassend beschrieben.

Der wesentliche Unterschied zum Routing-Tutorial liegt bei dieser Bridging-Lösung in der Prämisse, die entfernten mobilen Clients in das heimische Netzwerk als tatsächlich reguläre LAN-Clients zu integrieren, mit einer eigenen LAN-internen Client-IP.  Es ist dabei ausdrücklich nicht das Ziel, auch den normalen Internet-Datenverkehr der mobilen Clients ebenfalls durch das VPN zu routen, stattdessen soll für alle Zugriffe auf das Internet unverändert das am Ort des Clients lokal aktive Netzwerk verwendet werden. Bei meinem Routing-Setup wird der vollständige Datenverkehr (der Zugang zum heimischen LAN und die Zugriffe aufs Internet via heimischen DLS-Router) durch den VPN-Tunnel geroutet, dem entgegen wird hier beim Bridging die Integration der entfernten Geräte als LAN-Clients realisiert, ohne zusätzlich auch die Internet-Zugriffe des Clients beim Surfen zu routen.

Die markanten Unterschiede in meinen beiden Tutorials sind also: der Lösungsansatz Nur-ein-Zugang ist was anderes als echte Integration, einmal wird auch der Inet-Traffic durch den Tunnel geroutet, beim anderen nicht. Ein weiterer technischer Unterschied besteht darin, das Bridging eine besondere Netzwerk-Konfiguration erfordert, die man von Hand und mit Sachkenntnis herstellen muss. Hier in diesem Tutorial ist der Datenverkehr über eine Netzwerk-Brücke zwischen physischen (eth) und virtuellen (tap) Interface gelöst.  

 

Wie man hier in dieser Grafik erkennen kann, befinden sich die Client-Geräte auf beiden Netzwerk-Seiten allesamt im gleichen Subnet 10.0.1.0/24. Das bedeutet, alle Client-Geräte können untereinander kommunizieren. Achtung, hierzu ein wichtiger Hinweis: Derzeit wird in der von mir favorisierten Android-App „OpenVPN for Android“ der Bridging-Mode via TAP-Device nicht unterstützt. Die FAQ auf der Projekt-Seite sagt dazu folgendes: Tap Mode is not possible with the non root VPN API. Therefore this application cannot provide tap support .Das bedeutet, die Integration von mobilen Android-Geräten über das Internet in das heimische Netzwerk ist zur Zeit vermutlich deshalb nicht möglich, weil ungerootete Geräte anscheinend kein dynamisch generiertes TAP-Device erstellen können.

 
An dieser Stelle ist jetzt außerdem unbedingt eine Warnung angebracht… und zwar vor dem Hintergrund der Frage „Wer ist der Betreiber des lokalen Netzwerkes am entfernten Standort?“  Handelt es sich dabei um ein uns unbekanntes Netzwerk, also irgendein Netzwerk, was irgendein Betreiber für fremde Besucher geöffnet hat, sollten wir diesem Netzwerk auf jeden Fall mit einigem Misstrauen begegnen. Wir wissen nicht, welche fremden Gäste sich noch als ebenfalls reguläre LAN-Clients mit welchen Absichten in diesem Netzwerk aufhalten. Und ist unser VPN-Client-Gerät nicht wirklich zuverlässig durch eine Firewall geschützt ist, so besteht die große Gefahr, dass ein ebenfalls im lokalen Netzwerk anwesender unbekannter Angreifer nicht nur am Ort in unser Gerät eindringt, sondern sich gleich über das Gerät auch noch Zugriff auf unser heimisches Netzwerk verschafft.
 

Grundsätzlich existieren hierbei die gleichen Risiken, wie ich sie bereits hier schon beschrieben habe. Ich persönlich würde auf Reisen und mit Verbindungen an fremden und somit potentiell unsicheren Accesspoints eine solche Konfiguration eher nicht einsetzen. Im Gegensatz dazu wäre das allerdings meine favorisierte Lösung, wenn ich selber an den 2 Standorten der Herr der Netzwerke bin, zum Beispiel einmal beim Netzwerk zuhause und einmal beim Netzwerk in meinem beruflich notwendigen Zweitwohnsitz.

Darüber hinaus hat dieses Bridging-Setup durchaus noch einige Überraschungen parat. So ist es z.B. auf einem heimischen Dual-Stack-Account durchaus möglich, dass durch den IPv4-Tunnel über die Link-Local-IP des TAP-Devices auch das Neighbor Discovery Protocol (NDP (Router Solicitation und Router Advertisement)) übertragen wird und somit das Tap-Device des Clients eine IPv6 passend zur Site-ID des heimischen Netzwerks erhält. In dem Fall kann es passieren, dass bei einer Web-Abfrage der eigenen IP-Adressen bei IPv4 die öffentliche IP des örtlichen Internets angezeigt wird und für IPv6 eine Site-ID aus dem Heimnetzwerk…. im Endeffekt auf diesen Aspekt bezogen also sogar mit 2 unterschiedlichen DSL-Providern. Für das eigentliche Ziel, die Integration des Clients via Tunnel ins heimische Netzwerk mit Zugriff auf die dortigen Ressourcen, ist dieses zusätzliche Verhalten für mich allerdings irrelevant, weil das eigentliche Ziel erreicht wurde.

Um das hier also noch einmal deutlich abzugrenzen: Will ich den vollständigen Datenverkehr eines mobilen Clients durch den Tunnel schicken, also gleichzeitig Internet und auch für den Zugriff auf die heimischen Netzwerk-Ressourcen und will ich zudem auch noch Android-Geräte verwenden, ist Routing meiner Meinung nach die bessere bzw. sogar einzige Wahl. Für dieses Ziel einer zeitweisen Ad-hoc-Verbindung spielt es auch keine Rolle, ob ich eine IP aus dem Heimnetzwerk erhalte oder via NAT geroutet werde…. das Ergebnis ist für mich und mein mobiles Client-Gerät funktional betrachtet das gleiche. Natürlich besteht auch beim Routing die Möglichkeit, den Tunnel ins Heimnetz und den Datenverkehr ins Internet über das lokale Netzwerk zu trennen. Das bedeutet, ich greife über den Tunnel zwar auf das Heimnetz zu, aber Zugriffe aufs Internet werden im lokalen Gastgeber-Netz direkt geroutet. Ist es aufgrund ganz besonderer Anforderungen jedoch zwingend notwendig, dass der Client mit LAN-interner IP ins heimische Netzwerk integriert wird, ist Bridging die richtige Wahl. Allerdings, das muss ich gestehen, ich kann mir kein Szenario für mich als Privat-Reisenden vorstellen, wo mir eine solche Installation Vorteile bringen würde…. deshalb verwende ich selber immer und ausschließlich das Routing-Setup.

Bei der Installation eines OpenVPN-Default-Setups aus dem Debian/Raspbian-Repository muss außerdem beachtet werden, dass darüber ein automatischer Start via init.d-Scripte (sysv) eingerichtet wird, was in Konflikt mit dem hier eingeschlagenen Weg steht.

Dieses Tutorial richtet sich an erfahrene Linux-Anwender!

Inhaltsübersicht

> Prämissen  

> Raspian-Lite installieren  

> Basic-Setup Rpi

> Setup Bridge-Device

> Setup OpenVPN-Server

> Setup OpenVPN-Client

> Funktionstest

> Ein wichtiger Hinweis zum Schluss

Anhang:

> Service-Unit für Bridge und DHCP

 

 

Prämissen

IP-Range des lokalen regulären Heimnetzwerks:    10.0.1.0/24

Default-Gateway:                                 10.0.1.1

VPN-Server:                                      10.0.1.200

VPN-Client-Range:                                10.0.1.201-10.0.1.210

ETH-NIC-Name:                                    eth0

Bridge-NIC-Name:                                 br0

UDP-Port:                                        55553

 

- Setup eines Raspberry PI als  (zunächst) dedizierten VPN-Server ohne User-Interaktion und ohne grafisches Environment

- Integration von mobilen Clients in das heimische Netzwerk via Bridging durch einen VPN-Tunnel

- Normaler Traffic des Clients ins Internet wird über das lokale Netzwerk geroutet (nicht durch Tunnel)

- Aktive Verbindung via Patchkabel über Kabelinterface (eth0) ist zur Erst-Einrichtung zwingend notwendig

- Alle unbenötigten Dienste werden aus Sicherheitsüberlegungen deaktiviert

- Die Netzwerk-Connectivity wird vollständig direkt eingerichtet

 
 

 

Hinweise:                                        Bei allen Schritten nur dann mit dem nächsten Schritt

                                                 fortfahren, wenn der vorherige keine Fehler verursacht hat!

 

                                                 CLI-Prompt:   $ = normaler User

                                                               # = root

 

                                                 Kommentare!

                                                 Beachten!  

                                                 Auf lokale Gegebenheiten anzupassender Parameter

 

                                                 ne = Nice Editor

                                                      strg-s = save file

                                                      strg-q = quit

 

 

 

 

Mein PC zum Durchführen aller Arbeiten

$ lsb_release -a

Distributor ID: Debian

Description:    Debian GNU/Linux 10 (buster)

Release:        10

Codename:       buster

 

$ date

Sa 14. Mär 12:07:31 CET 2020

 

 

Raspian-Lite installieren

$ su -

 

# cd /media/Install/Images

 

# wget -c "https://downloads.raspberrypi.org/raspbian_lite_latest" -O raspbian_buster_lite_latest.zip

--2020-03-13 19:14:30--  https://downloads.raspberrypi.org/raspbian_lite_latest

Wird in »raspbian_buster_lite_latest.zip« gespeichert.

raspbian_buster_lite_latest.zip   100%[=============================================>] 433,01M  5,79MB/s    in 14s    

2020-03-13 19:14:44 (1,93 MB/s) - »raspbian_buster_lite_latest.zip« gespeichert [454047405/454047405]

 

# mkdir /tmp/rp

# cd /tmp/rp

# unzip /media/Install/Images/raspbian_buster_lite_latest.zip

Archive:  raspbian_buster_lite_latest.zip

inflating: 2019-06-20-raspbian-buster-lite.img

# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,UUID,TYPE

NAME   FSTYPE   SIZE MOUNTPOINT  LABEL     UUID           TYPE

sda           238,5G                                      disk

└─sda1 ext4   208,6G /           debian10  6c5dbab8-40680 part

sdb           465,8G                                      disk

└─sdb1 ext4     500G /media/sdb1           33daf003-08ac5 part

sdc             7,5G                                                            disk

├─sdc1 vfat     256M /media/sdc1 boot      F661-303B      part

└─sdc2 ext4     7,2G /media/sdc2 rootfs    8dfa-47f4      part

 

Device mit Card-Reader/Writer für SD-Card ermitteln

 

<<<=====

# umount /media/sdc*

 

# ls *lite.img

-rw-r--r-- 1 thomas thomas 2,1G 2019-06-20 02:21 2019-06-20-raspbian-buster-lite.img

 

# dd bs=1M if=2020-02-13-raspbian-buster-lite.img of=/dev/sdc status=progress

2191523840 bytes (2,2 GB, 2,0 GiB) copied, 80 s, 27,4 MB/s

2096+0 Datensätze ein

2096+0 Datensätze aus

2197815296 bytes (2,2 GB, 2,0 GiB) copied, 103,626 s, 21,2 MB/s

# sync

# df

Dateisystem             Typ      Größe Benutzt Verf. Verw% Eingehängt auf

/dev/sdc1               vfat      253M     40M  213M   16% /media/sdc1

/dev/sdc2               ext4      1,8G    995M  669M   60% /media/sdc2

# touch /media/sdc1/ssh                                                          

# umount /dev/sdc1; umount /dev/sdc2

# exit

$

<<<===== vfat

 

// RPi mit neuer Karte booten und IP-Adresse über DSL-Router ermitteln, hier = 10.0.1.56

 

$ ping 10.0.1.56 -c 3

PING 10.0.1.56 (10.0.1.56) 56(84) bytes of data.

64 bytes from 10.0.1.56: icmp_seq=1 ttl=64 time=0.429 ms

64 bytes from 10.0.1.56: icmp_seq=2 ttl=64 time=0.462 ms

64 bytes from 10.0.1.56: icmp_seq=3 ttl=64 time=0.410 ms

$ ssh pi@10.0.1.56 -p 22  

pwd = raspberry

 

 

Basic-Setup RPi

$ lsb_release -a

Distributor ID: Raspbian

Description:    Raspbian GNU/Linux 10 (buster)

Release:        10

Codename:       buster

 

$ sudo su -

# passwd

# adduser toml

# dpkg-reconfigure tzdata

# dpkg-reconfigure locales

root shell

root-pwd setzen

neuer Default-User

Europa / Berlin

de.de utf8

# hostnamectl set-hostname tomsvpngw

# cat /etc/hostname

tomsvpngw

Hostname beschreibt die Bestimmung

# systemctl reboot

$ ssh toml@10.0.1.56 -p 22

$ su -

Wichtig!!!

# deluser pi                                                            

# apt purge --remove sudo rsyslog avahi-daemon

Sicherheitsrisiken und Müll beseitigen

 

# ip link show | grep -i broadcast

2: enp1s0: <BROADCAST,MULTICAST> mtu 1500 …

3: wlanx00c0ca8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 …

NIC-Names prüfen! Alle Netzwerkinterfaces sind entsprechend dieser Anleitung mit Bindung an die MAC-Adresse (s.u.) umzubenennen. Sofern weitere Interfaces mit Möglichkeiten zu Namenskonflikten installiert sind, sind alle in eindeutiger Reihenfolge ebenfalls eindeutig mit MAC-Bindung zu benennen. Das gilt auch für Devices, die schon von vornherein die korrekte Bezeichnung hatten.

# ip link show                                                          

MAC-Adressen mit ip-Command ermitteln. Bei externen USB-Devices ggf. nacheinander einstecken und dann jeweils mit ip link show eindeutig identifizieren.

# nano /etc/systemd/network/10-eth0.link

[Match]

MACAddress=aa:bb:cc:dd:ee:ff                                        

                                                                     

[Link]                                                              

Name=eth0

Jedes Netzwerkinterface wird mit seiner Bezeichnung an die MAC-Adresse gebunden. Falls das NIC jetzt schon mit eth0 bezeichnet ist, kann diese Maßnahme übersprungen werden.

An jede der 3 Link-Dateien als letzte Zeile eine Leerzeile anfügen!

# nano /etc/systemd/network/11-wlan-client.link

[Match]

MACAddress=ab:cd:ef:12:34:56

Type=wlan

 

[Link]

Name=wlan0

WLAN-Interface (wird hier nur der Vollständigkeit wegen beachtet, ohne das es hinterher hier im Tutorial verwendet wird)

# systemctl reboot                                                      

                                                                       

Geänderte Bezeichnungen sind erst nach Reboot aktiv. Externe WLAN-Devices sollten jetzt angeschlossen sein!

 

$ ssh toml@10.0.1.56 -p 22

$ su -

 

 

# ip link show | grep -i broadcast

2: eth0: <BROADCAST,MULTICAST> mtu 1500  ...  

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...  

Netzwerk einrichten. Unbedingt sorgfältig arbeiten! Fehler können dazu führen, dass das Netzwerk beim Boot nicht startet und Fehler anschließend direkt auf der SD-Card korrigiert werden müssen.

 

Bezeichnung der Devices kontrollieren. Wenn fehlerhaft, dann gemäß der Anleitung oberhalb mit Bindung an MAC-Adresse korrigieren.

# nano /etc/systemd/system/network.service

[Unit]

Description=thlu:network.service:     Start network connectivity

After=basic.target

Before=network.target shutdown.target

Wants=network.target

Conflicts=shutdown.target

 

[Service]

Environment="PATH=/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"

Type=oneshot

RemainAfterExit=yes

 

ExecStartPre=ip link set dev eth0 up

ExecStart=dhclient -4 eth0

 

ExecStop=dhclient -r eth0

ExecStopPost=ip link set dev eth0 down

 

[Install]

WantedBy=multi-user.target

 

Diese Service-Unit ist nur eine Zwischenlösung, damit nach dem Ausplanen aktiver Netzwerk-Services (siehe unterhalb) trotzdem eine Netzwerkverbindung hergestellt werden kann.

An diese und jeder folgenden Service-Unit immer als letzte Zeile eine Leerzeile anfügen!

# cd /etc/systemd/system

# systemctl start network.service

Neue Netzwerkverbindung aktivieren

Teststart, um auf Fehler zu prüfen

# systemctl status network.service

● network.service - thlu:network.service:     Start network connectivity

   Loaded: loaded (/etc/systemd/system/network.service; enabled; vendor preset: enabled)

   Active: active (exited) since Wed 2020-03-25 16:55:12 CET; 4s ago

  Process: 521 ExecStartPre=/sbin/ip link set dev eth0 up (code=exited, status=0/SUCCESS)

  Process: 522 ExecStart=/sbin/dhclient -4 eth0 (code=exited, status=0/SUCCESS)

 Main PID: 522 (code=exited, status=0/SUCCESS)

    Tasks: 1 (limit: 2200)

   Memory: 3.5M

   CGroup: /system.slice/network.service

           └─523 /sbin/dhclient -4 eth0

Mär 25 16:55:11 tomsvpngw systemd[1]: Starting thlu:network.service:     Start network connectivity...

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPOFFER of 10.0.1.56 from 10.0.1.1

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPREQUEST for 10.0.1.56 on eth0 to 255.255.255.255 port 67

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPACK of 10.0.1.56 from 10.0.1.1

Mär 25 16:55:11 tomsvpngw dhclient[522]: RTNETLINK answers: File exists

Mär 25 16:55:12 tomsvpngw dhclient[523]: bound to 10.0.1.56 -- renewal in 429397 seconds.

Mär 25 16:55:12 tomsvpngw systemd[1]: Started thlu:network.service:     Start network connectivity.

# systemctl enable network.service

Created symlink /etc/systemd/system/multi-user.target.wants/network.service → /etc/systemd/system/network.service.

 

 

# cd /

# find /etc -iname "*networking" -print

/etc/rc0.d/K01networking

/etc/rc6.d/K01networking

/etc/rcS.d/S01networking

/etc/default/networking

/etc/init.d/networking

Alte Verbindung gefunden = sysv = obsolet => ausplanen

 

Bei der Ausplanung geht es primär um das Ziel, potentielle Störer von vornherein auszuschalten, sowie überflüssige Services zu deaktivieren.

 

Für Services, die nicht aktiv sind oder möglicherweise gar nicht installiert sind, werden die Schritte übersprungen.

 

Dieses Tutorial funktioniert unter Debian, Raspbian und aller Wahrscheinlichkeit gleichermaßen auch unter Ubuntu oder Arch Linux. Deshalb kann es sein, dass die folgenden Services unterschiedlich auf den Systemen eingerichtet und aktiviert sind.

# systemctl status ifup@eth0.service

● ifup@enp2s0.service - ifup for eth0

Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: enabled)

Active: active (exited) since Sat 2019-06-08

# systemctl mask ifup@eth0.service

Created symlink /etc/systemd/system/ifup@eth0 .service → /dev/null.

# update-rc.d networking remove

# systemctl status networking.service

● networking.service - Raise network interfaces

Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)

Active: active (exited) since Thu 2020-03-05 14:37:31 CET; 21s ago

# systemctl mask networking.service

Created symlink /etc/systemd/system/networking.service → /dev/null.

# find /etc -iname "*networking" -print

/etc/default/networking

/etc/init.d/networking

# systemctl status NetworkManager.service

● NetworkManager.service - Network Manager

Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)

Active: active (running) since Sat 2019-06-08

# systemctl mask NetworkManager.service

Created symlink /etc/systemd/system/NetworkManager.service → /dev/null.

# systemctl status systemd-networkd

● systemd-networkd.service - Network Service

Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)

Active: active (running) since Sat 2019-06-08

# systemctl mask systemd-networkd

Created symlink /etc/systemd/system/systemd-networkd.service → /dev/null.

# systemctl status wpa_supplicant.service

● wpa_supplicant.service - WPA supplicant

Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; enabled; vendor preset: enabled)

Active: active (running) since Thu 2020-03-05 15:01:35 CET; 9min ago)

# systemctl mask wpa_supplicant.service

Created symlink /etc/systemd/system/wpa_supplicant.service → /dev/null.

# systemctl status dhcpcd.service

● dhcpcd.service - LSB: IPv4 DHCP client with IPv4LL support

Loaded: loaded (/etc/init.d/dhcpcd; generated)

Active: active (running) since Thu 2020-03-05 15:01:35 CET; 9min ago

# systemctl mask dhcpcd.service

Created symlink /etc/systemd/system/dhcpcd.service → /dev/null.

# systemctl status triggerhappy.service

● triggerhappy.service - triggerhappy global hotkey daemon

Loaded: loaded (/lib/systemd/system/triggerhappy.service; enabled; vendor preset: enabled)

Active: active (running) since Fri 2020-03-13 20:39:52 CET; 14h ago

# systemctl mask triggerhappy.service triggerhappy.socket

Created symlink /etc/systemd/system/triggerhappy.service → /dev/null.

# systemctl status bluetooth.service

● bluetooth.service - Bluetooth service

Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)

Active: inactive (dead)

# systemctl mask bluetooth.service

Created symlink /etc/systemd/system/bluetooth.service → /dev/null.

# systemctl status networking.service wpa_supplicant.service

# systemctl status network.service

Aufmerksam kontrollieren!

= maskiert

= enabled

# apt update; apt full-upgrade

# echo -e "\nStorage=persistent\nSystemMaxUse=20M\nRuntimeMaxUse=20M\nForwardToSyslog=no\nMaxLevelConsole=warning\n" >>/etc/systemd/journald.conf

# systemctl reboot

 

$ scp "openvpn-2.4.8_buster_armhf.deb" "toml@10.0.1.56:/tmp"

$ scp "openvpn-setup.tar" "toml@10.0.1.56:/tmp"

Vom PC das vorbereitete deb-Package sowie die notwendigen Key-Files (hier im Tar-File enthalten) auf den Raspberry Pi (Server) kopieren, siehe:  http://www.thlu.de/openvpn.html.

 

$ ssh toml@10.0.1.56 -p 22

$ su -

# apt autoremove; apt autoclean

# systemctl status ifup@eth0 networking NetworkManager systemd-networkd wpa_supplicant dhcpcd triggerhappy bluetooth

● ifup@eth0.service

   Loaded: masked (Reason: Unit ifup@eth0.service is masked.)

   Active: inactive (dead)

● networking.service

   Loaded: masked (Reason: Unit networking.service is masked.)

   Active: inactive (dead)

● NetworkManager.service

   Loaded: masked (Reason: Unit NetworkManager.service is masked.)

   Active: inactive (dead)

● systemd-networkd.service

   Loaded: masked (Reason: Unit systemd-networkd.service is masked.)

   Active: inactive (dead)

● wpa_supplicant.service

   Loaded: masked (Reason: Unit wpa_supplicant.service is masked.)

   Active: inactive (dead)

● dhcpcd.service

   Loaded: masked (Reason: Unit dhcpcd.service is masked.)

   Active: inactive (dead)

● triggerhappy.service

   Loaded: masked (Reason: Unit triggerhappy.service is masked.)

   Active: inactive (dead)

● bluetooth.service

   Loaded: masked (Reason: Unit bluetooth.service is masked.)

   Active: inactive (dead)

# dpkg -l mc ne htop bridge-utils

dpkg-query: no packages found matching mc

dpkg-query: no packages found matching ne

dpkg-query: no packages found matching htop

dpkg-query: no packages found matching bridge-utils

Sind notwendige Pakete bereits vorhanden?

  mc   = midnight commander

  ne   = Nice Editor, vor mir bevorzugter Editor

  htop = Taskmanager

  bridge-utils

# apt install mc ne htop bridge-utils

Nur fehlende Pakete installieren!

# dpkg -l libc6 liblz4-1 liblzo2-2 libpam0g libssl1.1 libsystemd0 iproute2 lsb-base openssl

# apt install $(fehlende)

 

 

Setup Bridge-Device

# cd /tmp

# dpkg -i openvpn-2.4.8_buster_armhf.deb

OpenVPN ist zum jetzigen Zeitpunkt notwendig, da das Programm zum Generieren des Tap-Devices von der folgenden Service-Unit gestartet wird. Ohne OpenVPN würde die Unit fehlschlagen und somit auch die Netzwerkverbindung.

# tar -xf openvpn-setup.tar

# mkdir -p /etc/openvpn/keys

# mv /tmp/openvpn/keys /etc/openvpn

# rm -r /tmp/openvpn

# chown -R root:root /etc/openvpn

# chmod 700 /etc/openvpn

# chmod 600 /etc/openvpn/keys/*

Der Zugriff (auch lesend) auf die Keyfiles sowie der OpenVPN-Konfiguration ist ausschließlich ‚root‘ erlaubt.

# adduser vpnuser --no-create-home --gecos "" --disabled-password

Virtueller User, unter dessen UID der OpenVPN-Daemon laufen wird

# ip a s dev eth0 | grep -i "link/ether"

    link/ether b8:27:dd:kk:yz:5d brd ff:ff:ff:ff:ff:ff

MAC-Adresse des physischen NICs zur Übernahme in die Bridge-Konfiguration ermitteln

# ne /etc/systemd/system/network-bridge-static.service

[Unit]

Description=thlu:network-bridge-static.service    Bridged Network for VPN

After=basic.target

Before=network.target shutdown.target

Wants=network.target

Conflicts=shutdown.target

 

[Service]

Environment="PATH=/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"

Type=oneshot

RemainAfterExit=yes

 

ExecStartPre=openvpn --mktun --dev tap0

ExecStartPre=ip link add br0 type bridge

ExecStartPre=ip link set br0 type bridge stp_state 0

ExecStartPre=ip link set br0 type bridge forward_delay 0

ExecStartPre=ip link set br0 address b8:27:dd:kk:yz:5d

ExecStartPre=ip addr add 10.0.1.200/24 dev br0

ExecStartPre=sysctl -w net.ipv6.conf.br0.forwarding=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.disable_ipv6=0

ExecStartPre=sysctl -w net.ipv6.conf.br0.autoconf=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.use_tempaddr=2

ExecStartPre=sysctl -w net.ipv6.conf.br0.accept_ra=2

ExecStartPre=ip link set eth0 master br0

ExecStartPre=ip link set eth0 up

ExecStartPre=ip link set tap0 master br0

ExecStartPre=ip link set tap0 up

ExecStartPre=ip link set br0 up

ExecStartPre=ip route add default via 10.0.1.1

ExecStart   =true

 

ExecStop    =ip link set tap0 nomaster

ExecStopPost=ip link set tap0 down

ExecStopPost=ip addr flush dev tap0

ExecStopPost=openvpn --rmtun --dev tap0

ExecStopPost=ip link set eth0 nomaster

ExecStopPost=ip link set eth0 down

ExecStopPost=ip addr flush dev eth0

ExecStopPost=ip link set br0 down

ExecStopPost=ip addr flush dev br0

ExecStopPost=ip link del br0 type bridge

 

[Install]

WantedBy=multi-user.target

Service-Unit zum Starten des Netzwerkes

 

 

 

 

 

 

 

 

 

 

 

--mktun erzeugt eigentlich ein persistentes TAP-Device... sollte es, eigentlich. Aber aufgrund von wiederholten Unstimmigkeiten habe ich mich entschieden, das bei Systemstart explizit zu veranlassen

MAC-Adresse synchronisieren und statische IP-Adresse aus lokalen Netzwerk vorgeben (siehe oben Prämissen)

 

 

 

 

 

 

 

 

 

Default-Gateway

# ne /etc/sysctl.d/ip_setup.conf

net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1

 

net.ipv6.conf.default.disable_ipv6=0

net.ipv6.conf.default.forwarding=1

net.ipv6.conf.default.autoconf=0

net.ipv6.conf.default.use_tempaddr=0

net.ipv6.conf.default.accept_ra=0

 

net.ipv6.conf.eth0.disable_ipv6=1

net.ipv6.conf.eth0.forwarding=1

net.ipv6.conf.eth0.autoconf=0

net.ipv6.conf.eth0.use_tempaddr=0

net.ipv6.conf.eth0.accept_ra=0

Konfigruation der Interfaces für TCP/IP-Handling:

- Forwarding für alle Interfaces erlauben

- IPv6 default erlauben, aber ausdrücklich für eth0 verbieten

 

eth0 bekommt keine IPv4-Adresse, mit dem ‚disable‘ wird sichergestellt, dass auch der Kernel keine IPv6-Adresse via SLAAC generiert.

 

Das neue Bridge-Interface ‚br0‘ erhält sowohl eine aktive manuell zugewiesene Static-IPv4 aus dem LAN, als auch bei Verfügbarkeit von IPv6 eine durch SLAAC generierte öffentliche IPv6.

 

In reinen IPv4-Umgebungen sollten diese Einstellungen trotzdem keine negativen Auswirkungen haben.

# systemctl disable network.service

# systemctl enable network-bridge-static.service

# systemctl reboot

 

 

Setup OpenVPN-Server

$ ping 10.0.1.200 -c 3

PING 10.0.1.200 (10.0.1.200) 56(84) bytes of data.

64 bytes from 10.0.1.200: icmp_seq=1 ttl=64 time=0.433 ms

64 bytes from 10.0.1.200: icmp_seq=2 ttl=64 time=0.442 ms

64 bytes from 10.0.1.200: icmp_seq=3 ttl=64 time=0.409 ms

$ ssh toml@10.0.1.200 -p 22

$ su -

Achtung: Neue statische IP = 200. Bridge = OK?

# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000

    link/ether b8:27:dd:kk:yz:5d brd ff:ff:ff:ff:ff:ff

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

    link/ether b8:27:dd:kk:yz:5d brd ff:ff:ff:ff:ff:ff

    inet 10.0.1.200/24 scope global br0

       valid_lft forever preferred_lft forever

    inet6 2003:z2b9:ybcv:x344:5d3:3661:e819:c4f6/64 scope global temporary dynamic

       valid_lft 6672sec preferred_lft 3072sec

    inet6 2003:z2b9:ybcv:x344:ba27:ebff:feee:dd5d/64 scope global dynamic mngtmpaddr

       valid_lft 6672sec preferred_lft 3072sec

    inet6 fe80::ba27:ebff:feee:dd5d/64 scope link

       valid_lft forever preferred_lft forever

# ne /etc/openvpn/server_udp_br.conf

server-bridge 10.0.1.200 255.255.255.0 10.0.1.201 10.0.1.210

#client-to-client

 

proto udp

dev tap0

port 55553

 

ca   /etc/openvpn/keys/ca.crt

cert /etc/openvpn/keys/server.crt

key  /etc/openvpn/keys/server.key

 

cipher AES-256-GCM

auth SHA256

auth-nocache

 

dh /etc/openvpn/keys/dh.pem

ecdh-curve secp384r1

tls-version-min 1.3

tls-crypt /etc/openvpn/keys/ta.key

 

ping-timer-rem

keepalive 10 60

persist-key

persist-tun

group vpnuser

user vpnuser

 

verb 3

mute 10

log-append /var/log/openvpn/openvpn_udp.log

OpenVPN-Konfiguration:

Sollen örtlich voneinander getrennte VPN-Clients auch untereinander kommunizieren können, muss der Comment-Tag ‚#‘ bei dieser Zeile entfernt werden.

Sofern die Datei-Namen der Key-Files anders lauten, entweder die Conf anpassen oder Symlinks erstellen, z.B.:

# cd /etc/openvpn/keys

# ln -s RaspiSrv.key server.key

# ln -s RaspiSrv.crt server.crt

# ln -s dh4096.pem dh.pem

# ne /etc/systemd/system/openvpn.service

Service-Unit für den Start des OpenVPN-Servers beim Systemstart.

[Unit]

Description=thlu:openvpn.service   Start a OpenVPN-Daemon

After=network-bridge-static.service

Requires=network-bridge-static.service

 

[Service]

Type=forking

PIDFile=/var/run/openvpn/pid

 

ExecStartPre=/bin/mkdir -p /var/run/openvpn

ExecStartPre=/bin/mkdir -p /var/log/openvpn

ExecStartPre=/bin/chmod 770 /var/log/openvpn

ExecStartPre=/bin/chown root:vpnuser /var/log/openvpn

ExecStartPre=/bin/sleep 2

ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/pid --status /var/run/openvpn/status 60 --config /etc/openvpn/server_udp_br.conf

 

KillMode=process

 

[Install]

WantedBy=multi-user.target

 

Setup OpenVPN-Client

Die Installations-Schritte sind bis auf ein unterschiedliches Konfigurationsfile sowie unterschiedliche Keyfiles (Client != Server) identisch... Symlinks siehe also oberhalb beim Server.

# ne /etc/openvpn/client_udp_br.conf

tls-client

remote-cert-tls server

remote myprivateddnslink.net

 

proto udp

port 55553

 

dev tap0

lladdr 02:b8:39:89:5d:30  

 

pull

ping 60

 

cipher AES-256-GCM

auth SHA256

auth-nocache

 

ca        /etc/openvpn/keys/ca.crt

cert      /etc/openvpn/keys/client.crt

key       /etc/openvpn/keys/client.key

tls-crypt /etc/openvpn/keys/ta.key

 

mute 10

verb 3

explicit-exit-notify

log-append /var/run/openvpn/client.log

--remote-cert-tls stellt sicher, dass der angesprochene Server auch wirklich der ist, der er sein soll und nicht ein fremdes System, was sich als Server ausgibt. Dieser Parameter ist ein Sicherheitsparameter.

Im Regelfall generiert OpenVPN bei der Erstellung eines TAP-Devices jedesmal eine zufällige MAC-Adresse für das Device. Das ist meistens unkritisch, kann allerdings dann aber auch zu Problemen führen, wenn man in seinem heimischen DSL-Router für gerouteten Internet-Verkehr für alle neuen Geräte die Default-Einstellung „Gesperrt“ eingerichtet hat. In dem Falle, wäre der VPN-Client jedesmal wegen einer neuen MAC-Adresse ein neues Gerät und wäre somit per Default blockiert. Das kann man mit einer statischen MAC umgehen, die man sich einmalig via Random-Device selbst erzeugt:

$ hexdump -vn5 -e '/5 "02"' -e '/1 ":%02x"' -e '"\n"' /dev/urandom

  02:b8:39:89:5d:30

Die 02 im ersten Segment ist eine Besonderheit, aber nicht zwingend. Ich habe die 02  einfach aus Bequemlichkeit gewählt, um die beiden ‚Least Significant Bits‘ im ersten Byte zu setzen.

Bit 0   ist  ein "multicast bit“, was anzeigt, das ist eine multicast oderr broadcast adresse

Bit 1   ist "local bit“, was anzeigt, die MAC ist nicht „assigned by vendor“ und deshalb möglicherweise nicht unique.

Somit ist das erste Segment der IP  wie folgt gesetzt: 02 = 0000 0010

 

 

Funktionstest

Der Funktionstest findet als manuell durchgeführter Test statt. Weil sowohl in der Server- als auch der Client-Conf explizite Log-Datei-Angaben gesetzt sind, sind dazu vorher einige Vorbereitungen durchzuführen.

Für den Test verwende ich neben dem RPi als stationären VPN-Server mein Smartphone, um darüber via Tethering einen WLAN-Accesspoint zur Verfügung zu stellen. Das bedeutet, das Handy ist über „mobile Daten“ mit dem Internet verbunden und öffnet gleichzeitig quasi als WLAN-Router einen WLAN-Zugang für meinen mobilen Laptop. Damit ist eine Testumgebung hergestellt, wie ich sie auch auf Reise ständig erlebe. Den eigentlichen Verbindungs-Test zum Heimnetzwerk führt nun als OpenVPN-Client mein Laptop durch, der sich über das Handy-Netzwerk und damit über eine Internetverbindung mit dem Raspi verbindet.

Sowohl auf dem Server als auch auf dem Laptop (auf beiden ist hier das aktuelle Debian ‚Stable‘ installiert) werden jeweils 2 Terminals geöffnet, einmal zur fließenden Anzeige des lokalen VPN-Logs, das zweite zum Starten und Beenden von OpenVPN. Zum Raspi öffne ich für diesen Zweck 2 SSH-Sitzungen, auf dem Laptop bin ich direkt angemeldet. Die beiden Terminal-Fenster sollten jeweils so angeordnet werden, dass sie beide gleichzeitig sichtbar sind, wobei man das Log-Fenster durchaus großzügiger bemessen kann. Ich lege bei meinen Tests beide Fenster in ganzer Bildschirmbreite übereinander, wobei das obere Log-Fenster etwa ¾ des Bildschirms erhält, der Programm-Aufruf nur ¼ bzw. wegen der Taskbar sogar etwas weniger.

VPN-Server:

$ su -

# mkdir /var/log/openvpn

# touch /var/log/openvpn/openvpn_udp.log

# tail -f /var/log/openvpn/openvpn_udp.log

Log-Anzeige im ersten Terminal des Servers

# openvpn --config /etc/openvpn/server_udp_br.conf

Start des Programms im zweiten Terminal des Servers

 

Terminal

Mon Mar 30 14:32:56 2020 OpenVPN 2.4.8 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 14 2020

Mon Mar 30 14:32:56 2020 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10

Mon Mar 30 14:32:56 2020 Diffie-Hellman initialized with 4096 bit key

Mon Mar 30 14:32:56 2020 ECDH curve secp384r1 added

Mon Mar 30 14:32:56 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key

Mon Mar 30 14:32:56 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Mon Mar 30 14:32:56 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key

Mon Mar 30 14:32:56 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Mon Mar 30 14:32:56 2020 TUN/TAP device tap0 opened

Mon Mar 30 14:32:56 2020 TUN/TAP TX queue length set to 100

Mon Mar 30 14:32:56 2020 Could not determine IPv4/IPv6 protocol. Using AF_INET

Mon Mar 30 14:32:56 2020 Socket Buffers: R=[163840->163840] S=[163840->163840]

Mon Mar 30 14:32:56 2020 UDPv4 link local (bound): [AF_INET][undef]:55553

Mon Mar 30 14:32:56 2020 UDPv4 link remote: [AF_UNSPEC]

Mon Mar 30 14:32:56 2020 GID set to vpnuser

Mon Mar 30 14:32:56 2020 UID set to vpnuser

Mon Mar 30 14:32:56 2020 MULTI: multi_init called, r=256 v=256

Mon Mar 30 14:32:56 2020 IFCONFIG POOL: base=10.0.1.201 size=10, ipv6=0

Mon Mar 30 14:32:56 2020 Initialization Sequence Completed

 

VPN-Client:

$ su -

# mkdir /var/run/openvpn

# touch /var/run/openvpn/client.log

# tail -f /var/run/openvpn/client.log

Log-Anzeige im ersten Terminal des Client-Geräts

# openvpn --config /etc/openvpn/client_udp_br.conf

Start des Programms im zweiten Terminal des Client-Geräts

 

Terminal

Mon Mar 30 15:28:44 2020 OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov 13 2019

Mon Mar 30 15:28:44 2020 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10

Mon Mar 30 15:28:44 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key

Mon Mar 30 15:28:44 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Mon Mar 30 15:28:44 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key

Mon Mar 30 15:28:44 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Mon Mar 30 15:28:44 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]189.45.649.808:55553

Mon Mar 30 15:28:44 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]

Mon Mar 30 15:28:44 2020 UDP link local (bound): [AF_INET][undef]:55553

Mon Mar 30 15:28:44 2020 UDP link remote: [AF_INET]189.45.649.808:55553

Mon Mar 30 15:28:45 2020 TLS: Initial packet from [AF_INET]189.45.649.808:55553, sid=44968a94 a552338d

Mon Mar 30 15:29:00 2020 VERIFY OK: depth=1, CN=toml.de

Mon Mar 30 15:29:00 2020 VERIFY KU OK

Mon Mar 30 15:29:00 2020 Validating certificate extended key usage

Mon Mar 30 15:29:00 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

Mon Mar 30 15:29:00 2020 VERIFY EKU OK

Mon Mar 30 15:29:00 2020 VERIFY OK: depth=0, CN=Server

Mon Mar 30 15:29:00 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 384 bit EC, curve: secp384r1

Mon Mar 30 15:29:00 2020 [Server] Peer Connection Initiated with [AF_INET]189.45.649.808:55553

Mon Mar 30 15:29:01 2020 SENT CONTROL [Server]: 'PUSH_REQUEST' (status=1)

Mon Mar 30 15:29:01 2020 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.0.1.200,ping 10,ping-restart 60,ifconfig 10.0.1.201...

Mon Mar 30 15:29:01 2020 OPTIONS IMPORT: timers and/or timeouts modified

Mon Mar 30 15:29:01 2020 OPTIONS IMPORT: --ifconfig/up options modified

Mon Mar 30 15:29:01 2020 OPTIONS IMPORT: route-related options modified

Mon Mar 30 15:29:01 2020 OPTIONS IMPORT: peer-id set

Mon Mar 30 15:29:01 2020 OPTIONS IMPORT: adjusting link_mtu to 1656

Mon Mar 30 15:29:01 2020 OPTIONS IMPORT: data channel crypto options modified

Mon Mar 30 15:29:01 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Mar 30 15:29:01 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Mar 30 15:29:01 2020 TUN/TAP device tap0 opened

Mon Mar 30 15:29:01 2020 TUN/TAP TX queue length set to 100

Mon Mar 30 15:29:01 2020 /usr/sbin/ifconfig tap0 hw ether 02:b8:39:89:5d:30

Mon Mar 30 15:29:01 2020 TUN/TAP link layer address set to 02:b8:39:89:5d:30

Mon Mar 30 15:29:01 2020 /usr/sbin/ifconfig tap0 10.0.1.201 netmask 255.255.255.0 mtu 1500 broadcast 10.0.1.255

Mon Mar 30 15:29:01 2020 Initialization Sequence Completed

 

Sofern weder beim Start von OpenVPN auf den beiden Systemen Fehlermeldungen berichtet wurden, noch beim Herstellen der Verbindung, die Verbindung  offensichtlich funktioniert und die Systeme untereinander sowie zu und von anderen Clients vollständig erreichbar waren, kann nun der Server ‚produktiv‘ gesetzt werden.

# systemctl enable openvpn.service

# systemctl start openvpn.service

Sofern der Verbindungs-Test erfolgreich durchgeführt war und die manuellen Starts beendet sind, kann der VPN-Server nur für den Systemstart aktiviert und sofort als Daemon gestartet werden.

 

 

 

Ein wichtiger Hinweis zum Schluss!

Das hier beschriebene Bridging-Modell für einen OpenVPN-Tunnel ins Heimnetzwerk benötigt für die reine Funktion der Verbindung von außerhalb über das Internet zum Heimnetzwerk keine Paketfilter-Regeln. Das bedeutet, Einstellungen für iptables oder nftables sind nicht notwendig. Aber, und das ist der wichtigste Hinweis: Man sollte in seinem eigenen Interesse auf gar keinen Fall sein mobiles Gerät einfach so an einem fremden Gastgeber-Netzwerk (Restaurants, Cafes, Hotels oder irgendwo in der City an zufällig gefundenen offenen WLAN-Netze) ohne Schutzmaßnahmen anmelden und verbinden, wenn die Absicht besteht, anschließend einen VPN-Tunnel via Bridging nachhause zu öffnen. Schlimmstenfalls hat man damit eine Durchmarsch-Route für fremde und ebenfalls im im Gastgeber-Netz aktive Geräte bis hin in sein eigenes Netzwerk zuhause eröffnet.

 
 

Aber die notwendigen Firewall-Regeln, um solche Gefahren zu eliminieren, können natürlich hier aufgrund des kritischen Umfangs der möglichen Security-Verstöße kein Thema sein. Das Einrichten restriktiver Firewall-Regeln, deaktivieren unbenötigter Services, restriktive User-Berechtigungen, beschränken von ‚lauschenden Diensten‘ und weitergehende Erklärungen habe ich im Artikel Security beschrieben.

Und ja, man kann diese Hinweise natürlich auch ignorieren und sich selbstherrlich über berechtigte Warnungen hinwegsetzen. Nun ja, da kann man nichts machen... Sicherheit existiert jedenfalls nur solange, wie der ‚Admin‘ nicht selber auf Sicherheit verzichtet oder schlimmstenfalls sogar fahrlässig eine vorhandene Sicherheit außer Kraft setzt. Mach Dir einfach bewusst, wenn Du auf eine absolute und exklusive Kontrolle Deines Netzwerk verzichtest, hast Du auch keine Kontrolle darüber, wer die Hardware Deines Netzwerks unerlaubt mitbenutzt und darüber Zugang zu privaten Daten und Ressourcen im Netzwerk hat. Wenn Deine Netzwerkzugänge einmal kompromittiert sind, hast Du auch kaum eine Möglichkeit das im Nachgang noch festzustellen. Irgendwelche Antiviren-Programme können da jedenfalls keinen Schutz herstellen, weil sie solche ausgenutzten Exploits gar nicht feststellen können.

 

 

 

Haftungsausschluss:

Ich erhebe keinen Anspruch darauf, dass diese Dokumentation vollständig fehlerfrei ist und ich behaupte das auch nicht. Sowohl

- durch meine Fehler hier im Tutorial

- wie auch durch vorhandene Fehler in den hier verwendeten Linux-Programmen

- sowie durch ggf. zeitgleich auftretende äußere mechanische Einflüsse

- oder durch den Anwender selber verursacht durch Änderungen an Programmen

- oder durch unsachgemäße oder fehlerhafte Einrichtung der Programme beim Setup, z.B. wegen fehlerhafter  Parameter

kann es zu Datenverlust kommen. Durch unsachgemäße Sicherung und dem Betrieb eines deswegen unsicheren von außen erreichbaren Zugang ins Heimnetzwerk kann sogar das ganze private Netzwerk kompromittiert werden.

Deshalb schließe ich jede Haftung für Schäden an Software oder Hardware oder Vermögensschäden oder für Datenverlust aus, die durch die Benutzung dieses Tutorials enstehen. Die Benutzung dieses Tutorials, die Einrichtung der Services danach und der produktive Einsatz erfolgt auf eigenes Risiko.

 

 

Anhang:

Service-Unit für Bridge und DHCP

# ne /etc/systemd/system/network-bridge-dhcp.service

[Unit]

Description=thlu:network-bridge-dhcp.service    Bridged Network for VPN

After=basic.target

Before=network.target shutdown.target

Wants=network.target

Conflicts=shutdown.target

 

[Service]

Environment="PATH=/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"

Type=oneshot

RemainAfterExit=yes

 

ExecStartPre=openvpn --mktun --dev tap0

ExecStartPre=ip link add br0 type bridge

ExecStartPre=ip link set br0 type bridge stp_state 0

ExecStartPre=ip link set br0 type bridge forward_delay 0

ExecStartPre=ip link set br0 address b8:27:dd:kk:yz:5d

ExecStartPre=sysctl -w net.ipv6.conf.br0.forwarding=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.disable_ipv6=0

ExecStartPre=sysctl -w net.ipv6.conf.br0.autoconf=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.use_tempaddr=2

ExecStartPre=sysctl -w net.ipv6.conf.br0.accept_ra=2

ExecStartPre=ip link set eth0 master br0

ExecStartPre=ip link set eth0 up

ExecStartPre=ip link set tap0 master br0

ExecStartPre=ip link set tap0 up

ExecStartPre=ip link set br0 up

ExecStartPre=dhclient -v br0

ExecStart   =true

 

ExecStop    =ip link set tap0 nomaster

ExecStopPost=ip link set tap0 down

ExecStopPost=ip addr flush dev tap0

ExecStopPost=openvpn --rmtun --dev tap0

ExecStopPost=ip link set eth0 nomaster

ExecStopPost=ip link set eth0 down

ExecStopPost=ip addr flush dev eth0

ExecStopPost=ip link set br0 down

ExecStopPost=ip addr flush dev br0

ExecStopPost=ip link del br0 type bridge

 

[Install]

WantedBy=multi-user.target

Alternative Service-Unit zum Starten des Netzwerkes, die hier nicht als Static-IP-Setup, sondern mit IP via DHCP-Server realisiert ist.

 

 

 

 

 

 

 

 

 

< Startseite >