Automatisches prüfen ob ein Tunnel aufgebaut ist - gibts nen besseren Weg?

[SierraX]

Was ich eigentlich schon vor 1 oder 2 Jahren machen wollte, ist nun soweit fertig.
Ein VPN PPTP over SSH das mehrer Orte/Server (um genauer zu sein, z.Z. 4) miteinander verbindet. Aufgebaut als Stern. Zentraler Punkt ist ein OpenBSD 6.6 Server in (laut usernames bei angriffen auf port 22) Leipzig. Um gleich mal den "Warum nicht IPSEC und IKEv2"-Leuten den Wind aus den Segeln zu nehmen… IPSEC ist vereinfacht gesagt Bidirektional. Ich brauchte aber was Unidirektionales um kein Geschisse mit irgendwelchen Portweiterleitungen über proprietäre und geschlossene Provider Router zu haben
Jetzt ist es so: das geht der Tunnelserver down egal ob geplant oder ungeplant… bauen die Clients an den Standorten die Verbindung nicht selbständig wieder auf. Meine Lösung ein SH Script, das alle 5 Minuten von root Cron ausgeführt wird.

Spoiler: Script

tunstatus="$(ifconfig tun0 | grep -o "status:.*" | sed "s/status: *//")"

if test $tunstatus != "active"
then
 sleep 120
 /usr/bin/ssh -f -w 0:0 tun.endpointserver.net true
fi

Funktioniert gut, wenn alles richtig gemacht wurde … find ich aber nicht sonderlich elegant (Zu viele "Schrauben" z.B. hatte ich einmal vergessen das Script ausführbar zu machen, und hatte über 2 Wochen keine Verbindung zu diesem Standort). Gibt's da was besseres?

 

[roema]

Hi!
Ich verstehe nicht ganz, warum du einen PPTP über einen SSH Tunnel laufen lässt.
Ergibt für mich wenig Sinn, aber vielleicht kannst du es nochmals erklären.

 

[medV2]

Hi!
Ich verstehe nicht ganz, warum du einen PPTP über einen SSH Tunnel laufen lässt.
Ergibt für mich wenig Sinn, aber vielleicht kannst du es nochmals erklären.

Ich nehme an er hat Windows Clients, aber auch da wären OpenVPN / Wireguard besser und man könnte sich den ssh-Zirkus sparen

 

[Esjott]

Was ist mit security/tinc als dezentrales vpn? Zugegeben, selber noch nicht im Einsatz gehabt, sondern seit Jahren auf der todo Liste..

 

[jmt]

tinc funktioniert bei mir seit Jahren einwandfrei und problemlos.

 

[SierraX]

Hi!
Ich verstehe nicht ganz, warum du einen PPTP über einen SSH Tunnel laufen lässt.
Ergibt für mich wenig Sinn, aber vielleicht kannst du es nochmals erklären.

Die Verschlüsselung bei PPTP gilt seit 2012 als gebrochen und somit als unsicher. SSH gilt bei Schlüssellängen ab 2048 bit weiterhin als sicher.
SSH ist mir wesentlich lieber als dieses grottige SSL geraffele mit dem OpenVPN und Tinc arbeitet…
Mal ganz davon abgesehen, das man diese Art von VPN unter OpenBSD und anderen Unixoiden Systemen aufbauen kann ohne Irgendwo irgendetwas nachinstallieren zu müssen oder irgendwelche Abhängigkeiten zu haben.
Ausserdem würde auch dort das Problem mit der Wiederaufnahme des Tunnels bleiben

 

[SierraX]

Achja und es sind keine Desktop Rechner die damit verbunden werden, sondern APUs also ganze Netzwerke

 

[roema]

Achja und es sind keine Desktop Rechner die damit verbunden werden, sondern APUs

Und was läuft auf den APUs? Wenn da kein Windows läuft, verstehe ich nicht, warum PPTP..

 

[SierraX]

Und was läuft auf den APUs? Wenn da kein Windows läuft, verstehe ich nicht, warum PPTP..

Dann lies nochmal meinen vorherigen Post vielleicht hattest du ein edit nicht mitbekommen. Auf 2en läuft OpenBSD 6.6 current und auf einer läuft eine OpenBSD 6.4 current variante hatte irgendwie noch keine lust es auf 6.6 hoch zu ziehen.
Ich wollte etwas, das einfach nur von einer Stelle raus telefoniert und mit so wenig Aufwand wie möglich zu realisieren ist. Und ja ich hab auch schon mal OpenVPN am laufen gehabt… für desktops mal was zu haben … ok aber der Aufwand ist immens.

 

