Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
OpenVPN: Wahlweise ALLES oder nur DNS drüber laufen lassen...
Ich sehe hier meiner Meinung nach schon 2-3 Fehler:
1) Das sieht doppelt gemoppelt aus. 10.8.0.0 sollte reichen.
push "route 10.8.0.1 255.255.255.255"
push "route 10.8.0.0 255.255.255.0"
2) Ich bin bei VPN im 10.8.0er Netz ... um diesen DNS zu erreichen muss "geroutet" werden (ist zwar kein Problem - erfolgt ja - macht aber DIESE Zeile unnötig - DNS per 10.8.0.1 sollte reichen)
push "dhcp-option DNS 172.20.5.201"
3) ifconfig 10.8.0.1 10.8.0.2
10.8.0.2 existiert bei mir nicht. Wenn ich das richtig gelesen habe kommen hier die VPN-Client-IPs hin. Ich arbeite mit 101, 102, 103 - trag ich die da wirklich ein? Steht nicht drin, aber 101 und 102 gehen (3 noch nicht testen können). Den Sinn dieser Zeile versteh ich nicht ...
irgendwas an diesen Konfigs sorgte in Griechenland im Hotel-WLAN dafür das WLAN deaktiviert wurde und das VPN über LTE lief (Variante: DNS/LAN über VPN)... versteh ich nicht so ganz. Da wird doch nirgends LTE/WLAN unterschieden. Den Konfigs ist es doch letztendlich egal worüber das VPN aufgebaut werden soll ...
Mit der server Anweisung definiert man das VPN-Subnetz. In Verbindung mit topology subnet wird aus dem VPN ein einzelnes großes Subnetz. Im Prinzip so als wenn alle VPN-Clients per LAN-Kabel an einem großen Switch hängen würden. Der Server hat dabei automatisch die erste Host-IP-Adresse im Subnetz, also die 10.8.0.1.
Die ifconfig Anweisung kann man an dieser Stelle im Prinzip auch weglassen bzw. ist laut Dokumentation bei tun Devices nur für Punkt-zu-Punkt-VPNs. In der Beispielkonfiguration des Servers - in dem Falle ein Multi-Client-VPN - wird ifconfig überhaupt nicht verwendet.
Die push Anweisungen sind definitiv überflüssig. Durch die topology Anweisung hängt der VPN-Client wie gesagt an einer Art VPN-Switch und ist selbst in dem 10.8.0.0/24 Subnetz. Ergo braucht er keine Route in dieses Subnetz und auch nicht zum VPN-Server. Alle Netzwerke, in denen ein Gerät selbst eine IP Adresse hat, werden automatisch vom Betriebssystem "lokal geroutet". Sprich: Sobald man die IP-Adresse einstellt oder eingestellt bekommt (via DHCP) wird automatisch in der Routing-Tabelle eine lokale Route hinzugefügt.
Nur dann, wenn man in das Netzwerk hinter dem VPN-Server will, braucht man so eine Route (zB push "route 192.168.178.0 255.255.255.0", wenn der VPN-Server in einem Standard-Fritzbox-Netzwerk hockt).
ccd verwendet man, um client-spezifische Parameter im Server zu aktivieren. Dabei heißt der ccd-Ordner exakt so wie der Common Name des verbundenen Clients. Heißt: Man kann sich da nix "aussuchen". Wenn das Zertifikat des iPhones bzw. der Common Name darin "iPhoneVonWulfman" heißt, dann muss auch die ccd Konfig exakt diesen Namen tragen.
Die ccd's funktionieren so, dass der Server einen VPN-Client anhand des Zertifikats identifiziert. Er holt sich also den (eindeutigen) Namen aus dem Zertifikat und prüft ob er eine passende ccd-Konfig dazu hat - wenn nicht, dann macht ccd nüschts. Findet er eine passende Konfig, dann führt er die Befehle darin aus, zB die IP-Zuweisung, die aber ehrlicherweise vollkommen überflüssig ist.
Wenn Harry sich mit dem VPN verbindet, passiert nichts außer der server.conf. Wenn in dieser also keine weiteren push routes drin sind, wird Harry nur eine Verbindung zum VPN-Server selbst haben, aber nicht in das Netzwerk dahinter und auch keine Umleitung des Internets.
Wenn Steffi sich mit dem VPN verbindet, wird neben der server.conf noch die ccd Konfiguration für Steffi hinzugezogen. Ergo wird Steffis Standard-Gateway gemäß push Anweisung umgeleitet. Steffi hat Zugriff auf den VPN-Server und das Internet über das VPN, nicht jedoch in das Netzwerk hinter dem VPN-Server
Wenn Peter sich mit dem VPN verbindet, wird neben der server.conf noch die ccd Konfiguration für Peter hinzuzgezogen. Er bekommt also kein push redirect-gateway, sondern stattdessen ein push route für das lokale Netzwerk des Servers.
Wenn Wolfman sich mit dem VPN verbindet, bekommt er das Gateway wie Steffi und die Route ins Server-Netzwerk wie Peter.
ccd ist eigentlich nicht dafür da, dasselbe Gerät mit unterschiedlichen Profilen zu versorgen. Dann müsste man nämlich auch im VPN-Client zwei Konfigurationen haben, von denen eine quasi das Wolfman-Zertifikat verwendet und die andere das Harry-Zertifikat. Dann kann man aber genauso gut auch gleich zwei client.conf anlegen und in eine direkt das redirect-gateway einbauen und in der zweiten client.conf selbige Anweisung weglassen - kein Grund für Zweckentfremdung von ccds.
ifconfig-push würde man zB in einer ccd Konfig verwenden, wenn man beispielsweise (Non-VPN-)Server als Client an ein VPN anbindet, beispielsweise ein NAS als VPN-Client. Das NAS bekäme dann vom VPN-Server stets via push dieselbe VPN-IP und somit könnte man auch das NAS direkt mit der VPN-IP ansprechen. ifconfig-push im ccd ist quasi wie eine IP-Reservierung im DHCP-Server. Für Server-Geräte sinnvoll, bei reinen Client-Geräten vollkommen überflüssig. "ifconfig-pool-persist ipp.txt" in der server.conf würde im übrigen bereits dafür sorgen, dass derselbe Client dieselbe IP bekommen sollte.
DNS via VPN: Wenn redirect-gateway aktiv ist, wird sowieso alles was nicht im lokalen Subnetz liegt durch das VPN geschossen. Natürlich muss geprüft bzw. sichergestellt werden welchen DNS der Client verwendet. Wenn via VPN-DHCP zB ganz einfach 10.8.0.1 als DNS mitgegeben wird, dann sollte der VPN-Client auch diesen als DNS verwenden. Ausnahme: Wenn am lokalen LAN/WLAN-Adapter ein anderer DNS eingetragen ist, kann es sein, dass das Betriebssystem diese DNS-IP bevorzugt. Sofern diese IP nicht lokal ist (also zB LAN-DNS=8.8.8.8), wird eben dieser DNS 8.8.8.8 aber ebenfalls via VPN geroutet (Stichwort: redirect). Ist redirect-gateway nicht aktiv, würde 8.8.8.8 dann über den lokalen Router geroutet werden, nicht über das VPN. Dafür wäre dann zB ein push "route 8.8.8.8 255.255.255.255" im VPN-Server sinnvoll - oder eben gleich sicherstellen, dass 10.8.0.1 als DNS verwendet wird.
Wulfman_SG schrieb:
irgendwas an diesen Konfigs sorgte in Griechenland im Hotel-WLAN dafür das WLAN deaktiviert wurde und das VPN über LTE lief
Kann ich mir nicht vorstellen. Definiere "deaktiviert". Der VPN-Client wird wohl kaum den WLAN-Adapter abschalten.
Lange Rede, kurzer Sinn: Deine Konfiguration ist in meinen Augen unnötig kompliziert. Je mehr Dinge du konfigurierst (zB ccd, unnötige Routen, etc) umso mehr kann am Ende natürlich auch nicht funktionieren.
proto udp
dev tun
ca ca.crt
cert server.crt
dh dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1" <-- für alle hier oder individuell in den client.confs
push "dhcp-option DNS 10.8.0.1"
client-to-client
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
client
proto udp
dev tun
dev-node VPN
remote aaa.bbb.ccc.ddd 1194
ca ca.crt
cert client.crt
key client.key
redirect-gateway def1 <--- Auskommentieren, wenn nicht erwünscht. Evtl. zweite .conf anlegen zum Umschalten
Hab die Konfig jetzt mal soweit übernommen. Push route fürs LAN hab ich noch rein
=> es klappt.
WLAN + DNS/LAN und ALLES-Drüber-VPN-Profil -> klappt
LTE + DNS/LAN und ALLES-Drüber-VPN-Profil -> klappt
Ich habe aber 3 Probleme die ich noch nicht so verstehe ...
-1- Ich hab jetzt aber ein komisches Phänomen. Etwas was doch eigentlich keinen Sinn macht. Dem VPN dürfte es doch völlig egal sein ob es über WLAN oder LTE aufgebaut wird ... ist es aber nicht.
OpenVPN läuft auf einem Raspberry wo auch pi.hole (mein DNS-Server) läuft. IP: 172.20.5.201 bzw. 10.8.0.1.
LTE und Profil "DNS/LAN" -> ich connecte via Browser pi.hole bzw. die LAN-IP -> klappt!
WLAN und Profil "DNS/LAN" -> kein Connect via Browser möglich. Webserver auf 172.20.5.200 ist aber problemlos mit Host oder IP erreichbar.
Das gleiche mit dem Profil "Ganzer Traffic über VPN".
-2-
Mein Webserver sagt ich connecte ihn mit der IP 172.20.5.201 und nicht mit 10.8.0.101 (was die zugewiesene VPN-IP ist). Im Webinterface von pi.hole passt es ... die DNS-Abfragen kommen von 10.8.0.101
Woran liegt das? Das sieht ja aus als wäre der Raspberry nun Proxy ...
-3-
RDP (der Webserver; also 172.20.5.200) will auch nicht über das VPN (egal ob LTE/WLAN) laufen.
LTE: Netzwerk nicht verfügbar
WLAN: Keine Fehlermeldung - Laut Sitzungsinformationen bin ich verbunden - sehe aber nichts
Ok vielleicht ein Problem mit dem Server (heute Abend mal prüfen) - Aber warum 2 unterschiedliche Verhalten bei LTE/WLAN? Ich nutze bei beiden das gleiche Profil. Auf den RDP-Server komme ich per Webinterface mit gleicher IP/DNS-Namen drauf.
---
... wo ich OpenVPN ganz frisch installiert habe und nichts geändert habe, konnte ich auch per eigenen WLAN das VPN connecten. Macht natürlich keinen sinn ... ging aber - das geht nun nicht mehr ... wieso ist das so? [mein WAN-Host wird im LAN mit lokaler IP aufgelöst ... ich connecte OpenVPN also mit 172.20.5.x und nicht mit 85.1.2.3]
Raijin schrieb:
dann führt er die Befehle darin aus, zB die IP-Zuweisung, die aber ehrlicherweise vollkommen überflüssig ist.
ich weiß gerne welche IP was macht. Daher mag ich keine dynamischen Adressen. Im pi.hole-Log ist es auch praktischer wenn man dann sieht das 102 ständig irgendwelche komischen Adressen auflösen möchte - so weiß ich direkt: mein Tablet hat irgendwas was mir nicht gefällt. Bei dynamischer Zuordnung muss ich dann erstmal gucken - ist die .2 jetzt iPhone oder Android-Tablet bzw. zum Zeitpunkt der ominösen Auflösung. ifconfig-pool-persist ipp.txt <- das muss ich mir dann später noch mal anschauen. Aktuell mach ich das weiter mit ccd - erstmal das OpenVPN sauber zum laufen bekommen bevor ich weitere Baustellen auf mache.
Raijin schrieb:
Der VPN-Client wird wohl kaum den WLAN-Adapter abschalten
Im zweiten Urlaub noch mal testen können:
LTE: VPN -> klappt (nicht immer...)
WLAN: VPN aktivieren wollen -> WLAN, welches bis dahin gut gearbeitet hat, disconnectet (deaktiviert war unglücklich erwähnt) sich und LTE wurde für DÜ/VPN genommen.
In der iOS-OpenVPN-App gibt es eine Option mit der man sagen kann über welche Verbindung VPNs aufgebaut werden dürfen: WLAN/WWAN hab ich aktiviert. Daran kann es also nicht liegen.
Bei dem Fritz!Box-VPN gab es keinerlei Probleme mit WLAN vs. LTE. Das hier jetzt OpenVPN unterschiedlich reagiert macht für mich keinen Sinn. Theoretisch ist es dem Client und Server doch völlig egal über welche Technologie ich reinkomme. Ich kann die IP des Server connecten -> fertig.
Ergänzung ()
Die Verbindungslogs der OpenVPN-App@iOS sind bei LTE und WLAN identisch (kein wunder ...)
die Positionen kann ich doch dann eigentlich löschen? Ausser Android-OpenVPN nutzt diese (muss ich noch prüfen) bzw. der Windows-OpenVPN-Client (das testen dauert noch etwas länger...)
=> ok DNS hab ich nur auf 201. Eigentlich müsste ich doch nur 10.8.0.1 pushen. Da ich ja im 10.8er Netz hänge, spare ich mir so einmal Routing.
block-outside-dns <- hatte OpenVPN gestern neuinstalliert und das war dann plötzlich standardmässig drin. Laut Google eher ein Securityfeature.
Ansonsten paar Positionen mit "Infogehalt" aus dem Log:
Das Hauptproblem ist, dass du alles in einen großen Topf schmeißt, einmal kräftig umrührst und dann feststellst, dass etwas nicht so ganz funktioniert.
pihole, ccd, offensichtliche windows-openvpn-configs unter iOS, etc...
An dieser Stelle kann man dir aus der Ferne nur schwierig bzw. gar nicht weiterhelfen. Es gibt zig Baustellen, die man nicht über ein Forum abklären kann. Meine Empfehlung: Setze das Gesamtkonzept Schritt für Schritt nacheinander auf und teste es. Passe vor allem die configs an das jeweilige Betriebssystem an. "dev-node" ist zB eine Windows-spezifische Option, die bei *nix-Systemen überflüssig ist. Zwar sollte das keine Probleme verursachen, aber je sauberer die config umso besser. Was/wie/wo für Windows, iOS und Android konkret notwendig bzw. überflüssig ist, weiß google.
Für die ersten Gehversuche rate ich dir dringendst, die ccds, pihole und sonstige Extras wegzulassen. Je komplexer das Setup umso mehr Fehlerquellen gibt es. Man startet nie direkt mit dem Maximalausbau, sondern fängt mit einem rudimentären Test an - heißt: Schei** auf Rückverfolgbarkeit der IP, schei** auf DNS-gedöns, etc... Das sind alles Dinge, die man später oben drüber stülpt, wenn die Basis funktioniert.
dev-node VPN <- war doch in deiner Konfig drin - daher hab ich das übernommen.
Wie gesagt: ich hab deine Konfig übernommen - nur das mit der Route hab ich um das LAN ergänzt - dazu waren noch sachen wegen der Schlüssel drin - die hab ich auch so übernommen wie in der Standardkonfig vorgegeben. Aber sonst - deine Konfig.
pihole war ja schon drauf - openvpn hat sich da angeboten - das Fritz!Box-VPN taugt für meinen Anwendungsfall leider nichts.
Grundsätzlich funktioniert es ja ... ich weiß nur nicht wo der Unterschied zwischen LTE/WLAN ist. Ob ich jetzt per CCD eine feste IP setze (was in beiden konfigs der Fall ist) oder nicht, sollte nichts mit der Erreichbarkeit EINES Webservers im LAN zu tun haben. Außer der Webserver hat eine IP-Sperre drin - das kann ich aber verneinen ... per LTE-VPN komme ich ja drauf - nur WLAN-VPN weigert sich zu connecten. Gleiche feste IP.
Ich kann halt nur iOS/Android im LTE testen - mit Verzögerung auch im Hotspot. Das macht das Quick&Dirty etwas schwerer Aber wenigstens klappt das ganze schon mal Grundsätzlich .. zugriff auf pi-hole-gui brauch ich unterwegs ja nicht wirklich. RDP wäre eher interessant. Per Web ist der Server ja erreichbar - nur RDP will er nicht - aber auch hier wieder LTE vs. WLAN.
Das waren Beispiele. Nicht einfach blind alles aus einem Forum und/oder Tutorial abtippen
Dein LTE bzw. WLAN Problem habe ich ehrlich gesagt noch nicht so recht kapiert und kann es schon gar nicht nachvollziehen. Kannst du denn das VPN-Gateway - sprich: die WAN-IP deines Routers - jeweils anpingen? Bitte direkt mit IP versuchen und ggfs mit DDNS, falls vorhanden. Evtl. läuft da auch was mit der DNS-Auflösung beim VPN-Aufbau schief.
Aber wenigstens klappt das ganze schon mal Grundsätzlich .. zugriff auf pi-hole-gui brauch ich unterwegs ja nicht wirklich. RDP wäre eher interessant. Per Web ist der Server ja erreichbar - nur RDP will er nicht - aber auch hier wieder LTE vs. WLAN.