MS SQL 2019 Server Zugriff über VPN

Fast richtig, nicht die Authentifizierung dauert zu lange sondern die SQL Statements. Die Latenz vom Homeoffice ist vermutlich deutlich höher als aus dem Büro.

/Thomas

Dem schließe ich mich an.

Wenn Ihr für Homeoffice Consumer-Produkte verwendet, stehen die Wörter "bis zu" gerne in Verbindung mit der Bandbreite, die dazu meist asymmetrisch ist.

Ich halte das speziell für Datenbankverbindungen für fatal.

Gruß
bdmvg

Es geht nicht um Bandbreite sondern um Latenz.

Sinnvoll wäre auch mal ein nslookup via VPN vom Homeoffice auf alle für die SQL Kommunikation relevanten Hostnamen um einmal die Auflösung und die DNS Zeiten zu sehen. Dadurch das es auch bei High Speed Anschlüssen zu solchen Fehlern kommt spricht vermehrt für ein DNS Problem (Timeout) der HO Clients !

also es gibt noch einen Aspekt - die Latenz/Bandbreite vom Client zum SQL Server. Je nachdem was die Applikation da so treibt bzw der Entwcikler, hat man unter Umständen große Probleme

a) mit den Latenzen. VPN über eine Cloud ist immer ein "Umweg" für die Daten, zwar einfach einzurichten z.B. bei AWS oder Azure, aber die Daten vom Client gehen dann zu einem virtuellen VPN System in der Cloud und dann zum Büro wo der SQL Server steht. Bestimmte Aufgaben rufen viele viele kleine Collections ab oder schreiben sie, und die sind nur schnell wenn der SQL Server in wenigen Milisekunden per Ping erreichbar ist. Auch ist so ein DAtenpaket vom MS SQL Server 4 kB groß, die MTU in öffentlichen Netzen aber 1,5 kB, sprich ein IP PAket wird "zerlegt" beim SEnden und "zusammengebaut" auf der Empfangsseite, was mit zusätzlichen Latenzen einhergeht.

b) mit den Bandbreiten. Ich hatte neulich einen Workload, der 200 Mbit Traffic vom bzw zum SQL Server erzeugt.... die "ausgehende" Bandbreite im Homeoffice sind fast immer im einstelligen Megabitbereich, selbst mit dem 1000/50 Anschluß und einer direkten VPN Anbindung ans Büro komme ich nicht an die LAN-Bedingungen heran, die ich hab wenn mein Endgerät direkt dort ins LAN eingestöpselt ist.

Moin Manuel,

deiner Problem könnte meiner Ansicht nach an zwei Dingen liegen.

1. Das ICMP Protokoll sollte in dieser Konstellation immer sowohl vom Server bis zum Client freigegeben sein und auch in die andere Richtung.

Stichwort: Path MTU Discovery (PMTUD)
https://en.wikipedia.org/wiki/Path_MTU_Discovery

Sprich, der SQL Server muss den Remoteclient anpingen können und der Remoteclient muss auch den SQL Server anpingen können.


2. Die Mitarbeiter im Büro bekommen wahrscheinlich per DHCP den lokalen DC als DNS aufs Auge gedrückt und die Remoteclients bekommen die XG als DNS Server verpasst.
Wenn ja, dann stelle bitte den DNS Server der SSL-Clients der XG mal auf den internen DC um.
Ich weis aus vielen eigenen Erfahrungen, dass der DNS Forwarder der XG's oft eine echt miese Zicke sein kann. 🙃

Beste Grüsse aus BaWü

Alex

Wichtig ist ob sie die Hostnamen (DNS Auflösung) pingen können und nicht nur die nackten IPs.

Moin aqui,


zum Überprüfen ob ICMP an sich funktioniert ist es vollkommen schnuppe ob man das Ziel per IP oder FQDN anpingt. 😉

Wenn du per FQDN anpingst, dann testest du lediglich quasi gleichzeitig auch ob die DNS Auflösung funktioniert.
Für den PING selbst ist es vollkommen irrelevant ob du mit FQDN kommst oder direkt mit der IP.
Der Ping selber läuft ausschließlich über IP/ICMP ohne jeglichen Hostheader der den FQDN enthält, wie es z.B. bei HTTP/HTTPS der Fall ist.