[Zirias]

Vielleicht war ja PPP (ohne T) gemeint? Würde IMHO noch ein bisschen mehr Sinn ergeben, dann müsste man wenigstens nicht eine TCP-Verbindung durch SSH tunneln, nur um dadurch nochmal zu tunneln ....

 

[roema]

Dann lies nochmal meinen vorherigen Post vielleicht hattest du ein edit nicht mitbekommen. Auf 2en läuft OpenBSD 6.6 current und auf einer läuft eine OpenBSD 6.4 current variante hatte irgendwie noch keine lust es auf 6.6 hoch zu ziehen.
Ich wollte etwas, das einfach nur von einer Stelle raus telefoniert und mit so wenig Aufwand wie möglich zu realisieren ist. Und ja ich hab auch schon mal OpenVPN am laufen gehabt… für desktops mal was zu haben … ok aber der Aufwand ist immens.

Ah, okay, hab ich übersehen.
Ich denke, PPTP über SSH ist der großere Aufwand als OpenVPN.
Hab selbst habe ein paar APUs mit OVPN im Einsatz und der Konfiguration Aufwand ist überschaubar.

Am Desktop selbst sogar noch einfacher, da nur ein OpenVPN-Konfig-File importiert werden muss.

 

[SierraX]

Ah, okay, hab ich übersehen.
Ich denke, PPTP über SSH ist der großere Aufwand als OpenVPN.
Hab selbst habe ein paar APUs mit OVPN im Einsatz und der Konfiguration Aufwand ist überschaubar.

Am Desktop selbst sogar noch einfacher, da nur ein OpenVPN-Konfig-File importiert werden muss.

Ich weiss nicht mehr wo ich her hatte das es sich um PPTP handelt… Vielleicht ist es wirklich eher PPP
Aufgebaut hab ich es anhand eines Kernel Panic Artikels und wenn ich dort den Aufwand für OpenVPN und OpenSSH vergleiche… kommt OpenSSH wesentlich besser weg.

 

[medV2]

Also um nochmal auf den Ausgangspost zu kommen: Eine schöner Möglichkeit mit den von dir verwendeten Techniken gibts wohl nicht.

Ich würde dir raten, sieh dir mal Wireguard an, es erfüllt deine Anforderungen, ist sehr einfach einzurichten und ist sau schnell.

 

[jmt]

Oder bau Dein VPN mit TINC. Das löst soche Probleme recht einfach und ist für alle gängigen Betriebssystem verfügbar.

 

[TCM]

Wireguard [...] ist sau schnell.

Gilt das auch für OpenBSD mittlerweile? Als ich das zuletzt angesehen hab, hat es zwischen zwei Kisten direkt nebeneinander im LAN mal eben 20ms Latenz draufgeschlagen wegen der grottigen Userland-Implementierung. OpenVPN ist zwar auch Userland, aber mehr als 10x so schnell, wenn man rein nach der Latenz geht.

Edit: Damit keine Missverständnisse aufkommen: Ich halte eine Kernel-Implementierung für den völlig falschen Weg. Ich würde eine nicht-grottige Userland-Implementierung bevorzugen, wie sie OpenVPN eben hat.

 

[medV2]

Gilt das auch für OpenBSD mittlerweile? Als ich das zuletzt angesehen hab, hat es zwischen zwei Kisten direkt nebeneinander im LAN mal eben 20ms Latenz draufgeschlagen wegen der grottigen Userland-Implementierung. OpenVPN ist zwar auch Userland, aber mehr als 10x so schnell, wenn man rein nach der Latenz geht.

Edit: Damit keine Missverständnisse aufkommen: Ich halte eine Kernel-Implementierung für den völlig falschen Weg. Ich würde eine nicht-grottige Userland-Implementierung bevorzugen, wie sie OpenVPN eben hat.

Gerade der Umstand, dass es direkt im Kernel ist, macht es so unfassbar schnell, bzw. hält den Latenzoverhead im nicht wirklich messbaren. Leider nur unter Linux.

Die Userland Implementierung von FreeBSD läuft gut, über die von OpenBSD kann ich leider nichts sagen, ich weiß nur das es eine gibt und an der auch rege geschraubt wird.
Von Cloudflare gibts auch eine OS Userlandimplementierung für mehrere Betriebsysteme, aber ich weiß nicht ob da *BSD dabei ist.

 

[Crest]

SierraX: Mach die Ports auf und verwende GRE+IPsec im Transportmode. Falls das nicht geht verwende IPsec mit NAT-T.

 

