[Problem] Push Option bei OpenVPN

[xrated]

Folgende Optionen laufen am Server:

push "route 192.168.5.0 255.255.255.0"
push "redirect-gateway def1"
push "route 0.0.0.0 0.0.0.0"
push "dhcp-option DNS 192.168.5.1"

Am Client taucht jedoch im Log nichts von Push auf, an was könnte das liegen?

Und anderes Problem, im status log steht nichts von verbundenen Clients bzw. wieviele im Moment verbunden sind.

 

[PeterPawn]

Folgende Optionen laufen am Server:

Version ?

OpenVPN 2.3:
Bei falsch konfiguriertem Client kann es passieren, daß die Push-Anweisungen ins Leere gehen. Normalerweise muß ein Client, wenn er in seiner Konfiguration "client" definiert hat (steht für "pull" + "tls-client"), nicht extra die "pull"-Option aufführen. Wenn da aber ein "tls-client" definiert ist bei Dir anstelle des "client", bräuchtest Du das explizite "pull".

Auch die Status-Datei muß entsprechend konfiguriert werden, standardmäßig wird keine Status-Datei erzeugt. Die benötigte Konfigurationsoption ist "status filename seconds" und "status-version n" für das Format der Status-Datei. Wenn da ansonsten nichts geschrieben wird, kann das auch ein Rechteproblem sein, wenn der Server unter anderer UID/GID läuft und am Ende nicht in die Status-Datei schreiben darf.

 

[xrated]

Ok, es lag daran das ich noch kein TLS nutze und pull nur zusammen mit tls-client geht.

Eine Logdatei habe ich schon nur sehe ich da nichts von Anzahl der Clients:
OpenVPN STATISTICS
Updated,Tue Jan 27 11:27:30 2015
TUN/TAP read bytes,240
TUN/TAP write bytes,240
TCP/UDP read bytes,1240
TCP/UDP write bytes,820
Auth read bytes,472
pre-compress bytes,0
post-compress bytes,0
pre-decompress bytes,0
post-decompress bytes,0
END

In Config (Version 2.3.5):
status /var/log/openvpn.log

 

[PeterPawn]

Status-File und Log-File sind zwei verschiedene Paar Schuhe, soviel vorab. Das Rechte-Problem hast Du ausgeschlossen?

Eine Status-Datei (Version 2) sieht z.B. so aus:

TITLE,OpenVPN 2.3.3 x86_64-suse-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Apr 20 2014
TIME,Tue Jan 27 12:06:28 2015,1422356788
HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username
CLIENT_LIST,client.mydomain.de,1.2.3.4:56789,192.168.0.1,851126,1068081,Tue Jan 27 04:03:47 2015,1422327827,UNDEF
HEADER,ROUTING_TABLE,Virtual Address,Common Name,Real Address,Last Ref,Last Ref (time_t)
ROUTING_TABLE,22:f6:80:90:18:6b,client.mydomain.de,1.2.3.4:56789,Tue Jan 27 12:06:11 2015,1422356771
GLOBAL_STATS,Max bcast/mcast queue length,1
END

Ich habe keine Ahnung, welche Version Deine Status-Datei enthalten könnte ... wird in dieser Version u.U. gar keine Client-Liste ausgegeben?

 

[xrated]

Die Ausgabe von oben stammt von status /var/log/openvpn.log und man sieht wie sich mit der Laufzeit die bytes ändern.
Ich habe gelesen das die Statistics auf dem Client so aussehen sollen, aber das ist ja der Server.
status-version 2 hat auch nichts gebracht.

Edit: Ich glaube es liegt daran das kein "mode server" gesetzt ist und das geht ebenfalls erst wenn tls genutzt wird.

 

[PeterPawn]

@xrated:
So langsam erscheint Deine Konfiguration immer verworrener. In #1 steht noch explizit, Deine OpenVPN-Installation wäre ein Server und die Clients würden per Push (auch eine Option, die den Multi-Client-Mode erfordert) übermittelte Informationen nicht akzeptieren.

Vielleicht sortierst Du doch noch einmal den Stand und schaust auch mal kurz in der OpenVPN-Dokumentation vorbei, denn wenn Du tatsächlich P2P mit PSK machst, gibt es m.E. auch kein "push".

 

[xrated]

Ich hatte das vorher mit der GUI eingestellt und wusste nicht das es kein Server ist wenn man einen statischen Schlüssel verwendet.
Zertfikate werde ich eh noch einrichten aber ich wollte erstmal klein anfangen bevor es komplizierter wird.

 

[MaxMuster]

Das liegt daran, dass man als "Server" durchaus auch einen P2P-Teilnehmer bezeichnen könnte, zu dem sich ein OpenVPN-P2P-"Client" verbindet.
Quasi "ein Server mit genau einem Client".

Es gibt im OpenVPN aber den "multi-client TCP/UDP server mode" (die Option "mode server"), und der funktioniert nur mit Zertifikaten ("SSL/TLS authentication must be used in this mode."). Daher wird mit "Server" meist dieser Modus gemeint.

Per GUI (Version 1) wird auch nur mit "Zertifikaten" die Option "mode server" gesetzt und die ist (zusammen mit "tls-server") die "Voraussetzung" für "push"-Befehle beim Server.
:doktor: Eigene "pushs" müsstest du schon selbst dazu geschrieben haben und dabei bestätigen, dass du die Man-Page gelesen hast (oder die GUI "V2" nutzen, da muss man selbst wissen, was man reinschreibt) ;-)

 

[xrated]

Schreibt man jetzt eigentlich redirect-gateway def1 oder nur redirect-gateway in die Config?

Den Push "Route 0.0.0.0 0.0.0.0" als Default Route für tun, benötigt man bei Windows Clients?

Mit der Config bin ich soweit so gut wie fertig, nur bin ich noch nicht zum testen ausserhalb des LANs gekommen.

 

[MaxMuster]

"def1" ist normalerweise "einfacher".
Dann bleibt die Default-Route erhalten und das OpenVPN-Gateway wird durch zwei "spezifischere" Routen (jeweils für den halben IP-Range) realisiert (sowie einer Host-Route für die OpenVPN-Gegenstelle) und nach Abbau der Verbindung werden die wieder gelöscht.

 

[xrated]

Das hab ich gefunden:
def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

Und das Push "Route 0.0.0.0 0.0.0.0" dürfte ja eigentlich auch überflüssig sein.

 

[PeterPawn]

@xrated:
In der Tat ... wenn "def1" gesetzt wird, sogar kontraproduktiv, da dieses Push nicht wieder gelöscht werden dürfte nach dem Abbau der VPN-Verbindung ... im Gegensatz zum "redirect-gateway", was entsprechend "rückabgewickelt" wird.

Auch der Effekt der 192.168.5.0/24-Route ist natürlich bei "redirect-gateway" umstritten. Wenn die lokale Adresse des TUN/TAP-Adapters entsprechend gesetzt ist, ist das als "link-lokal" ja eigentlich auch inklusive (ist dann identisch mit der Standard-Angabe "route-gateway"); nur, wenn die Adresse des Clients wegen komplizierter Topologie nicht auf diese Maske paßt, ist die Angabe u.U. notwendig.