OpenVPN Verbindung für DB Zugriffe optimieren

viragomann

@exordium
Ich hatte mit "Block Outside DNS" und Windows 10 Clients eine ziemlich schlechte Erfahrung gemacht. Der VPN Server war dabei aber außerhalb des Firmen-AD-Netzes.

So ziemlich jeglicher Authentifizierungs-/Autorisierungsprozess dauerte elendslange. Allerdings nicht nur welche im Firmen-AD, auch RDP oder SVN im Zielnetz der VPN, und das auch ganz ohne Verbindung ins Firmen-AD.

Das Problem beschränkte sich aber auf die Anmeldevorgänge, danach lief die Kommunikation normal.

Exordium

@jegr said in OpenVPN Verbindung für DB Zugriffe optimieren:

Ich würde daher in den beiden Richtungen forschen :)

Hi Jens

Ja, natürlich. Es muss NICHT direkt mit dem OpenVPN zu tun haben, sondern kann, wie Du schon sagst, auch eine andere Ursache haben. Es geht ja auch sonst sehr gut mit OpenVPN zu arbeiten. Ich bin begeistert wie stabil und zuverlässig das alles funktioniert! Die Probleme zeigen sich ja auch tatsächlich nur bei den "Sonderfällen" AD, bzw. DB. Der Rest geht wie geschnitten Brot! Hätte ich asynchrones Routing oder so ein Zeug, müsste ich ja auch deutlich spürbare Einbrüche... z.B. bei einem copy auf bzw. von ner smb share haben. Diese Übertragungen sind aber sehr nahe am max. möglichen dran, was meine Leitung so her gibt. Vermutlich muss ich bei meinem Lieblings-pfsense-Support mal nen Case aufmachen...

Gruß
Exo

Exordium

@viragomann said in OpenVPN Verbindung für DB Zugriffe optimieren:

@exordium
Ich hatte mit "Block Outside DNS" und Windows 10 Clients eine ziemlich schlechte Erfahrung gemacht. Der VPN Server war dabei aber außerhalb des Firmen-AD-Netzes.

So ziemlich jeglicher Authentifizierungs-/Autorisierungsprozess dauerte elendslange. Allerdings nicht nur welche im Firmen-AD, auch RDP oder SVN im Zielnetz der VPN, und das auch ganz ohne Verbindung ins Firmen-AD.

Das Problem beschränkte sich aber auf die Anmeldevorgänge, danach lief die Kommunikation normal.

Hi. Nein, das stellt sich bei mir tatsächlich auch etwas anders dar. Das Anmelden und Cert-Check geht super schnell. Dabei wird auch das AD direkt angefragt. Auch RDP völlig problemlos.

Gruß
Exo

JeGr

@exordium said in OpenVPN Verbindung für DB Zugriffe optimieren:

Auch RDP völlig problemlos.

OK das macht mich dann schon stutzig. Normalerweise auch bei MTU Problemen ist das gern eher eine Sache von größeren Datenraten oder Filesystem/RDP Transfers die einbrechen, während kleinere Sachen wie SSH und Co sauber gehen. DAS ist dann schon sehr verwunderlich.

Hmm, da du sagst das trifft nur per VPN zu, kannst du ggf. mal eine kleine Aufstellung machen, was genau langsam ist? Aus den vorhandenen Aussagen sehe ich "RDP -> gut, Datentransfer via SMB/CIFS -> gut, etc." aber welche Zugriffe genau sind dann die langsamen und wie genau äußert sich dann langsam? Also eher "erster Zugriff" ist langsam oder die Antwort ist immer langsam? Kannst du die genauen Arten und Phänomene etwas eingrenzen? Ich bekomme da vielleicht eine Vermutung, dass es eventuell was mit reverse DNS zu tun haben könnte?

Cheers

Exordium

@jegr said in OpenVPN Verbindung für DB Zugriffe optimieren:

Hmm, da du sagst das trifft nur per VPN zu, kannst du ggf. mal eine kleine Aufstellung machen, was genau langsam ist? Aus den vorhandenen Aussagen sehe ich "RDP -> gut, Datentransfer via SMB/CIFS -> gut, etc." aber welche Zugriffe genau sind dann die langsamen und wie genau äußert sich dann langsam? Also eher "erster Zugriff" ist langsam oder die Antwort ist immer langsam? Kannst du die genauen Arten und Phänomene etwas eingrenzen? Ich bekomme da vielleicht eine Vermutung, dass es eventuell was mit reverse DNS zu tun haben könnte?