[SierraX]

Irgendwie muss ich lernen Fragen besser zu stellen.
Ich habe nicht und hatte nie vor das VPN zu ersetzen. IPSec, OpenVPN, TINC sind mir für meinen Anwendungszweck zu aufgeblasen und zu unpraktisch. Aufgeblasen schon alleine weil man etwas nachinstallieren müsste. Zu unpraktisch weil man mit Zertifikaten rum hantieren muss, was SSH schon automatisch macht und man Ports öffnen (ggf. lassen weil nicht eigenes Netz) müsste wo der SSH Port bei den meisten eh schon offen ist.
Den Begriff "PPTP over SSH" hatte ich wohl von einem alten StackOverflow Wiki Artikel und dass das für Verwirrung gesorgt hat tut mir leid.
Es geht mir nur um die Aufrechterhaltung eines Tunnels und @medV2 hat die Frage heute um 12:26 beantwortet.

 

[Zirias]

Ich habe nicht und hatte nie vor das VPN zu ersetzen.

Du bist einfach nur ungefragt beraten worden. Sowas kommt vor, und kann auch manchmal ganz hilfreich sein
Allerdings fehlt mir hier noch der wichtigste Nachteil eines "irgendwas-durch-SSH" VPN: Schlechte Performance bei Paketverlusten. Details gibt's hier: http://sites.inka.de/bigred/devel/tcp-tcp.html

[OpenVPN et al] Zu unpraktisch weil man mit Zertifikaten rum hantieren muss,

Es gibt fertige Scripts für eigene CAs, die sind relativ leicht zu bedienen. Setzt man einmal auf, danach geht es sehr einfach.

was SSH schon automatisch macht

Ne, automatisch ist da nichts. Entweder man erzeugt Keys (die in etwa der Funktion des Keys eines X.509 Zertifikats entsprechen, nur eben ohne Signierung durch eine CA, also muss auch der Server jedem einzelnen Key vertrauen) -- die muss man aber auch selbst passend verteilen -- oder man nimmt mit reiner Passwort-Authentifizierung vorlieb.

und man Ports öffnen (ggf. lassen weil nicht eigenes Netz) müsste wo der SSH Port bei den meisten eh schon offen ist.

Also OpenVPN braucht per default einen UDP Port. Man kann es als Fallback auch noch auf TCP/443 betreiben (wahlweise komfortabel hinter sslh, damit da auch noch ein Webserver laufen kann, oder ein SSH daemon), falls der Client mal in einem seltsam vernagelten Netz steht -- dann allerdings leider auch mit den oben genannten Nachteilen des Tunnelns durch TCP.

 

[midnight]

Gilt das auch für OpenBSD mittlerweile? Als ich das zuletzt angesehen hab, hat es zwischen zwei Kisten direkt nebeneinander im LAN mal eben 20ms Latenz draufgeschlagen wegen der grottigen Userland-Implementierung. OpenVPN ist zwar auch Userland, aber mehr als 10x so schnell, wenn man rein nach der Latenz geht.

Edit: Damit keine Missverständnisse aufkommen: Ich halte eine Kernel-Implementierung für den völlig falschen Weg. Ich würde eine nicht-grottige Userland-Implementierung bevorzugen, wie sie OpenVPN eben hat.

Ja, hier ein kleines howto dazu: https://obscurity.xyz/bsd/open/wireguard.html

 

[SierraX]

Ne, automatisch ist da nichts. Entweder man erzeugt Keys (die in etwa der Funktion des Keys eines X.509 Zertifikats entsprechen, nur eben ohne Signierung durch eine CA, also muss auch der Server jedem einzelnen Key vertrauen) -- die muss man aber auch selbst passend verteilen -- oder man nimmt mit reiner Passwort-Authentifizierung vorlieb.

Ach man muss sich bei OpenSSH selbst um Diffie-Hellman Zertifikate kümmern. Und muss den die Personalisierten X.509 Zertifikate bei OpenVPN nicht selbst verteilen?

Also OpenVPN braucht per default einen UDP Port. Man kann es als Fallback auch noch auf TCP/443 betreiben (wahlweise komfortabel hinter sslh, damit da auch noch ein Webserver laufen kann, oder ein SSH daemon), falls der Client mal in einem seltsam vernagelten Netz steht -- dann allerdings leider auch mit den oben genannten Nachteilen des Tunnelns durch TCP.

Hast du schonmal einen Firewall Antrag in irgendeiner Firma mit mehr als 100 oder 1000 Mitarbeitern gestellt?

 

[double-p]

