Important note:
This site will be available completely in English soon.
Dear Fourdee, dear Developers
First I want to thank you for this wonderful piece of software that has been created here. The installation went smoothly without any glitches.
I have a ODROID XU4 including cloud-shell and a 2TB hard drive. On the system running MySQL( Apache…), Samba, OpenVPN. I setup the whole System within 2 hours out of the box. Amazing! The XU4 works as a file server and database server for my electronic components database. I manually expand Samba settings for my needs. I have also forwarded the file paths of the database and the web server on the hard disk.
So far so good. All went fine. But now there is a Problem with OpenVPN. The configuration, described in forum works fine, and I have propper access to my server over VPN. I use a DDNS account and an cable modem from AVM (fritz.box).
I want to have the VPN connection to access my entire internal network. I want to have access to my computers for my home automation system and a camera. Although I possess a basic knowledge of Linux, but very weak on routing. All attempts by the instructions on the OpenVPN website ended up that I could not reach my server from the Internet and/or internal WLAN problems.
At the moment my configuration (router, Odroid) coressponds of the original configuration on the forum.
Does anybody have experience with such issue and have made a appropriate config.
Please excuse my terrible English. It’s very rusty over the years.
Gehe davon aus, du forwardes auf deiner Fritz!Box UDP Port 1194 auf die LAN IP Adresse des XU4.
Hmm, ich mutmaße einmal, du erreichst deinen VPN Server (XU4) durch den VPN Tunnel unter IP: 10.8.0.1 . Korrekt?
Standardmäßig ist in DietPi openVPN als End-to-End-VPN / Host-to-Host-VPN / Remote-Desktop-VPN konfiguriert.
Was möchtest du gerne erreichen? Ein End-to-Site-VPN / Remote-Access-VPN mit lokalen Internet-Zugriff nur mit Internet-Zugriff nur über den VPN Tunnel ?
Welchen Client Betriebssystem setzt du ein? Windows?
Hier einmal ein Beispiel. Zugriff auf den VPN Server, das LAN am VPN Server und das Internet erfolgt dabei nur über den VPN Tunnel.
Der VPN Client ist ein Windows System.
DietPi_OpenVPN_Client.ovpn (editiert):
client
proto udp
dev tun
#Ip/Domain name of DietPi system, running OpenVPN server.
remote dietpi.wan-ip.dyndns 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
## VPN Server ist das Gateway für alle Verbindungen
redirect-gateway def1
## Windows Client spezifisch
route-method exe
route-delay 2
## DNS Server im LAN des VPN Servers
dhcp-option DNS 192.168.0.1
<ca>
-----BEGIN CERTIFICATE-----
....
Auf den VPN Server folgend Befehle ausführen, wenn die LAN Schnittstelle eth0 ist:
# alle vorherigen iptables Eintraege entfernen
iptables -F
iptables -X
iptables -t nat -F
## Forwarding u. NAT fuer openVPN Cients
## - VPN Server LAN erreichbar machen
## - Internet ueber das LAN des openVPN Server erreichen
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Die forwarding und NAT Reglen sind nicht persisten, also nach einem reboot des VPN Servers sind diese wieder weg,
Wir wollen aber zuerst nur testen, ob es funktioniert.
Die editierte “DietPi_OpenVPN_Client.ovpn” in die Client VPN Soft importieren und eine VPN Verbindung aufbauen.
Der VPN Server ist jetzt unter IP: 10.8.0.1 und seiner LAN IP z.B. 192.168.0.100 zu erreichen.
LAN IP des DNS Servers u. IP des Default Gateways am VPN Server, im Bsp die 192.168.0.1 , sollte vom Client aus auf einen ping Befehl antworten.
Ein Traceroute vom Client aus sollte jetzt in etwa so aussehen:
C:\Windows\system32>tracert heise.de
Routenverfolgung zu heise.de [193.99.144.80] über maximal 30 Abschnitte:
1 55 ms 56 ms 54 ms 10.8.0.1
2 55 ms 55 ms 55 ms 192.168.0.1
3 * * * Zeitüberschreitung der Anforderung.
....
7 69 ms 66 ms 67 ms te0-0-2-3.c350.f.de.plusline.net [80.81.193.132]
8 77 ms 85 ms 84 ms 82.98.102.5
9 68 ms 67 ms 68 ms 212.19.61.13
10 68 ms 74 ms 74 ms redirector.heise.de [193.99.144.80]
Ablaufverfolgung beendet.
Auf IP-Adresse erfahren sollten jetzt die angezeigten Daten so aussehen, als ob du vom Standort deines VPN Servers auf das Internet zugreifen würdest.
Und funktioniert es bei dir?
Will man die lokale Internetverbindung des Clients zum surfen nutzen, muss man es anders konfigurieren.
Falls es aber nicht gewünscht ist, müsste man nach die iptable Regeln bei jedem Start mit ausführen lassen.
Wow, vielen Dank für das ausführliche Tutorial. Ich komme aus einer Zeit, in der der Z80 und CP/M das Maß aller Dinge waren. Dann brauchte ich mich 30 Jahre nicht mehr um solche Dinge zu kümmern und genoß die Vorteile der immer besser werdenden Wizards.
Entschuldige also bitte, wenn ich in der Terminologie herumstolpere, aber ich will zuerst einmal versuchen Dir meine Konfig zu erläutern. Hoffentlich wird keiner sauer, wenn das auf deutsch geschieht, worüber ich im übrigen sehr dankbar bin.
Also, auf der FritzBox habe ich einen forward der Ports 1194,443 und 943 auf den XU4 192.168.178.69 eingerichtet. Außerdem noch eine IP-Route 10.8.0.0 die auf den XU4 zeigt.
Mein Remote-Client ist mein Notebook mit Win7 und dieses erhält bei der Verbindung die IP: 10.8.0.6. Der XU4 hat die Remote IP 10.8.0.5 und auf dem Lan die IP …69 (Siehe oben, ist klar). Dann hängen noch ein Win10-PC, ein Win7-PC sowie ein Notebook im Lan. Eine Kamera und ein Raspi für die Wärmepumpe runden das Netz ab.
Der XU4 ist auf DHCP konfiguriert und in der FritzBox habe ich die IP so konfiguriert, dass der XU4 immer die gleiche Adresse erhält. Also das Gleiche als ob der XU4 statisch konfiguriert wäre. Ich hatte anfangs eine statische Adresse am XU4, aber dann waren die Netzlaufwerke des Samba-Servers nur noch über die IP des XU4 zu verbinden. Warum das so ist entzieht sich meinem Kenntnisstand. Die Idee den Samba-Server als WINS-Server zu konfigurieren hat an der Stelle nichts gebracht. Stellt man das Ganze zurück auf DHCP erscheint der Host auch im Explorer. Ach so, ifconfig sagt mir, dass eth1 die Ethernetschnittstelle meines XU4 ist. (Habe das in den iptables berücksichtigt)
Wie Du richtig vermutet hast möchte ich natürlich am liebsten ein Remote-Access-VPN mit Zugriff auf meine internen Host, sowie Internetzugriff über den Tunnel, also über meinen Internetzugang.
Da ich hier im Tal wohne, muss ich jedoch ins Auto steigen um die Konfig via Tethering auszutesten. Ich habe den Client und den Server entsprechend Deinem Tutorial eingerichtet und werde das Morgen mal testen. Habe keine Ahnung wie es ausgeht, aber ich werde umgehend berichten.
Auf jeden Fall bin ich wirklich begeistert von der Zuverlässigkeit des kleinen Maschinchens und von der Leistung der DietPi-Entwickler. Da ich Dich dazu zähle habe also auch Dank für Deine kompetente Hilfe. Es bleibt natürlich jedem selbst überlassen, aber mir war das eine Spende wert und wird es regelmäßig Wert sein.
so, jetzt liegen die Ergebnisse vor. Der frühe Vogel… Leider hat Deine Lösung nicht funktioniert. Der Tunnel wurde zwar aufgebaut und ich habe eine IP erhalten (wie zu erwarten die 10.8.0.6), jedoch war danach nicht mal mehr der XU4 zu erreichen. Ich habe dann noch mal alles überprüft um sicher zu gehen, dass ich keinen Mist gemacht habe. Außerdem habe ich dann noch das IP-Forwarding im Router deaktiviert, auch ohne Erfolg. Ich hatte gestern noch etwas recherchiert und eine andere Lösung gefunden die ohne die Konfiguration der iptables auskommt.
Du wirst Dich wundern aber das klappt. Ich erreiche alle Hosts und kann über meinen Anschluß im I-Net surfen. Alles perfekt. Das einzige was nicht funktioniert ist die Namensauflösung im Windowws Netz. Also auf dem Laptop, im Explorer, erscheinen nicht die angeschlossenen Teilnehmer meines internen Netzes. Frag mich nicht warum, das wirst Du besser wissen. Über die IP sind die Teilnehmer jedoch problemlos mit allen Diensten erreichbar. Auch meine Bauteiledatenbank ist super erreichbar.
Ich habe auf dem XU4 in der Samba Konfiguration den WINS aktiviert und bei den Clients diesen bei den Adaptern eingetragen. (Nur zur Info)
Ich glaube ich schicke Dir einfach mal die Konfigdateien von Server und Client.
Hier die Serverkonfig:
port 1194
proto udp
dev tun
ca ca.crt
cert DietPi_OpenVPN_Server.crt
key DietPi_OpenVPN_Server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
client-to-client
keepalive 10 60
comp-lzo
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
verb 3
status /var/log/openvpn-status.log
log-append /var/log/openvpn
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway def1"
## DNS Server meines Providers
push "dhcp-option DNS X.X.X.X"
push "dhcp-option DNS X.X.X.X"
## Adresse des XU4 auf dem VPN
push "dhcp-option DNS 10.8.0.5"
push "dhcp-option WINS 192.168.178.69"
und hier der Client
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
route-method exe
route-delay 30
route-metric 512
route 0.0.0.0 0.0.0.0
ns-cert-type server
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
Portfreigabe auf dem Router: 1194 UDP, 443 TCP, 943 TCP alles in Richtung XU4
IP-Forward auf dem Router: Netzwerk 10.8.0.0, Subnet 255.255.255.0, Gateway 192.168.178.69
Auf dem XU4 ist das Port-Forwarding aktiviert, aber das ist es standardmäßig wie ich festgestellt habe.
Alles leer. Vieleicht findest Du ja heraus warum das funktioniert. Wäre vielleicht für alle interessant. Der Tracert nach Heise.de sieht dann in etwa so aus, wie das was Du gepostet hast.
Ich bin zwar jetzt froh, dass es bis auf WIns erst einmal funktioniert. Aber vielleicht kannst Du mir/allen noch behilflich sein zu verstehen warum das funktioniert.
Fühle Dich frei und nochmals vielen Dank für Deine bisherige Antwort.
Solltest Du noch Infos brauchen dann einfach nachfragen.
anbei noch ein Nachtrag zum Post von vorhin. Ich habe es geschafft den Tracert zu kopieren. Hier das Ergebnis.
Ich bin mit meinem Notebook in einem Firmennetz via WLan und aktivem Tunnel.
PS C:\Users\Thomas> tracert heise.de
Routenverfolgung zu heise.de [193.99.144.80] über maximal 30 Abschnitte:
1 18 ms 18 ms 16 ms MEINSERVER [10.8.0.1]
2 20 ms 18 ms 18 ms fritz.box [192.168.178.1]
3 * * * Zeitüberschreitung der Anforderung.
.
.
.
.
11 38 ms 29 ms 31 ms redirector.heise.de [193.99.144.80]
Ablaufverfolgung beendet.
PS C:\Users\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.
es klappt Alles so wie es soll. Aber dazu später mehr.
Zuerst einmal möchte ich Dir ganz herzlich für Deine Zeit danken, die Du mit meinem Problem verbracht hast. Du hast einem alten Mann, neben der Freude das es klappt, auch noch einen Haufen über Netzwerke und allen damit verbundenen Möglichkeiten beigebracht. Selten so verständlich und ausführlich beschrieben und Hilfe zur Selbsthilfe. Wenn Du in dem Metier zuhause bist, dann mache ich mir keine Sorgen dass Du verhungern musst.
Noch etwas zum DietPI Projekt, was ich an alle Leser und Anwender richten möchte. Wer dieses Projekt nutzt, privat oder geschäftlich, den bitte ich, falls er es noch nicht getan hat, das Projekt zu unterstützen. Ich habe hier einen Server, der mich, wenn ich diesen mit der gesamten Funktionalität aus Redmond hätte beziehen müssen, einen vierstelligen Betrag mit einer 6 vorne gekostet hätte. Da reden wir noch nicht von den Technikerkosten, bis das alles zum Laufen gekommen wäre! Hier bitte ich jeden User einmal für sich nachzudenken wollen wir weiterhin davon profitieren. Ein altes Sprichwort sagt: Viele wenige ergeben ein Viel! Und wo wenig hilft, kann viel nicht schaden!
Jetzt zur Lösung:
Dein Vorschlag mit dem “Bridging” ist das Zaubermittel, welches die Dinge zum Laufen gebracht hat. Es funktioniert alles bestens so wie ich es wollte. Die Namensauflösung in Windows funktioniert, Browsen über den eigenen Zugang und die Erreichbarkeit der Host’s im Lan. Dazu gehören auch der Raspi und die Kamera. Es ist so, als ob der Notebook im Heimnetz eingestöpselt wäre.
Dein Hinweis auf Layer 2 hat mich dunkel an das OSI-Schichtenmodell erinnert welches ich mir dann noch mal angeschaut habe. Sicherlich hätte man das mit einem konfigurierbaren DNS-Server auch hinbekommen, jedoch kann das die FritzBox ohne Sonderbehandlung (Patch, Firmwaränderung usw.) nicht. Dies würde ich mir aber nicht antun, noch will ich einen Garantieverlust.
Also muß man wohl das VPN FritzBox kompatibel machen. Also, der FritzBox DHCP und DNS überlassen und mit dem VPN eine Bridge in das Lan erstellen. Wichtig ist, das der DietPI auf dem das VPN läuft, ebenfalls eine IP über die Box erhält. Nur so wird er in DNS auf der Box registriert. Danach unbedingt ein Häkchen auf der Box setzen, dass der DietPi immer die gleiche IP erhält, selbst wenn die Lease erneuert wird. Nur so schafft man es, das die statischen Routen niemals ihr Ziel verfehlen.
Zuerst trägt man dann auf der FritzBox die Portfreigabe für Port 1194 UDP auf die IP des DietPi ein. Weitere Einträge sind, entgegen dem Tutorial hier im Forum, nicht nötig. Danach noch einen IP-Forward vom VPN (10.8.0.0) auf die IP des DietPI auf dem der VPN-Server läuft. Bei mir die 192.168.178.69.
Ein WINS Server wird im gesamten Netz nicht benötigt. Ich habe noch einen alten XP Messrechner. Auch dort klappt die Namensauflösung perfekt.
Die VPN-Konfigurationsdatei auf dem Server konnte ich erheblich abspecken.
port 1194
proto udp
## Hier von tun auf tap ändern
dev tap
ca ca.crt
cert DietPi_OpenVPN_Server.crt
key DietPi_OpenVPN_Server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
client-to-client
keepalive 10 60
comp-lzo
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
verb 3
status /var/log/openvpn-status.log
log-append /var/log/openvpn
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.178.1"
push "dhcp-option DOMAIN WORKGROUP"
Wie Du siehst habe ich Deine Anmerkungen beherzigt. Wichtig ist hier der letzte Eintrag bei den dhcp-optionen. Es geht auch ohne die Angabe der Domäne, jedoch entsteht ein großer “Nudelfaktor” bei der Suche nach den Sambafreigaben. Das geht sehr schnell mit diesem Eintrag. Mehr braucht es auf dem Server nicht.
### siehe VPN Server Config oben
client
proto udp
dev tap
#Ip/Domain name of DietPi system, running OpenVPN server.
remote meindynhost 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
route-method exe
route-delay 2
route 0.0.0.0 0.0.0.0
ns-cert-type server
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
Wie man sieht ist die Clientdatei auch entsprechend schlank.
Fazit: Wer eine FritzBox sein eigen nennt und das dürften viele sein, wer dann noch eine volle Namensauflösung wünscht, der kommt aufgrund der Einschränkungen der Box nicht um “bridging” herum und sollte gleich von “tun” auf “tap” wechseln.
In diesem Sinne nochmals vielen Dank an k-plan für die Unterstützung und das neugierig machen auf die aktuelle Netzwerktechnik und deren Verfahren. Werde da weiterlesen und “rumfummeln”
@k-plan: Wenn es gewünscht wird, würde ich diesen Thread zusätzlich ins Englische übersetzen, so das alle was davon hätten. Es wäre schön, wenn man das in deutsch stehen lassen könnte, da dieses Problem in vielen deutschen Foren zu finden ist.
NACHTRAG:
Im Betrieb hat sich herausgestellt, dass es manchmal dazu kommt, das Windows beim Anklicken eines Servers im Explorer (unter Netzwerk) meldet, das der Netzwerkpfad nicht gefunden wurde. Wartet man ein weilchen, so zwischen 5 - 10min ist das Problem weg. D.h. der Name wird zwar angezeigt, jedoch scheint die Namensauflösung nicht sofort zu funktionieren. Abhilfe schafft das editieren der lmhosts Datei auf dem VPN Clientrechner. Die Datei befindet sich unter C:\windows\system32\driver\etc. In der Grundkonfiguration heist die Datei lmhosts.sam. Nach dem editieren bitte die Datei unter dem Namen lmhosts ohne Erweiterung speichern. “sam” bedeutet sample. Die Datei dient der manuellen Namensauflösung von WINS. Nicht zu verwechseln mit der hosts Datei, die im gleichen Verzeichnis liegt. Diese dient der manuellen DNS-Auflösung!
In die Datei einfach die IP des Hosts und den Namen eintragen. Die Option #PRE veranlasst Windows die Tabelle sofort in den Cache zu laden. Es können bis zu 100 Hosts manuell in die Liste eingetragen werden. Folgendes Beispiel soll das verdeutlichen.
Im Explorer unter Netzwerk wird der Rechner FRITZ-NAS angezeigt. Klickt man darauf kommt nach einer Weile die Meldung das der Netzwerkpfad nicht gefunden wurde. FRITZ-NAS ist nichts anderes als die Festplatte an der FritzBox, die bei mir die IP 192.168.178.1 hat. (Dies dürfte bei den meisten Anwendern so sein die die NAS-Option der Box verwenden, da es dem Standard entspricht)
Fügt man jetzt der Datei lmhosts folgenden Eintrag hinzu, ist das Problem weg:
192.168.178.1 FRITZ-NAS #PRE
Nach dem Neustart und dem erneuten Aufbau des VPN-Tunnels tritt das Problem nicht mehr auf. Analog dazu ist das mit jedem Rechner zu machen, der diese Probleme verursacht. Die IP des Rechners erhält man aus der Liste der FritzBox unter “Heimnetzwerk”. Verwendet man diese Methode ist dringend zu empfehlen bei allen Rechnern das Häkchen für die Bereitstellung der immer gleichen IP über DHCP zu setzen, da sonst u.U. bei der Erneuerung der Lease die Namensauflösung ins leere läuft. Schlimmer noch, erhält der Host eine neue IP wird unter seiner neuen IP niemals mehr gefunden!!
schön, dass es nun bei dir so funktioniert, wie du es dir vorgestellt hast.
Das von Dir geäußerte Lob, möchte ich unkommentiert lassen, mich aber trotzdem dafür herzlich bei Dir bedanken.
Ist beides nicht mehr so häufig anzutreffen in der heutigen Zeit.
In der “Geiz-ist-Geil” Gesellschaft ist es üblich und selbstverständlich, dass man alles und jedes umsonst und ohne jegliche Gegenleistung bekommt. Das nennt sich wohl Wandel der Zeit.
Das böse OSI Wort hatte ich bewusst vermieden, weil dabei die meisten direkt dicht machen und das weitere Lesen sofort einstellen.
Da kann ich in deinem Fall auch nur stark von abraten. (nur wegen “rumfummeln” )
Die Kabelmodem-Router-Kombinationen der Kabelnetzbetreiber sind vorprovisioniert und mit speziellen Firmwares versehen, die sich vom Kunden nicht updaten, entbranden oder umflashen lassen. Meist ist der Konfigurationsumfang gegenüber dem Original noch stärker eingeschränkt.
Die Geräte gehören ja dem Kabelnetzbetreiber und sind dem Kunden nur zur Nutzung überlassen. Dieser wird sie, wenn überhaupt, nur selber über sein Netzwerk, auch ohne Zustimmung des Kunden, updaten.
Die AVM FritzBox ist ein Consumer Gerät, dem viele Einstellmöglichkeiten in der Oberfläche bewusst genommen wurde, um Endkunden Fehler zu minimieren und das Handling für Kunden zu vereinfachen. (Minimierung des Support-Aufwandes)
Durch das Branding der Kabelnetzbetreiber, dass übrigens auch durch AVM vorgenommen wird, entfallen meist noch weitere Konfigurationsmöglichkeiten.
Seit dem 01.08.2016 ist zwar der “Routerzwang” gefallen, aber diese Geräte lassen sich trotzdem nicht “entsperren” oder mit einen original AVM Firmware versehen. (jedenfalls nicht für Heim-Anwender)
Also bitte gar nicht erst versuchen, gibt wenn nur teueren Elektronikschrott. Wenn schon, sollte man sich eine FRITZ!Box 6490 Cable (ungebrandet und nur direkt von AVM) kaufen und vom Provider freischalten (provisionieren) lassen. Das geht aber nur bei Neukunden u. für bestimmte Bestandskunden. Also somit auch nicht für jeden Kunden.
Wenn es interessiert, kann ich das erklären.
Auf der FritzBox läuft immer ein DNS Server. Darüber wird auch bewerkstelligt, dass sich die Box immer über den Namen " fritz.box " im Internetbrowser ansprechen lässt. Außerdem ist sie auch unter der "Notfall IP ": 169.254.1.1 erreichbar. Beides ist statisch im DNS Server der FritzBox hinterlegt.
Ist nun der DHCP Server auf der FritzBox aktiviert, melden sich die Clients im LAN bei diesem an und beziehen ihre IP Adressen von diesem.
Dabei übermittel die DHCP Clients, also deine Rechner u. Geräte, standardmäßig " clientid " (Code 61), das ist in diesem Fall ihre eigene MAC Adresse, und " hostname " (Code 12) , der im Betriebssystem des Gerätes festgelegte Name des Geräte. Für deinen XU4 wäre das z.B. standardmäßig “DietPi”, kann man aber leicht ändern (dietpi-config).
Die vom DHCP Server der FritzBox zugeteilte IP Adresse übernimmt die FritzBox in ihren DNS Server und ergänzt den Eintrag um den übermittelten “hostname”. Ist die FritzBox nun DNS Server für die LAN Clients (z.B. über DHCP verteilt) kann sie die Gerätenamen in IPs auflösen.
Ja, vielen Dank. Wäre schön, wenn du das in English noch einmal niederschreiben könntest. Am günstigsten in einen neuen, extra Thread (new Topic). Dann können die meisten das Thema besser wieder finden.
Sehe keinen Grund, warum das hier nicht in Deutsch stehen bleiben sollte.
Fourdee make the rules, but I can only speek german.
So come on Dan, if you have any questions, please let us know. :mrgreen:
OK, I’ll do my best to translate this complex issue. It was hard enough to understand the terms of networking in German. I hope that my Native speakers are available to support my efforts.
So be merciful to me. I try hard.
I will open a new thread and link with this thread and vice versa.
Otherwise, don’t worry. I’m not going to fumble around on my router. Previously should drop my fingers.
Der Tunnel wurde zwar aufgebaut und ich habe eine IP erhalten (wie zu erwarten die 10.8.0.6), jedoch war danach nicht mal mehr der XU4 zu erreichen. Ich habe dann noch mal alles überprüft um sicher zu gehen, dass ich keinen Mist gemacht habe. Außerdem habe ich dann noch das IP-Forwarding im Router deaktiviert, auch ohne Erfolg. Ich hatte gestern noch etwas recherchiert und eine andere Lösung gefunden die ohne die Konfiguration der iptables auskommt.
Das böse OSI Wort hatte ich bewusst vermieden, weil dabei die meisten direkt dicht machen und das weitere Lesen sofort einstellen.