Gerne.

1.) Zugriff über Aruba Remote AccessPoint:

AD Benutzer- und Computer verwalten.
Programm bereit nach ca. 1,5s. Arbeiten im Programm. völlig smooth, keine Wartezeiten beim Auflisten der Einträge und Container. Programm DNS verwalten. Geht instant auf, arbeiten wie im lokalen Netz
Anwendung Docusnap (Client) Dieses Programm öffnet eine MS-SQL Serververbindung, da sich sämtliche Daten mit denen das Programm arbeitet, darin befinden. Hier laufen Tabellenchecks und etliche SQL-Abfragen und es werden ordentliche Datenmengen vom Server zum Client übertragen.
Dauer Programmstart bis Programm ready:
Gemittelter Wert aus 5 Wiederholen: 40s
RDP Zugriff auf x-beliebigen Host: Praktisch wie im lokalen Netz, keine spürbaren Delays im Aufbau, als auch Arbeiten

2.) Zugriff über OpenVPN (Computer zuvor neu gestartet, Aruba RAP offline genommen)

AD Programme - Unbenutzbar. Ladezeiten teils > 5 Min. Wenns Fenster dann mal auf ist, deutliche Verzögerungen beim Öffnen der Container (inkl Sanduhr-Busypointer)
Docusnap: Mal eine, mal 2 Minuten vom Programmstart bis Programm ready... Im Mittel doppelt so lange wie über die RAP Lösung.
RDP ist auch hier völlig problemlos. Identisch zum RAP

Auch Files öffnen via SMB völlig smooth bei beiden Verbindungen.

JeGr

@exordium Okidok,

AD Benutzer und Container: das greift doch via AD auf den entsprechenden DC/Server zu. Da hängt dann aber doch Namensauflösung mit drin? Er versucht doch da im Normalfall den Server zu kriegen? Bekommt er den Namen, Kurznamen, AD Domain etc. alles sauber via VPN oder klemmts vielleicht da schon? Hatte ich tatsächlich schon mehrfach, dass es da an Namensraum scheitert.

Dito beim MSSQL ich vermute auch, dass da für den Zugriff auf die MSSQL wahrscheinlich nen Host-/Domainnamen verwendet wird und keine direkte IP?

Das könnte dann schon damit zusammenhängen, dass sich vielleicht ein lokaler DNS vordrängelt und die Namensauflösung kaputtspielt - das wäre nur mal so mein erster Gedanke dazu. Ich hatte da auch irgendwo mal einen Link zu, wie man hier manuell in Windows die Adapter Reihenfolge rekonfigurieren kann (Powershell lässt grüßen) um das OVPN Interface vom Setting abzusenken, damit es unter der LAN Gewichtung ist wenn verbunden und die damit assoziierten DNSe etc. immer Vorrang haben vor lokalem Krams.

Wäre so die erste Sache was mir einfällt. :)

Exordium

@jegr said in OpenVPN Verbindung für DB Zugriffe optimieren:

@exordium Okidok,

AD Benutzer und Container: das greift doch via AD auf den entsprechenden DC/Server zu. Da hängt dann aber doch Namensauflösung mit drin? Er versucht doch da im Normalfall den Server zu kriegen? Bekommt er den Namen, Kurznamen, AD Domain etc. alles sauber via VPN oder klemmts vielleicht da schon? Hatte ich tatsächlich schon mehrfach, dass es da an Namensraum scheitert.

Dito beim MSSQL ich vermute auch, dass da für den Zugriff auf die MSSQL wahrscheinlich nen Host-/Domainnamen verwendet wird und keine direkte IP?

Das könnte dann schon damit zusammenhängen, dass sich vielleicht ein lokaler DNS vordrängelt und die Namensauflösung kaputtspielt - das wäre nur mal so mein erster Gedanke dazu. Ich hatte da auch irgendwo mal einen Link zu, wie man hier manuell in Windows die Adapter Reihenfolge rekonfigurieren kann (Powershell lässt grüßen) um das OVPN Interface vom Setting abzusenken, damit es unter der LAN Gewichtung ist wenn verbunden und die damit assoziierten DNSe etc. immer Vorrang haben vor lokalem Krams.

