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.