Hast du schonmal einen Firewall Antrag in irgendeiner Firma mit mehr als 100 oder 1000 Mitarbeitern gestellt?

Solche Firmen machen auch gerne mal 22/tcp zu ("ssh -R" threat) ;-)

Aber mal zum Script: wozu das sleep 120?
Weiterhin wuerde ich da zumindest noch einen ping durchschicken; stale ssh kommt vor.

 

[Zirias]

Ach man muss sich bei OpenSSH selbst um Diffie-Hellman Zertifikate kümmern.

Sowas gibt's gar nicht. OpenVPN /kann/ DH *keys* verwenden, das ist optional, aber emfpehlenswert. Dazu braucht jeder Client das gleiche shared secret.

Und muss den die Personalisierten X.509 Zertifikate bei OpenVPN nicht selbst verteilen?

Wo habe ich denn sowas behauptet? Umgekehrt wird ein Schuh draus, wenn man bei OpenSSH nicht auf simple Passwort-Authentifizierung vertrauen will, muss man ebenfalls Keys verteilen. Und das skaliert sogar schlechter als bei X.509, weil man eben keine Zertifikate hat. Wenn man eh schon verteilt spielt es auch keine Rolle mehr, ob man einem Client zusätzlich noch ein Secret für DH aufspielt.

Hast du schonmal einen Firewall Antrag in irgendeiner Firma mit mehr als 100 oder 1000 Mitarbeitern gestellt?

In so einer Firma wird in der Regel gerade SSH sowieso gesperrt sein, man kann damit ja tunneln. Und andere VPN-Lösungen erst recht. Der Weg drum herum ist (je nach Firewall) eben genau TCP/443 -- allerdings sollte man dann mal über seinen Anwendungsfall nachdenken. Wenn es um ein von der Firma gewünschtes VPN geht, darf auch die Konfiguration der Firewall kein Thema sein.

 

[SierraX]

Wo habe ich denn sowas behauptet? Umgekehrt wird ein Schuh draus, wenn man bei OpenSSH nicht auf simple Passwort-Authentifizierung vertrauen will, muss man ebenfalls Keys verteilen. Und das skaliert sogar schlechter als bei X.509, weil man eben keine Zertifikate hat. Wenn man eh schon verteilt spielt es auch keine Rolle mehr, ob man einem Client zusätzlich noch ein Secret für DH aufspielt.

"-- die muss man aber auch selbst passend verteilen --" Impliziert, das man dass woanders nicht müsse.

In so einer Firma wird in der Regel gerade SSH sowieso gesperrt sein, man kann damit ja tunneln. Und andere VPN-Lösungen erst recht. Der Weg drum herum ist (je nach Firewall) eben genau TCP/443 -- allerdings sollte man dann mal über seinen Anwendungsfall nachdenken. Wenn es um ein von der Firma gewünschtes VPN geht, darf auch die Konfiguration der Firewall kein Thema sein.

Nach drinnen ja ist meist zu. Nach draussen oft nein… zwar nicht die Server Netzwerke, aber die Desknetze. Genau das ist ja der Punkt. Der Klient hat bzw. muss den Port 22 nicht offen haben. Weil man nur einseitig eine Verbindung aufbaut. Selbst wenn man den Port 22 nach draussen zu einer bestimmten Adresse beantragen muss, kann man das vor Security wesentlich besser verargumentieren (z.B. mit einem SFTP Server den man zum Arbeiten braucht) als einen Monitoring Alarm weil man zu oft auf 443 womöglich sogar noch ohne DNS Eintrag geht. Und da keine Seite hinterlegt ist wenn ein Analyst mal nachguckt. Zusätzlich ist die Frage ob das dann auch noch hinter einem Proxy funktionert. Ich hab ein OpenSSH das darauf lauscht angeblich soll das ja auch funktionieren und bin da bisher bei Proxies immer gescheitert.

 

[SierraX]

Aber mal zum Script: wozu das sleep 120?

Ich meine dass ich da eine Schleife einbauen wollte die nach 2 Minuten nochmal checkt… um dann festzustellen dass das Blödsinn ist, weil es die Verbindung ja nicht selbständig wieder aufbaut. Angefangene Sachen die nicht schaden bleiben bei mir gerne mal drin.

Weiterhin wuerde ich da zumindest noch einen ping durchschicken; stale ssh kommt vor.

Sowas ähnliches hab ich mir auch schon gedacht, aber eher zu Monitoring zwecken. Aber reicht ICMP da aus? Hätte jetzt eher gesagt das ich in regelmässigen Abständen mit Curl auf port 22 haue