Beste Grüsse aus BaWü
Alex

Moin Manuel,


da würde ich ja fast eine Halbe Kiste guten Bölkstoff verwetten, dass genau das dein Problem ist.
Wenn vom Server Richtung Client ICMP nicht funktioniert / freigeschaltet ist, dann funktioniert auch PMTUD nicht.

Die Folge ist:
Ohne PMTUD versendet der Server die Antwortpakete gemäss seiner Standard MTU Vorgabe, immer mit einer Payload von 1460 Bytes pro TCP/IP Paket richtung Client. Spättestens wenn dieses Packet durch einen VPN Tunnel muss, kann es nicht mehr an einem Stück übermittelt werden, da zu den bestehenden TCP & IP Headern des Datenpakets noch der VPN Header hinzukommt. Um die Daten dennoch übermitteln zu können, geht das VPN-Gateway her und fragmentiert das ursprüngliche Packet in ein grosses und ein kleineres Paket und das klappt öfters mehr schlecht als recht. 🙃

Und wenn du dann auf den NIC's (Server & Client) noch LSO und RSC eingeschaltet hast, dann kannst du der SQL Performance auch gleich gute Nacht sagen. 😉

Beste Grüsse aus BaWü

Alex

Das ist richtig. Es sollte auch rein nur dafür sein zu überprüfen ob generell interne Hostnamen aufgelöst werden können. Also ein reiner DNS Check. Das ICMP an sich dabei vollkommen irrelevant ist, ist klar.
plus PPPoE Header sofern die VPN Strecke über xDSL rennt.

Sorry, dass ich diesen alten Thread noch mal nach oben holen muss, aber er passt für mein Problem am besten.
Gibt es hierfür inzwischen eine Lösung?

zu meinem Problem:
- wir haben eine Sophos UTM Firewall
- in der Sophos VPN Verbindung sind alle Ports und Protokolle für die Mitarbeiter freigegeben
- wir haben zwei Programme, mit denen die Mitarbeiter sowohl im LAN als auch im VPN auf vier SQL-Datenbanken zugreifen müssen
- alle Server sind auf MS Windows 2019er Servern in MS Hyper-V virtualisiert
- lokales Netzwerk ist 192.168.0.0/20 (192.168.0 bis 192.168.2 wird nicht verwendet, da diese Bereiche oft von privaten lokalen Netzwerken verwendet werden und dies im VPN Probleme gemacht hatte)
- VPN Netz ist 10.242.0.0/24 und wird von der Sophos verwaltet

wir HATTEN einen MS Windows Server 2012-R2 mit einem MS-SQL 2012 Express

nach Umstellung auf einen MS Windows Server 2019 mit einem MS-SQL 2019 Express können die Mitarbeiter im LAN fast normal weiterarbeiten (es ist deutlich langsamer geworden - keine Ahnung woran das liegt - aber es funktioniert)
Im VPN geht aber fast nichts mehr bzw. ist so langsam, dass es nicht mehr benutzbar ist (z.B. der Start eines Programmes, bei dem am Anfang nach der Anmeldung gleich ein großer Datensatz geladen wird, benötigt im Büro ca. 30 Sekunden; früher im VPN ca 50 Sekunden; jetzt im VPN bis zu 30 MINUTEN!)

Ich kann jeden von jedem Pingen (Server, lokalen Rechner, VPN Rechner) sowohl IP als auch Namen.
Server-Ping hat vom VPN Rechner aus Top-Zeiten (20-55ms)

Wir haben drei synchronisierte domain-Controller mit DNS-Funktion. Diese werden bei "ipconfig /all" auch angezeigt. Bei "nslookup" wird sowohl im LAN als auch im VPN nur der erste DC aufgelistet. Ebenso ist beides mal in nslookup auch der problematische SQL-Server bekannt.

Nachdem wir bei einer Software den Zugriff von Servername\Instanz auf IP,Port umgestellt hatten, haben wir wieder halbwegs vernünftige SQL-Zugriffszeiten.
Bei der anderen Software ist dies aber nicht so ohne weiteres möglich. Ausserdem ist dies ja ein eindeutiges Zeichen, dass irgendetwas nicht ganz stimmen kann.

