Hallo Thomas,
puh, wo soll ich jetzt anfangen? Erst einmal mit dem Allgemeinen.
Sollte kein Problem darstellen, außer dass den nicht deutschsprachigen Usern einiges entgeht. Sorry, aber das Thema ist mir zu komplex, um es in Englisch abzuhandeln. Wenn es Probleme geben sollte, kläre ich das mit Fourdee, wir finden da bestimmt eine Lösung.
Nein, bin keine Entwickler, Coder oder Programmierer. Bin auch “nur” Nutzer, der versucht, sich hier einzubringen und weiterzuhelfen.
Der Hauptentwickler ist Fourdee (Daniel Knight) unterstützt zur Zeit von Rhkean u. xenfomation. Hier nachzulesen: GitHub - Fourdee/DietPi: Lightweight justice for your single-board computer!
Die Entwicklung findet auf github statt. Auch dort ist jeder herzlich eingeladen mitzuwirken, auch das Melden von Bugs u. Fehlern hilft immer weiter.
Vielen Dank dafür, besonders im Namen von Fourdee, der jegliche Unterstützung wirklich benötigt.
Der ganze Spaß hier, trägt sich in keinster Weise. Selbst die Entwickler-Board sind zum größten Teil durch die Entwickler selbst finanziert.
Zu deinen Fragen.
Vorausschicken möchte ich, dass Windows, WINS, Samba nicht meine Baustellen sind, da ich selber versuche um Windows einen Bogen zu machen.
Bei Routern ist das ähnlich. FritzBox ist auch nicht mein bevorzugtes Gerät. Aber egal.
Den iptables und NAT Ansatz hatte ich gewählt, weil da nicht am Gateway Router (hier: Fritzbox) u. VPN Server Konfiguration (hier XU4) etwas zusätzlich zu ändern wäre.
Diese Änderungen bedingen meist jeweils einen Geräte-Neustarts oder Neustart des Services.
An der Text Datei für die Clients kann man jederzeit einfach u. schnell etwas ändern/ergänzen.
Daher habe ich die meisten Änderungen, die man auch zentral auf dem VPN Server machen kann und mittel “push” verteilen, in der Client Config vorgenommen.
Forwarding auf der FritzBox zum XU4 hin von UDP Port 1194 sollte ausreichen, Mehr benötigt du nicht, laut deiner aktuellen Konfigurationen.
Man sollte darüber nachdenken, am Ende, wenn alles zufriedenstellend läuft, 443 TCP u. 943 TCP wieder zu deaktivieren (aus Gründen der Sicherheit).
Es sei denn du benötigst das für etwas anderes auf dem XU4.
Gehe davon aus, dass ich deinen grundsätzlichen Netzaufbau im LAN soweit grob verstanden habe.
Serverkonfig: (mit zusätzlichen Kommentaren)
### VPN Server lauscht nur auf UDP Port 1194
port 1194
proto udp
### Läuft im Tunnel Modus auf Layer3, also Kommunikation nur IP basiert möglich (Routing)
### KEINE Layer2 Verbindung (Bridging) auf Ethernet Ebene
dev tun
ca ca.crt
cert DietPi_OpenVPN_Server.crt
key DietPi_OpenVPN_Server.key
dh dh1024.pem
### VPN Server Netz Adresse, nutzbare IPs von 10.8.0.1 bis 10.8.0.254
#### Der Server hat immer die 10.8.0.1 als IP, während die Clients ihre IPs fortlaufend zugeteilt bekommen.
server 10.8.0.0 255.255.255.0
### Daten von VPN-Client zu VPN-Client wird direkt in OpenVPN weitergeleitet
client-to-client
### Alle 10 Sekunden pingen. 1 Minuten Timeout fuer Clientverbindung
### bei UMTS/LTE Verbindung kann es notwendig werden, die ping Zeit zu verringern, da UDP genutzt wird (Connection Tracking)
keepalive 10 60
### Komprimierung einschalten und festlegen
comp-lzo
max-clients 10
user nobody
group nogroup
### die Key-Dateien werden nicht neu gelesen bei Neuverbindung
### TUN/TAP-Device wird nicht geschlossen und neugestartet
persist-key
persist-tun
### Logging Pfade und Log Level
verb 3
status /var/log/openvpn-status.log
log-append /var/log/openvpn
### Den Client über das Server-LAN informieren (wichtig! - wenn kein NAT zum LAN genutzt wird)
### In dem Fall muss eine Rückroute auf dem Default Gateway (Fritzbox)
### auf dem Router: Netzwerk 10.8.0.0, Subnet 255.255.255.0, Gateway 192.168.178.69 zwingend gesetzt werden
### damit die Clients im LAN den VPN Clients antworten können (über ihr Default Gateway, bei dir die FritzBox)
push "route 192.168.178.0 255.255.255.0"
### Aktiviert den OpenVPN Server als Standard Gateway auf den Clients
push "redirect-gateway def1"
## DNS Server meines Providers
# push "dhcp-option DNS X.X.X.X"
# push "dhcp-option DNS X.X.X.X"
#### kann man so machen, da die FritzBox aber bestimmt der DNS Server für dein LAN ist,
#### würde ich auch diesen DNS Server pushen, da sonst teilweise die DNS Auflösung für das LAN nicht funktionieren wird. (Bsp: fritz.box)
# push "dhcp-option DNS 192.168.176.1"
## Adresse des XU4 auf dem VPN
### push "dhcp-option DNS 10.8.0.5"
### Der VPN Server selbst hat die IP 10.8.1.0
#### kann man sich auch mittels " ip a | grep tun " anzeigen lassen
push "dhcp-option WINS 192.168.178.69"
##### legt die TCP/IP-Eigenschaften vom TAP-Adapter fest. Zur Zeit wird aber in den Configs auf Server u. Client TUN verwendet!
##### Die Option ist sehr hilfreich, wenn ein Samba-Server via VPN erreicht werden soll.
push "dhcp-option DOMAIN name" # "name" legt den Verbindungsspezifischen DNS-Suffix fest.
und hier der Client (mit zusätzlichen Kommentaren):
### siehe VPN Server Config oben
client
proto udp
dev tun
#Ip/Domain name of DietPi system, running OpenVPN server.
remote meindynhost 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
#### die Route wird anhand des Shells-Befehls “route.exe” angesetzt (geht nur bei Windows Clients)
### kannst du dir mit "route print" in der Windows cmd.exe auch anzeigen lassen
route-method exe
### OpenVPN wartet 30 Sekunden lang nach dem Tunnelaufbau, bevor eine Route angesetzt wird.
### Würde sagen das ist heftig lange. 2, 5, 10 Sekunden dürften dicke genügen.
### Macht man sowieso nur damit, damit die Windows Routing Tabelle bei langsamen Rechnern nicht aus dem Tritt kommt.
route-delay 30
### Würde ich nicht setzen, die Metrik setzt Windows über "route.exe" schon korrekt
### auch wenn die Routing Tabelle auf den ersten Blick etwas seltsam anmutet
# route-metric 512
### Hier wird die Default Route zusätzlich noch einmal gesetzt
### Kann man machen, schadet nicht, aber eigentlich ist dies schon über den Server via
#### ' push "redirect-gateway def1" ' geschehen
route 0.0.0.0 0.0.0.0
ns-cert-type server
### Komprimierung einschalten und festlegen
comp-lzo
### Log-level Client
verb 3
<ca>
-----BEGIN CERTIFICATE-----
Du kannst einmal versuchen, Server und Client von “dev tun” auf “dev tap” umzustellen,
damit der Parameter " push "dhcp-option DOMAIN name ".
“name” wäre dabei der von dir gewählte lokale (WINS) Domain Name.
Eigentlich läuft WINS ab Win2000 auf Port 445 TCP allein, also auf Layer3 siehe auch :
http://www.elektronik-kompendium.de/sites/net/0901151.htm
und
Aber manches mal macht Windows auch seltsame andere Sachen …
Bitte dran denken, nach jeder Änderung an der VPN Server Konfiguration, ist der VPN Dienst neu zu starten. Zum Beispiel mit
:~# /etc/init.d/openvpn restart
und auf evt. Fehlermeldung ist dabei zu achten.
Doppeltes NAT (MASQUERADE) ist halt die mit dem wenigstens Aufwand zu konfigurierende Lösung. Leider nicht immer die ideale, siehe WINS und Samba Freigaben per Rechnernamen, wenn man auf so etwas wert legt oder es benötigt,
Will nicht verschweigen, dass es in fremden Netzen, als Beispiel bei WLAN öffentlichen HotSpots, Firmennetzen, in UMTS/LTE Mobilfunk-Netz zu Problemen beim Verbindungsaufbau kommen kann. Durch den Einsatz von Capative-Portalen und/oder transparenten Zwangsproxies, Firewalls die Port umleiten oder sperren wird nicht immer ein Verbindungsaufbau via VPN möglich sein. Da bleiben einem dann wenig Möglichkeiten, dies zu beeinflussen.
Weil es in deiner Konfiguration VPN ohne NAT funktioniert. Ist eine reine Routing Lösung. Das benötigt keine iptables Regeln.
route -F -C -n
-
zwischen den beiden direkt am VPN Server verbundenen Netzen (directly connected) routet Linux per default also bei dir zwischen 10.8.0.0/24 und 192.168.178.0/24
\ -
das lokale LAN am VPN Server hinter eth1, erreicht der VPN Client dank ’ push “redirect-gateway def1” ’
-
er wird alles, was nicht 10.8.0.0/24 ist, dem VPN Server IP 10.8.0.1 senden, der dieses dann ins LAN weiter leitet.
-
Damit dies so ist, setzt der VPN Client in seiner Routing-Tabelle eine Metrik (Gewichtung gleichwertiger Routen)
-
Ist die Zieladresse aus dem Bereich 192.168.176.0/24 liefert er es direkt an das Gerät mit der entsprechenden IP aus.
-
Dieses Gerät weiß aber nicht, wo sich die Absende Adresse des VPN Clients 10.8.0.6 befindet.
-
Also muss er es seinem Default Gateway, bei dir die FritzBox, mit der IP 192.168.178.1 senden. Deshalb musst du dort auch die Statische Route für 10.8.0.0/24 auf die LAN IP des VPN Servers 192.168.178.69 setzen.
-
Also wir der Router das Paket des LAN Clients an den VPN Server weiterleiten.
-
Dieser weiß ja, dass sich das Netz hinter der tun0 oder tap0 Schnittstelle befindet. Somit wird er es automatisch durch den VPN Tunnel schieben.
\ -
Internet Zugriff funktioniert ähnlich. Nach der Namensauflösung (DNS) über die FritzBox (funktioniert wie oben im LAN)
-
wird der VPN Client die nun bekannte öffentliche IP Adresse, sagen wir einmal 4.4.4.4 , seinem Default Gateway, der 10.8.0.1 des VPN Servers senden.
-
dieser hat in seiner Routing-Tabelle seinerseits eine Default Route für unbekannt Netze auf die IP der FritzBox 192.168.178.1
-
diese routet das Paket dann ins Internet weiter und ersetzt die Absende Adresse des Clients 10.8.0.6 mit seiner öffentlichen IP Adresse (NAT, um genau zu sein macht dieser PAT, eine Sonderform des Maskieren von IP Adressen)
-
Die Rückroute des Antwortpaketes aus dem Internet auf die ursprüngliche Absende-Adresse 10.8.0.6 erledigt wieder der statische Routing Eintrag in der FritzBox auf die LAN Adresse 192.168.178.69 des VPN Servers
-
den Rest erledigt dann der VPN Server und routet es an den VPN Client.
Bei tap0 (Bridging) hat der VPN Server die IP 10.8.0.1 und verbindet das ganze /24 Subnetz (255.255.255.0) auf Layer2, so wie im LAN.
:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth1
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tap0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
:~# ip a | grep tap
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
inet 10.8.0.1 peer 10.8.0.2/24 scope global tap0
Bei tun0 (Routing) hat der VPN Server die IP 10.8.0.1 und baut zusätzlich mit den Clients ein /30 Subnetz (255.255.255.252) auf. In dieses Netzsegment passen nur zwei Stationen. IP 10.8.0.5 hat dabei der VPN Server und 10.8.0.6 hat der VPN Client.
Zwischen den zwei 10.8.0.x Netzen, routet der VPN Server mittels seiner Routing Tabelle.
:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth1
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
:~# ip a | grep tun
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
Hast du mehrere VPN Clients mit VPN Server gleichzeitig verbunden erlaubt man das routen zwischen den /30 Subnetzen mittels ‘client-to-client’.
Sonst ist es standardmäßig verboten. (Sicherheitsgewinn durch Client Isolation)
Puh, was für ein langer Text.
Muss jetzt erst einmal Pause machen.
Wenn noch Fragen offen, einfach fragen.
cu
k-plan