Wäre so die erste Sache was mir einfällt. :)

Ich habe mal das TCPView installiert um zu schauen, welche Connections die jeweiligen Programmaufrufe verwenden. ADS und DB Server werden tatsächlich namentlich angesprochen, allerdings sehe ich auch unmittelbar danach ein "Established" bei Verbindungsstatus.

Docusnap öffnet den DB-Server UND auch eine ADS Connection. Evtl. liegt das Docusnap-Problem gar nicht an der Datenbank. Hierzu werde ich mir lokal mal das SQL Management Studio installieren und prüfen.

Ansonsten gehen die DNS Abfragen der lokalen Domain völlig problemlos vom Client aus...
Ein nmap quickscan auf das entsprechende /24 Netzwerksegment listet alle ~240 IPs inkl. der Servernamen problemlos innerhalb einer Minute auf.

Evtl. ein Zugriffs-/Rechteproblem des OVPN-Subnetzes auf das AD?

A Former User

@exordium
2.20 GHz und 4C /8 T sind auch nicht so der "Bringer" bei
mehr SOHO Mitarbeitern und wenn da noch PPPoE mit im
Spiel ist das ganze auf einen CPU Kern festgenagelt!

IPSec wird mittels AES-NI unterstützt und bei OpenVPN
zählt eben "nur" der rohe CPU-Takt. OpenVPN ist auch noch in der Entwicklungsphase und IPSec ist ausgereift! Und dann
wäre da noch der Aruba PAP der eventuell noch einen ASIC
verlötet bekommen hat und das macht dann eben den
Unterschied!

Exordium

Ah, sorry ... diese Angaben stimmen nicht mehr ... Es ist ein 8/16c System mit aktuellen Xeon und 32GB. Es ist auch kein OVPN typisches Performance Problem. Meine 100MBit DSL wird mit VPN zu 100% genutzt. Da rauschen 10-12MB/s (smb-share filecopy) problemlos durch. Ich habe diverse Wiresharks-Tests gemacht und einmal die OVPN-Verbindung und die Aruba-Verbindung bei den Showstopper-Applikationen mitgeschnitten. Hier fällt auf, dass M$ scheinbar der OVPN Verbindung nicht traut! Während durch den Aruba-AP die AD Anfragen als authentisierter LDAP Traffic durchgeht, verwendet das Programm über OVPN CLDAP im Read-Only Mode und jede Menge Wartezeit... und weitere Ungereimtheiten...Falsch zusammengebaute SRV _ldap DNS Anfragen (Seit Win 2000 ist der Bug bekannt!) und dann noch ein Kerberos Auth Problem...
Keine Lust mehr diesen Redmont Müll weiter hinterher zu rennen.

JeGr

@dobby_ said in OpenVPN Verbindung für DB Zugriffe optimieren:

zählt eben "nur" der rohe CPU-Takt. OpenVPN ist auch noch in der Entwicklungsphase und IPSec ist ausgereift! Und dann

Wat? Seit wann ist OVPN in der "Entwicklungsphase". Die letzten 10 Jahre nicht mitbekommen?
Du meinst eher Wireguard? Selbst OVPN unterstützt AES-NI schon länger und mit AES-GCM auch AEAD Cipher.

Also bitte keine so wilden Behauptungen

Exordium

Open VPN ist für unsere Firma die führende Lösung für Home-Office und unterwegs Arbeiten! Das funktioniert seit der Einführung bestens bei 600-800 Clients! Rund 50% davon sind täglich verbunden und geben keinen Anlass zum Klagen. Der eine Spezialfall wo es eben nicht gut funktioniert, ist nach intensiver Recherche auch nicht Open VPN direkt anzukreiden.
Die Aruba Lösung ist auch toll und vor allem sehr end-user-friendly! Aber sie verursacht nicht gerade geringe Kosten, was die Hardware und Lizenzen angeht. Daher verwenden wir diese auch nur dort, wo Open VPN strauchelt. Meist liegt es dann aber an komischen IPv4/v6 Problemen, die der Provider oder deren Endgeräte verursachen.