An Paketgrößen oder NIC Einstellungen möchte ich nicht rumdoktern, da der Rest ja funktioniert und die Nebeneffekte nicht absehbar sind.

Hat jemand einen Lösungsvorschlag oder sonst etwas, das ich noch überprüfen sollte?

Diese Anmerkung ist sinnfrei und löst dein Problem auch nicht, denn in den Phase 2 Credentials ist einzig und allein die Netzwerkmaske entscheidend!!
Wenn ihr da dann fälschlicherweise eine /22 angegeben habt dann inkludiert das immer auch diese ungewollten IP Netze und führt dann zu den entsprechenden VPN Ausfällen.

Das 192.168.0.0er Netz mit welcher maske auch immer zu verwenden ist in sich schon ein grober IP Adressierungsfehler der immer und immer wieder zu VPN Problemen führen wird. Siehe dazu auch hier:
VPN IP Adressierung
Daran sollte man sich strikt halten!
Wäre unsinnig, denn bei IPsec basieren VPNs gibt es gar kein internes IP Netz.
Leider machst du keinerlei Angaben zum verwendeten VPN Protokoll so das man hier dann nur Kristallkugeln kann.
Nur soviel zum VPN Adressdesign was sicher nicht optimal ist.

Auch ein /20er Prefix bei der LAN Adresse lässt Böses erahnen...zumindestens wenig Fachkenntnisse in IP Netzdesign und IP Adressierung.
Jeder Netzwerker weiss das in einer Layer 2 Broadcast Domain niemals mehr als ~150 Clients sein sollten um die Broad- und Multicast Last erträglch zu halten. Ein Prefix größer als 24 Bit ist also in der Regel niemals erforderlich.
Möglich das bei dem laienhaften Adressdesign mit solchen Netzen und Subnetzmasken diese Lasten dann deutlich zu groß sind was sich bei den erheblich schmaleren Tunnelbandbreiten eines VPNs dann mit solchen Effekten auswirkt wie oben beschrieben.

Um da aber genau und fundiert antworten zu können müsste man die Kommunikation der Clients mit dem SQL Server genauer kennen. Zumindestens ein Wireshark Trace wäre essentiell wichtig um das beurteilen zu können. All das fehlt in der o.a. Beschreibung.
Wenn natürlich jeder Client eine 200MB Datenbank nach dem Start vollständig lädt und/oder zurückschreibt oder andere wilde Dinge via Netzwerk tut muss man sich auch nicht wundern. Besonders bei einem schmalbrüstig angebundenen Server ohne LAG oder höhere Bandbreiten.
Ohne die genauen Datenströme zu kennen ist das auch hier wilde Kristallkugelei.

Danke für Deine Antwort, aber ich glaube (bzw. hoffe), dass das nicht das Problem ist.
Wir haben per se keine Netzwerk oder VPN Probleme - nur mit diesem besagten SQL-Server. Auf dem problematischen Server haben wir auch eine Freigabe und diese funktioniert tadellos.
Ich weiß, dass der Adressbereich 192.168.0.0 bis 192.168.15.255 nicht gut ist. (Gerade auch wegen den Gründen aus dem von Dir verlinkten Tutorial.) Dies ist allerdings historisch so gewachsen. Wir hatten früher den Adressbereich 192.168.2.0/24. Dieser wurde uns zu klein. Ebenso hatten wir in diesem Adressbereich die besagten VPN-Probleme (Wenn lokal eine Server-Ip-Adresse belegt war, dann war der Server nicht erreichbar). Eine Lösung wäre gewesen, dass jeder Mitarbeiter zu Hause seinen Adressbereich überprüfen muss und diesen gegebenenfalls selber ändern muss. Dies wollten wir aber unseren Mitarbeitern nicht antun.
Ein kompletter Wechsel adhoc (in z.B. ein Klasse A oder B Netz) war aber nicht möglich und so blieb uns nur die Möglichkeit des Supernetting. So konnten die Server nach und nach aus dem gefährdeten Bereich umgezogen werden. Im Nachhinein gibt es bessere Lösungen aber hinterher ist man immer schlauer. (Man kann nicht immer alles neu und perfekt machen - ab und zu muss man aus dem Gegebenen das Beste machen)
Zum Glück verwendet nicht jeder Router die besagten Netze - Fritz!Box verwendet z.B. standardmäßig 192.168.178.0/24.
Als VPN Protokol wird SSL verwendet.
Das VPN-Netzwerk ist notwendig, da die lokalen Rechner per lokalem DHCP-Server verwaltet werden und die VPN-Rechner von der Sophos verwaltet werden müssen.
Zu Deiner Anmerkung mit dem /20er Prefix und maximal 150 Clients hab ich noch eine Frage: Wie funktioniert dann ein Broad- oder Multicast in einem Klasse A oder B Netzwerk (65.536-2 bzw 16.777.216-2 mögliche Adressen) ?

