22
MS SQL 2019 Server Zugriff über VPN
Hallo zusammen.
Wir haben aktuell ein etwas schräges Problem ...
ich würde euch erst einmal den Aufbau des Netzwerks "zeigen":
Die Mitarbeiter programmieren auf ihren eigenen Geräten und müssen Zugriff auf den SQL Server haben der in der Cloud ist.
Die Authentifizierung am SQL Server läuft über die AD.
Soweit so gut.
Die Mitarbeiter die im Büro sitzen können ohne Probleme arbeiten und haben gute Zugriffszeiten auf den SQL Server.
Sobald nun ein Mitarbeiter im Home Office arbeitet und auf den SQL Server zugreifen möchte, sind die Zugriffszeiten überirdisch.
Eine abfrage die im Büro 0,x Sekunden braucht, braucht im Home Office über 2 Minuten.
Wir hatten dann die VPN Verbindung vom Home Office auf den Hauptstandort und dann wiederum in die Cloud im Verdacht, also haben wir eine zusätzliche VPN Verbindung in die Cloud eingerichtet und das Routing über die VPN Verbindung in den Hauptstrandort deaktiviert.
Leider hat dies aber auch keine Abhilfe gebracht.
Ebenso der Wechsel von Sophos SSL VPN (OpenVPN) auf IPSec hat keine Besserung gebracht.
Der zusätzliche DC in der Cloud leider ebenso wenig (Gedanke war dass evtl. der "Authenzifizierungsweg" über die VPNs zulange dauert, aber die Authentifizierung bzw. Anmeldung am Server geht recht flott, erst die Abfragen dauern dann ewig lang.
Ich bin leider mit meinem Latein am Ende
Hat von euch noch jemand eine Idee wie wir das Lösen könnten?
Viele Grüße
Manuel
Wir haben aktuell ein etwas schräges Problem ...
ich würde euch erst einmal den Aufbau des Netzwerks "zeigen":
Die Mitarbeiter programmieren auf ihren eigenen Geräten und müssen Zugriff auf den SQL Server haben der in der Cloud ist.
Die Authentifizierung am SQL Server läuft über die AD.
Soweit so gut.
Die Mitarbeiter die im Büro sitzen können ohne Probleme arbeiten und haben gute Zugriffszeiten auf den SQL Server.
Sobald nun ein Mitarbeiter im Home Office arbeitet und auf den SQL Server zugreifen möchte, sind die Zugriffszeiten überirdisch.
Eine abfrage die im Büro 0,x Sekunden braucht, braucht im Home Office über 2 Minuten.
Wir hatten dann die VPN Verbindung vom Home Office auf den Hauptstandort und dann wiederum in die Cloud im Verdacht, also haben wir eine zusätzliche VPN Verbindung in die Cloud eingerichtet und das Routing über die VPN Verbindung in den Hauptstrandort deaktiviert.
Leider hat dies aber auch keine Abhilfe gebracht.
Ebenso der Wechsel von Sophos SSL VPN (OpenVPN) auf IPSec hat keine Besserung gebracht.
Der zusätzliche DC in der Cloud leider ebenso wenig (Gedanke war dass evtl. der "Authenzifizierungsweg" über die VPNs zulange dauert, aber die Authentifizierung bzw. Anmeldung am Server geht recht flott, erst die Abfragen dauern dann ewig lang.
Ich bin leider mit meinem Latein am Ende
Hat von euch noch jemand eine Idee wie wir das Lösen könnten?
Viele Grüße
Manuel
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 955942830
Url: https://administrator.de/forum/ms-sql-2019-server-zugriff-ueber-vpn-955942830.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
22 Kommentare
Neuester Kommentar
Hallo,
eine mögliche Ursache kann eine fehlerhafte Namensauflösung über das VPN sein.
Gruß
CH
eine mögliche Ursache kann eine fehlerhafte Namensauflösung über das VPN sein.
Gruß
CH
Leider nein.
Die Namensauflösung funktioniert fehlerfrei - sowohl im Cloud Netz über die S2S als auch im "lokalen" Netz über die Client-VPN Verbindung.
Die Namensauflösung funktioniert fehlerfrei - sowohl im Cloud Netz über die S2S als auch im "lokalen" Netz über die Client-VPN Verbindung.
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
Zitat von @Th0mKa:
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
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
Danke schonmal für eure Antworten!
Einfluss auf die Hardware im Home Office haben wir leider nur bei den Notebooks
Den Internetanschluss und den dazugehörigen Router müssen die Mitarbeiter selbst beschaffen.
Klar, wenn die Bandbreite schon unterirdisch ist, geht da nicht viel.
Allerdings ist das Problem auch bei Mitarbeitern die eine gute Verbindung (Glasfaser mit 250mbit/s) haben das selbe wie bei denen mit 6mbit/s Verbindungen. Ebenso egal ob der Anbieter Vodafone, 1&1 oder Telekom heisst.
Oder reden wir gerade aneinander vorbei?
Viele Grüße
Manuel
Einfluss auf die Hardware im Home Office haben wir leider nur bei den Notebooks
Den Internetanschluss und den dazugehörigen Router müssen die Mitarbeiter selbst beschaffen.
Klar, wenn die Bandbreite schon unterirdisch ist, geht da nicht viel.
Allerdings ist das Problem auch bei Mitarbeitern die eine gute Verbindung (Glasfaser mit 250mbit/s) haben das selbe wie bei denen mit 6mbit/s Verbindungen. Ebenso egal ob der Anbieter Vodafone, 1&1 oder Telekom heisst.
Oder reden wir gerade aneinander vorbei?
Viele Grüße
Manuel
Es geht nicht um Bandbreite sondern um Latenz.
Ahja, klar 
Wobei ja die Latenz ebenso bei einem Glasfaseranschluss besser sein sollte als bei einem 6mbit/s Kupferanschluss in Hinterdupfingen.
Da ich leider keine Ahnung von SQL hab, hab ich nun mal als "Latenztest" einen einfachen Ping gemacht:
die linke Powershell ist vom "Home Office" über VPN auf den DC im Hauptstandort
die rechte Powershell ist vom "Home Office" über VPN und S2S VPN auf den SQL Server in der Cloud
die untere Powershell ist vom RD Server im Hauptstandort auf den SQL Server in der Cloud
Und der Test lief nun von einem schnellen Anschluss ...
Kann / sollte ich die Latenz beim SQL Server noch anders testen?
Wobei ja die Latenz ebenso bei einem Glasfaseranschluss besser sein sollte als bei einem 6mbit/s Kupferanschluss in Hinterdupfingen.
Da ich leider keine Ahnung von SQL hab, hab ich nun mal als "Latenztest" einen einfachen Ping gemacht:
die linke Powershell ist vom "Home Office" über VPN auf den DC im Hauptstandort
die rechte Powershell ist vom "Home Office" über VPN und S2S VPN auf den SQL Server in der Cloud
die untere Powershell ist vom RD Server im Hauptstandort auf den SQL Server in der Cloud
Und der Test lief nun von einem schnellen Anschluss ...
Kann / sollte ich die Latenz beim SQL Server noch anders testen?
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 !
Das muss ich dann nochmal am Montag bei einem der MAs machen.
Ich werde mich nochmal melden
Ich werde mich nochmal melden
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.
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
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.
Beste Grüsse aus BaWü
Alex
@MysticFoxDE
Das mit dem Ping ist noch ein guter Tipp, die Clients können durch den Tunnel alles anpingen (im Hauptstandort, als auch die Geräte in der Cloud). Allerdings ... ich weiss nicht ob es anders herum geht, das müsste ich mal ausprobieren.
Die VPN Clients bekommen den DC als DNS spendiert, die VPN Clients melden sich ebenfalls an der Domäne an, dies funktioniert auch problemlos.
Das mit dem Ping ist noch ein guter Tipp, die Clients können durch den Tunnel alles anpingen (im Hauptstandort, als auch die Geräte in der Cloud). Allerdings ... ich weiss nicht ob es anders herum geht, das müsste ich mal ausprobieren.
gerade getestet, die Clients im Homeoffice sind nicht vom Server aus erreichbar, dann schau ich mal das diese Richtung auch klappt.
Die VPN Clients bekommen den DC als DNS spendiert, die VPN Clients melden sich ebenfalls an der Domäne an, dies funktioniert auch problemlos.
die Clients können durch den Tunnel alles anpingen
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
Wichtig ist ob sie die Hostnamen (DNS Auflösung) pingen können und nicht nur die nackten IPs.
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 mit dem Ping ist noch ein guter Tipp, die Clients können durch den Tunnel alles anpingen (im Hauptstandort, als auch die Geräte in der Cloud). Allerdings ... ich weiss nicht ob es anders herum geht, das müsste ich mal ausprobieren.
gerade getestet, die Clients im Homeoffice sind nicht vom Server aus erreichbar, dann schau ich mal das diese Richtung auch klappt.
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
zum Überprüfen ob ICMP an sich funktioniert ist es vollkommen schnuppe
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.da zu den bestehenden TCP & IP Headern des Datenpakets noch der VPN Header hinzukommt.
plus PPPoE Header sofern die VPN Strecke über xDSL rennt.
Guten Morgen!
Sorry für die späte Antwort - leider habe ich früher keinen Mitarbeiter im Home Office zur Verfügung gehabt.
Aus dem Home Office sind die Server per FQDN erreichbar. Auf den Screenshots habe ich von meiner "Adminmaschine" aus getestet, die ist absichtlich nicht in der Domäne und auch nicht auf dem lokalen DNS, daher sind die Server von aus nicht per FQDN erreichbar.
Wir haben nun die MTU auf der VPN Verbindung angepasst von vorher 1400 auf 1370 - keine Änderung.
Ebenso hab ich mal probeweise die Firewall auf dem Client komplett deaktiviert - Ping vom Server auf den Client funktioniert, leider keine Änderung
Was ich allerdings jetzt nicht getestet hab, ist ob der Ping dann auch per FQDN auf den Client vom Server aus geht ... dies sollte aber denke ich gehen müssen, oder?
Sorry für die späte Antwort - leider habe ich früher keinen Mitarbeiter im Home Office zur Verfügung gehabt.
Aus dem Home Office sind die Server per FQDN erreichbar. Auf den Screenshots habe ich von meiner "Adminmaschine" aus getestet, die ist absichtlich nicht in der Domäne und auch nicht auf dem lokalen DNS, daher sind die Server von aus nicht per FQDN erreichbar.
Wir haben nun die MTU auf der VPN Verbindung angepasst von vorher 1400 auf 1370 - keine Änderung.
Ebenso hab ich mal probeweise die Firewall auf dem Client komplett deaktiviert - Ping vom Server auf den Client funktioniert, leider keine Änderung
Was ich allerdings jetzt nicht getestet hab, ist ob der Ping dann auch per FQDN auf den Client vom Server aus geht ... dies sollte aber denke ich gehen müssen, oder?
habe ich jetzt gerade noch getestet, der Client ist auch per FQDN vom Server aus pingbar.
Noch zur Erklärung wie ich auf die 1370 gekommen bin: ich habe jeweils auf dem Client und dem Server einen ping IPADRESSE -f -l xxxx gestartet und den "Gemeinsamennenner" genommen - vom Server zum Client wäre noch 1400 gegangen aber von Client zu Server ging ohne Fragmentierung max. 1370 durch. Sollte ich dann dort noch etwas Overhead abziehen > d.h. das dann selbst die 1370 noch zu hoch sind?
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?
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?
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
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!
VPN Netz ist 10.242.0.0/24 und wird von der Sophos verwaltet
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.
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:
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.
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.
dann inkludiert das immer auch diese ungewollten IP Netze
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:
Bei "nslookup" wird sowohl im LAN als auch im VPN nur der erste DC aufgelistet.
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
- alle Server sind auf MS Windows 2019er Servern in MS Hyper-V virtualisiert
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!)
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.
Set-NetTCPSetting -SettingName Datacenter -CongestionProvider DCTCP -EcnCapability Enabled
Set-NetTCPSetting -SettingName Internet -CongestionProvider DCTCP -EcnCapability EnabledAuch das eklige ACK Delay kann eine Rolle spielen, dieses kann man mit dem folgenden Befehl deaktivieren.
Set-NetTCPSetting -SettingName Datacenter -DelayedAckFrequency 1
Set-NetTCPSetting -SettingName Internet -DelayedAckFrequency 1Dann 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.
netsh int tcp set global autotuninglevel=disabledHast du schon RSC auf dem V-Switch deaktiviert?
Wenn nicht, dann lass mal den folgenden Befehl auf dem Hyper-V laufen.
Get-VMSwitch | Set-VMSwitch -Name SETswitch -EnableSoftwareRsc $falseEs 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.
Remove-WindowsFeature -Name "windows-defender" 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
2
Wenn es das war bitte nicht vergessen deinen Thread hier als erledigt zu markieren!