Aber wie bereits geschrieben hat mit dieser fehlerhaften Netzkonfiguration bis vor kurzem alles mit dem 2012er Server funktioniert. Erst nach einer Umstellung auf 2019 (weil 2012 ab Oktober von MS nicht mehr supportet wird) geht es nicht mehr.
Es kann auch sein, dass irgendetwas im SQL Server Konfigurations Manager falsch eingestellt ist. Vielleicht hat jemand hierzu einen Tipp was ich noch überprüfen könnte.

Einen Wireshark Trace kann ich aus Datenschutzgründen hier nicht online stellen. Ausserdem wäre der so groß - das wollt ihr nicht haben!

Kann ich ausser Wireshark sonst noch etwas machen um VPN oder die Netzwerkadressierung auszuschließen?
Hinweis: die IP Adresse des 2019 SQL Servers ist 192.168.10.170 - also weit ausserhalb des gefährdeten Bereiches (192.168.0 bis 192.168.2).

Zur Ergänzung:
Ich habe mich in meinem Post oben etwas falsch ausgedrückt:
Was ich sagen wollte:
Sowohl im LAN als auch im VPN wird im nslookup der gleiche Server als DNS-Standardnamenserver verwendet. Wenn ich manuell die anderen zwei DNS-Server abfrage, dann ist dort auch jeweils der problematische SQL-Server bekannt.

Moin @S3vN-Mahoney,





ping gut, Datenübertragung schlecht und beim 2012 war das nicht so ... 🤔 ... sehr interessant.

Das könnte z.B. an dem zwischen Server 2012 und Server 2019, von DCTCP auf CUBIC verändertem TCP-Überlaststeuerungsanbieter liegen.

Mit dem folgenden Befehl, kann man den TCP-Überlaststeuerungsanbieter auf dem Server jedoch wieder auf DCTCP zurückbiegen.

(Befehl funktioniert nur auf Servern)

Auch das eklige ACK Delay kann eine Rolle spielen, dieses kann man mit dem folgenden Befehl deaktivieren.

(Befehl funktioniert nur auf Servern)

Dann könnte die beim Server 2019, auf abartige 1GB erhöhte TCP-Session-Size eine Rolle spielen.
Mit dem folgenden Befehl schraubt man diese wieder auf 64K zurück.


Hast du schon RSC auf dem V-Switch deaktiviert?

Wenn nicht, dann lass mal den folgenden Befehl auf dem Hyper-V laufen.


Es gibt leider noch duzende andere Dinge die man bei einem Server 2019 im Vergleich zu einem Server 2012 machen muss, damit dieser mit +- derselben Performance läuft. 😔😭

Bei dem Server 2019 ist z.B. per Default auch der Defender aktiviert und dieser deaktiviert sich auch nicht automatisch, sobald eine andere AV-Lösung installiert wurde sondern läuft parallel mit. 🤢🤮
Zum Glück kann man den Defender auf den Server mit dem folgenden Befehl jedoch vollständig deinstallieren.


Und nein, dieser Befehl funktioniert leider nicht auf den Clients. 😭

Für weitere Tipps, müsste ich aber mehr über die entsprechende Umgebung wissen.

Beste Grüsse aus BaWü
Alex