16
VPN wie ein Schweizer Käse
Hey zusammen,
ich beobachte momentan zwei Standorte
Hauptstandort A (Telekom Glasfaser; 200 / 100 Mbit/s)
Nebenstandort B (Telekom ADSL2+; 16.000 / 1.000 Kbit/s in der Theorie; praktisch aber nur ca. 10.000 / 800 Kbit/s).
Beide Standorte betreiben pfSense mit jeweils davor geschaltetem Modem für den Internetzugang.
Zwischen beiden Standorten wird eine OpenVPN Verbindung hergestellt, die gemäß Monitoring auch stabil läuft (nur ein Reconnect pro Tag wegen Zwangstrennung). Auch bei starker Auslastung bleibt die Verbindung "aufgebaut".
Aber...
Während Datei-Transfers vom Hauptstandort zum Nebenstandort problemlos funktionieren, beginnt das Problem, wenn der Nebenstandort seinen schwachen Upload nutzen möchte, um Dateien auf den Hauptstandort zu schieben.
Hier ein beispielhaftes Problem:
An einem Computer am Nebenstandort, werden 100 Dateien per Windows Explorer kopiert und im Netzlaufwerk des Hauptstandortes eingefügt (Copy, Paste). Es passiert dann folgendes: Entweder bricht der Upload dann nach kurzer Zeit mit der Meldung "unerwarteter Netzwerkfehler" ab, oder, er läuft durch und kopiert dabei einige Dateien nur zur Hälfte. Das macht sich bemerkbar in PDFs, die nicht mehr geöffnet werden können oder JPEGs, die übersäht sind mit Artefakten. Interessant ist, dass aus Sicht des Windows Explorers in diesem Fall der Kopiervorgang ganz normal abgeschlossen wird (der Balken läuft durch), die Dateien dahinter nach dem Kopiervorgang aber so durchlöchert sind wie ein Schweizer Käse ;)
Ich muss deshalb momentan spezielle Programme für Dateitransfers verwenden, die mit Prüfsummen die Pakete geordnet wieder "zusammenbauen". Die OpenVPN-Verbindung selbst wird via UDP realisiert - aber das sollte an sich ja ausreichend sein?
Ist wirklich der geringe Upload von Nebenstandort hier das entscheidene Problem?
Danke!
Viele Grüße, Chris
ich beobachte momentan zwei Standorte
Hauptstandort A (Telekom Glasfaser; 200 / 100 Mbit/s)
Nebenstandort B (Telekom ADSL2+; 16.000 / 1.000 Kbit/s in der Theorie; praktisch aber nur ca. 10.000 / 800 Kbit/s).
Beide Standorte betreiben pfSense mit jeweils davor geschaltetem Modem für den Internetzugang.
Zwischen beiden Standorten wird eine OpenVPN Verbindung hergestellt, die gemäß Monitoring auch stabil läuft (nur ein Reconnect pro Tag wegen Zwangstrennung). Auch bei starker Auslastung bleibt die Verbindung "aufgebaut".
Aber...
Während Datei-Transfers vom Hauptstandort zum Nebenstandort problemlos funktionieren, beginnt das Problem, wenn der Nebenstandort seinen schwachen Upload nutzen möchte, um Dateien auf den Hauptstandort zu schieben.
Hier ein beispielhaftes Problem:
An einem Computer am Nebenstandort, werden 100 Dateien per Windows Explorer kopiert und im Netzlaufwerk des Hauptstandortes eingefügt (Copy, Paste). Es passiert dann folgendes: Entweder bricht der Upload dann nach kurzer Zeit mit der Meldung "unerwarteter Netzwerkfehler" ab, oder, er läuft durch und kopiert dabei einige Dateien nur zur Hälfte. Das macht sich bemerkbar in PDFs, die nicht mehr geöffnet werden können oder JPEGs, die übersäht sind mit Artefakten. Interessant ist, dass aus Sicht des Windows Explorers in diesem Fall der Kopiervorgang ganz normal abgeschlossen wird (der Balken läuft durch), die Dateien dahinter nach dem Kopiervorgang aber so durchlöchert sind wie ein Schweizer Käse ;)
Ich muss deshalb momentan spezielle Programme für Dateitransfers verwenden, die mit Prüfsummen die Pakete geordnet wieder "zusammenbauen". Die OpenVPN-Verbindung selbst wird via UDP realisiert - aber das sollte an sich ja ausreichend sein?
Ist wirklich der geringe Upload von Nebenstandort hier das entscheidene Problem?
Danke!
Viele Grüße, Chris
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: 351115
Url: https://administrator.de/contentid/351115
Ausgedruckt am: 26.11.2024 um 03:11 Uhr
16 Kommentare
Neuester Kommentar
Moin,
nein, der Upload spielt dabei keine Rolle wenn das VPN sauber läuft... Ich würde mal die Leitungen prüfen - ob du da ggf. grössere Aussetzer hast.
Oder ob dein VPN ggf. ständig abbricht wg. Reconnects....
nein, der Upload spielt dabei keine Rolle wenn das VPN sauber läuft... Ich würde mal die Leitungen prüfen - ob du da ggf. grössere Aussetzer hast.
Oder ob dein VPN ggf. ständig abbricht wg. Reconnects....
Hi,
wenn der Tunnel, wie vermutet, regelm. zusammenbricht, checke mal die MTU an dem kleinen Standort.
wenn der Tunnel, wie vermutet, regelm. zusammenbricht, checke mal die MTU an dem kleinen Standort.
Danke für eure Antworten.
Die MTUs auf beiden Seiten habe ich überprüft. Sie betragen jeweils 1492. Beide Anschlüsse werden von der Telekom zur Verfügung gestellt.
Gemäß den pfSense-Logs läuft die OpenVPN Verbindung konstant. Sprich, auch bei maximal ausgelastetem VPN-Tunnel bleibt die Verbindung bestehen. Es ist nur jeweils um 04.30 Uhr eine Verbindungsunterbrechung in den Logs aufzufinden, die aber bedingt ist durch die Zwangstrennung und dem Neueinholen der IP-Adresse.
Die MTUs auf beiden Seiten habe ich überprüft. Sie betragen jeweils 1492. Beide Anschlüsse werden von der Telekom zur Verfügung gestellt.
Gemäß den pfSense-Logs läuft die OpenVPN Verbindung konstant. Sprich, auch bei maximal ausgelastetem VPN-Tunnel bleibt die Verbindung bestehen. Es ist nur jeweils um 04.30 Uhr eine Verbindungsunterbrechung in den Logs aufzufinden, die aber bedingt ist durch die Zwangstrennung und dem Neueinholen der IP-Adresse.
Hallo,
- Was passiert zur gleichen zeit noch über die OpenVPN Verbindung?
Pufferüberlaufs und irgend wo in der Kette geht der Speicher (RAM) zur Neige!? Jeder OpenVPN Tunnel belegt einen CPU
Kern sei es nun ein virtueller oder ein echter Kern und sicherlich läuft dann dort auch entweder der Speicher voll oder aber
es kommt zu einem Stocken des Datentransfers.
Gruß
Dobby
An einem Computer am Nebenstandort, werden 100 Dateien per Windows Explorer kopiert und im Netzlaufwerk des
Hauptstandortes eingefügt (Copy, Paste).
- MTU überall gleich bzw. angepasst?Hauptstandortes eingefügt (Copy, Paste).
- Was passiert zur gleichen zeit noch über die OpenVPN Verbindung?
Es passiert dann folgendes: Entweder bricht der Upload dann nach kurzer Zeit mit der Meldung "unerwarteter Netzwerkfehler"
ab, oder, er läuft durch und kopiert dabei einige Dateien nur zur Hälfte.
Und wenn man nur 20 Dateien kopiert ist das dann auch noch genau so? Wenn nciht ist das wohl eher ein Problem einesab, oder, er läuft durch und kopiert dabei einige Dateien nur zur Hälfte.
Pufferüberlaufs und irgend wo in der Kette geht der Speicher (RAM) zur Neige!? Jeder OpenVPN Tunnel belegt einen CPU
Kern sei es nun ein virtueller oder ein echter Kern und sicherlich läuft dann dort auch entweder der Speicher voll oder aber
es kommt zu einem Stocken des Datentransfers.
Das macht sich bemerkbar in PDFs, die nicht mehr geöffnet werden können oder JPEGs, die übersäht sind mit Artefakten.
Interessant ist, dass aus Sicht des Windows Explorers in diesem Fall der Kopiervorgang ganz normal abgeschlossen wird
(der Balken läuft durch), die Dateien dahinter nach dem Kopiervorgang aber so durchlöchert sind wie ein Schweizer Käse ;)
Dann gab es Probleme bei dem Abspeichern.Interessant ist, dass aus Sicht des Windows Explorers in diesem Fall der Kopiervorgang ganz normal abgeschlossen wird
(der Balken läuft durch), die Dateien dahinter nach dem Kopiervorgang aber so durchlöchert sind wie ein Schweizer Käse ;)
Ich muss deshalb momentan spezielle Programme für Dateitransfers verwenden, die mit Prüfsummen die Pakete geordnet
wieder "zusammenbauen".
FTP wäre hier nicht schlecht.wieder "zusammenbauen".
Die OpenVPN-Verbindung selbst wird via UDP realisiert - aber das sollte an sich ja ausreichend sein?
Nur via UDP? Nicht auch über TCP? Also "ein großes" Layer2 Netzwerk? Ich würde es einmal mit TAP versuchen wollen.Ist wirklich der geringe Upload von Nebenstandort hier das entscheidene Problem?
TUN oder TAP was wird dort verwendet?Gruß
Dobby
Die OpenVPN-Verbindung selbst wird via UDP realisiert
Ich denke hier wird der Fehler sein. Der Windows Kopiervorgang kümmert sich nicht um Paketverluste, das regelt ja das TCP. Die VPN kümmert sich aber auch nicht darum, weil UDP. Soll heißen, wird die kleine Leitung ausgelastet und es kommt zu Übertragungsfehlern irgendwo auf der Strecke, bleibt das doch unentdeckt. Würde erklären wieso die Daten zerstückelt ankommen, oder?
Durchaus.
Ein Dateikopiervorgang fordert soviel Bandbreite an, wie möglich.
Wenn da Schwankungen auftreten, rummst es.
Probiere mal mit Testdateien.
Viele kleine im ersten Durchlauf.
Dann eine ordentlich große.
Schau mal, wo der Schaden größer sein kann.
Für jeden Kopiervorgang wird die Session neu angeschoben. Beim Kopieren kleinerer Dateien hast Du also weniger Bandbreitenverbrauch,
als beim Kopieren einer wirklich großen.
Ein Dateikopiervorgang fordert soviel Bandbreite an, wie möglich.
Wenn da Schwankungen auftreten, rummst es.
Probiere mal mit Testdateien.
Viele kleine im ersten Durchlauf.
Dann eine ordentlich große.
Schau mal, wo der Schaden größer sein kann.
Für jeden Kopiervorgang wird die Session neu angeschoben. Beim Kopieren kleinerer Dateien hast Du also weniger Bandbreitenverbrauch,
als beim Kopieren einer wirklich großen.
pfSense mit jeweils davor geschaltetem Modem für den Internetzugang
Wirklich ein reines NUR Modem oder eine Router Kaskade ?Was du beschreibst ist ein technisches Wunder !
So gut wie ALLE Datei Transfer protokolle nutzen TCP als Transportprotokoll. TCP hat ein Handshaking und eine Absicherung mit Prüfsumme was absolut sicherstellt das die Daten fehlerfrei am Ziel ankommen.
Es ist unmöglich das Daten manipuliert ankommen sofern man TCP als Transport benutzt.
Entweder bricht der Transfer ab oder geht sehr langsam. Was du da beschreibst ist wenigstens mit TCP basiertem Transport technisch vollkommen unmöglich.
Wen UDP oder anderes benutzt werden sieht das anders aus.
Wichtig ist dann die MTU Einstellung des OVPN Tunnels:
https://www.unitymediaforum.de/viewtopic.php?t=23755
usw.
Hi Leute,
danke für eure Antworten.
MTU ist überall gleich und beträgt 1492. Ansonsten passiert zu diesem Zeitpunkt nichts über die OpenVPN Verbindung. Wir befinden uns in einem reinen Testszenario für Dateitransfers (denn die sollten sicher laufen! Es stecken ZFS-Dateisysteme dahinter!)
Der Fehler tritt auch dann auf, wenn wir z.B. eine einzige, große Datei kopieren. Die ersten paar MBytes funktionieren erfolgreich, aber schon nach kurzer Zeit bricht der Dateitransfer ab. In seltenen Fällen funktioniert der Dateitransfer auch über einen längeren Zeitraum. Große Dateien über 25-50 MByte sind aber fast unmöglich "sicher" an ihr Ziel zu bringen.
10.1.x.y = Standort 1
10.2.x.y = Standort 2
10.2.x.y = Standort 3
usw...
Hmmmm... Ich finde das einen guten Einwand... Deswegen habe ich etwas gegooglet...
Aber
Ein Kopiervorgang basiert doch auf TCP. Es wäre ja grob fahrlässig von Microsoft, wenn deren Kopiervorgang von einem lokalen Laufwerk auf ein Netzlaufwerk auf einem UDP-Protokoll basiert. Damit könnte theoretisch ja *jeder* Dateikopiervorgang zum Scheitern verurteilt sein. Ich hab im Internet etwas recherchiert und festgestellt, dass der Kopiervorgang verschiedene Ports nutzt. Unter anderem aber auch tatsächlich UDP. Siehe z.B. hier: https://superuser.com/questions/764623/what-port-or-ports-are-used-for-f ...
Dennoch vermute ich, dass der eigentlich Kopiervorgang via TCP abgewickelt wird. Das stimmt dann auch in etwa mit dem überein, was aqui in seinem Kommentar geschrieben hat:
Deswegen hier die Frage: Ein Microsoft Windows Kopiervorgang nutzt doch TCP für den eigentlichen Dateitransfer, oder nicht?
Interessant ist folgendes: Wenn ich spezielle Programme, wie z.B. richcopy verwende, dann funktioniert der Dateitransfer problemlos. Es werden dann sogar oft mehrere Dateien parallel übertragen. Das Problem beginnt, sobald ich das (anwenderfreundliche) Copy&Paste des Windows Explorers nutze.
Die Punkte, die du hier erwähnst, erinnern mich an meine ersten Fritzboxen... Mir ist da ebenfalls dieser Punkt aufgefallen, den du erwähnst: Bei großen Transfers über die VPN-Verbindung, wird diese instabil und bricht teilweise zusammen. Ich habe damals gelernt, dass das an diesem sehr unsymmetrischen Bandbreitenverhältnis lag (viel stärkerer Download, als Upload).
Dennoch sollte jetzt das Problem lösbar sein. Hat der Windows Kopiervorgang in sich eventuell Probleme, wenn ein Dateitransfer nur sehr sehr langsam vonstatten geht? Wie gesagt stehen im Upload nur ca. 800 Kbit/s zur Verfügung. Das ist dort derzeit nicht viel... leider...
Danke für euren Input! Viele Grüße,
Chris
danke für eure Antworten.
- MTU überall gleich bzw. angepasst?
- Was passiert zur gleichen zeit noch über die OpenVPN Verbindung?
- Was passiert zur gleichen zeit noch über die OpenVPN Verbindung?
MTU ist überall gleich und beträgt 1492. Ansonsten passiert zu diesem Zeitpunkt nichts über die OpenVPN Verbindung. Wir befinden uns in einem reinen Testszenario für Dateitransfers (denn die sollten sicher laufen! Es stecken ZFS-Dateisysteme dahinter!)
Und wenn man nur 20 Dateien kopiert ist das dann auch noch genau so? Wenn nciht ist das wohl eher ein Problem eines
Pufferüberlaufs und irgend wo in der Kette geht der Speicher (RAM) zur Neige!? Jeder OpenVPN Tunnel belegt einen CPU
Kern sei es nun ein virtueller oder ein echter Kern und sicherlich läuft dann dort auch entweder der Speicher voll oder aber
es kommt zu einem Stocken des Datentransfers.
Pufferüberlaufs und irgend wo in der Kette geht der Speicher (RAM) zur Neige!? Jeder OpenVPN Tunnel belegt einen CPU
Kern sei es nun ein virtueller oder ein echter Kern und sicherlich läuft dann dort auch entweder der Speicher voll oder aber
es kommt zu einem Stocken des Datentransfers.
Der Fehler tritt auch dann auf, wenn wir z.B. eine einzige, große Datei kopieren. Die ersten paar MBytes funktionieren erfolgreich, aber schon nach kurzer Zeit bricht der Dateitransfer ab. In seltenen Fällen funktioniert der Dateitransfer auch über einen längeren Zeitraum. Große Dateien über 25-50 MByte sind aber fast unmöglich "sicher" an ihr Ziel zu bringen.
Nur via UDP? Nicht auch über TCP? Also "ein großes" Layer2 Netzwerk? Ich würde es einmal mit TAP versuchen wollen.
Die VPN-Verbindungen zwischen den Standorten werden via TUN und UDP realisiert. Die IP-Adressen entsprechen dem folgenden Schema:10.1.x.y = Standort 1
10.2.x.y = Standort 2
10.2.x.y = Standort 3
usw...
Ich denke hier wird der Fehler sein. Der Windows Kopiervorgang kümmert sich nicht um Paketverluste, das regelt ja das TCP. Die VPN kümmert
sich aber auch nicht darum, weil UDP. Soll heißen, wird die kleine Leitung ausgelastet und es kommt zu Übertragungsfehlern irgendwo auf der
Strecke, bleibt das doch unentdeckt. Würde erklären wieso die Daten zerstückelt ankommen, oder?
sich aber auch nicht darum, weil UDP. Soll heißen, wird die kleine Leitung ausgelastet und es kommt zu Übertragungsfehlern irgendwo auf der
Strecke, bleibt das doch unentdeckt. Würde erklären wieso die Daten zerstückelt ankommen, oder?
Hmmmm... Ich finde das einen guten Einwand... Deswegen habe ich etwas gegooglet...
Aber
Ein Kopiervorgang basiert doch auf TCP. Es wäre ja grob fahrlässig von Microsoft, wenn deren Kopiervorgang von einem lokalen Laufwerk auf ein Netzlaufwerk auf einem UDP-Protokoll basiert. Damit könnte theoretisch ja *jeder* Dateikopiervorgang zum Scheitern verurteilt sein. Ich hab im Internet etwas recherchiert und festgestellt, dass der Kopiervorgang verschiedene Ports nutzt. Unter anderem aber auch tatsächlich UDP. Siehe z.B. hier: https://superuser.com/questions/764623/what-port-or-ports-are-used-for-f ...
Dennoch vermute ich, dass der eigentlich Kopiervorgang via TCP abgewickelt wird. Das stimmt dann auch in etwa mit dem überein, was aqui in seinem Kommentar geschrieben hat:
Wirklich ein reines NUR Modem oder eine Router Kaskade ?
In beiden Fällen ein reines Modem; Im Fall von Nebenstandort: Ein ADSL2+ Modem; Im Fall von Hauptstandort: Ein Glasfaser-Modem;Was du beschreibst ist ein technisches Wunder !
So kommts mir eben auch vor... Ich kann mir das nicht erklären! Selbst wenn meine VPN-Verbindung das UDP-Protokoll nutzt, dann ist das UDP-Paket ja nur der "Container", der die Netzwerkpakete, die via VPN versendet werden, umgibt. Sollte aber ein UDP-Container verloren gehen, der in sich ein TCP-Paket beinhaltet, dann würde dieses Paket ja sowieso erneut gesendet werden - solange, bis es ankommt!So gut wie ALLE Datei Transfer protokolle nutzen TCP als Transportprotokoll. TCP hat ein Handshaking und eine Absicherung mit Prüfsumme was > absolut sicherstellt das die Daten fehlerfrei am Ziel ankommen.
Es ist unmöglich das Daten manipuliert ankommen sofern man TCP als Transport benutzt.
Entweder bricht der Transfer ab oder geht sehr langsam. Was du da beschreibst ist wenigstens mit TCP basiertem Transport technisch
vollkommen unmöglich.
Wen UDP oder anderes benutzt werden sieht das anders aus.
Wichtig ist dann die MTU Einstellung des OVPN Tunnels:
https://www.unitymediaforum.de/viewtopic.php?t=23755
usw.
Es ist unmöglich das Daten manipuliert ankommen sofern man TCP als Transport benutzt.
Entweder bricht der Transfer ab oder geht sehr langsam. Was du da beschreibst ist wenigstens mit TCP basiertem Transport technisch
vollkommen unmöglich.
Wen UDP oder anderes benutzt werden sieht das anders aus.
Wichtig ist dann die MTU Einstellung des OVPN Tunnels:
https://www.unitymediaforum.de/viewtopic.php?t=23755
usw.
Deswegen hier die Frage: Ein Microsoft Windows Kopiervorgang nutzt doch TCP für den eigentlichen Dateitransfer, oder nicht?
Interessant ist folgendes: Wenn ich spezielle Programme, wie z.B. richcopy verwende, dann funktioniert der Dateitransfer problemlos. Es werden dann sogar oft mehrere Dateien parallel übertragen. Das Problem beginnt, sobald ich das (anwenderfreundliche) Copy&Paste des Windows Explorers nutze.
Ein Dateikopiervorgang fordert soviel Bandbreite an, wie möglich.
Wenn da Schwankungen auftreten, rummst es.
Probiere mal mit Testdateien.
Viele kleine im ersten Durchlauf.
Dann eine ordentlich große.
Schau mal, wo der Schaden größer sein kann.
Für jeden Kopiervorgang wird die Session neu angeschoben. Beim Kopieren kleinerer Dateien hast Du also weniger Bandbreitenverbrauch,
als beim Kopieren einer wirklich großen.
Wenn da Schwankungen auftreten, rummst es.
Probiere mal mit Testdateien.
Viele kleine im ersten Durchlauf.
Dann eine ordentlich große.
Schau mal, wo der Schaden größer sein kann.
Für jeden Kopiervorgang wird die Session neu angeschoben. Beim Kopieren kleinerer Dateien hast Du also weniger Bandbreitenverbrauch,
als beim Kopieren einer wirklich großen.
Die Punkte, die du hier erwähnst, erinnern mich an meine ersten Fritzboxen... Mir ist da ebenfalls dieser Punkt aufgefallen, den du erwähnst: Bei großen Transfers über die VPN-Verbindung, wird diese instabil und bricht teilweise zusammen. Ich habe damals gelernt, dass das an diesem sehr unsymmetrischen Bandbreitenverhältnis lag (viel stärkerer Download, als Upload).
Dennoch sollte jetzt das Problem lösbar sein. Hat der Windows Kopiervorgang in sich eventuell Probleme, wenn ein Dateitransfer nur sehr sehr langsam vonstatten geht? Wie gesagt stehen im Upload nur ca. 800 Kbit/s zur Verfügung. Das ist dort derzeit nicht viel... leider...
Danke für euren Input! Viele Grüße,
Chris
Auch interessant.. Ich hab gerade ein paar Ping-Versuche vom Hauptstandort unternommen...
Das mximale Größe, die ich erreiche, sind folgende:
ping -f -l 1464 t-online.de -> Das ist ein Ping ins Internet!
ping -f -l 1472 10.1.100.1 -> Das ist ein Ping von Hauptstandort zu Nebenstandort
Wie kann das denn sein, dass das VPN-Tunnel selbst größere Pakete duldet, als die Pakete, die ins Internet gesendet werden? :D
Danke euch vielmals!
Viele Grüße,
Chris
Das mximale Größe, die ich erreiche, sind folgende:
ping -f -l 1464 t-online.de -> Das ist ein Ping ins Internet!
ping -f -l 1472 10.1.100.1 -> Das ist ein Ping von Hauptstandort zu Nebenstandort
Wie kann das denn sein, dass das VPN-Tunnel selbst größere Pakete duldet, als die Pakete, die ins Internet gesendet werden? :D
Danke euch vielmals!
Viele Grüße,
Chris
dass das VPN-Tunnel selbst größere Pakete duldet, als die Pakete, die ins Internet gesendet werden?
Googeln nach MTU Path Discovery sollte dir diese Frage beantworten...Ich habe damals gelernt, dass das an diesem sehr unsymmetrischen Bandbreitenverhältnis lag
Das ist natürlich wie immer Unsinn !Es liegt in erster Linie daran das eine FritzBox ein billiges Consumer Massenprodukt ist mit einer schwachbrüstigen SoC CPU. Die ist für solche Sachen wie Wirespeed VPN Verschlüsselung nicht gemacht. Das VPN ist dafür ausgelegt das man damit mal hie und da Oma Gretes PC fernwarten kann.
Leider fehlt dir hier vermutlich der Technik Horizont zu professionellerer VPN Router Hardware denn sonst würdest du solchen Unsinn nicht in einem Administrator Forum verbreiten.
Allein ein TCP Protokoll was oben drüber liegt würde durch seinen Sliding Windows Mechanismus sich an asymetrische Bandbreiten anpassen so das es niemals zu einem Absturz kommt solange der VPN Tunnel steht. Abgesehen davon würde man auf dem Router zusätzlich ein Rate Limiting Profile auf den VPN Traffic bzw. seinem Interface auf die maximale Uplink Speed einstellen.
All sowas ist bei billigen FBs gar nicht möglich. Muss es ja auch nicht, da es ein Consumer Device für den Massenmarkt ist. Nichts aber für deine Anwendung.
Sollte man als verantwortungsvoller Netzwerker aber auch wissen. Oder warum meinst du gibt es Geräte die das nachweislich besser können ?!
Hi,
daher benutze ich ja keine Fritzbox. Vielleicht hast du ja das Geld, dir teure Hardware zu kaufen. Bei mir reichts nur für pfSense. Ich bin trotzdem damit zufrieden und mir machts Spaß damit zu arbeiten! Klar ist da kein teures Cisco- oder Juniper-Label drauf - aber für meine Vorhaben reichen mir die Funktionen, die da drin angeboten werden...
Und: Ein Grund, weswegen ich keine FBs verwende, ist ja genau das VPN-Dilemma.
Zurück aber zum Wesentlichen:
Beim Auswerten der Übertragungsgeschwindigkeiten im VPN-Tunnel ist mir aufgefallen, dass sich der Geschwindigkeits-Graph oft wie eine Säge verhält. Es gibt kurze Momente, in denen gar nichts transferiert wird. Ich habe daraufhin via "mssfix 1424;" versucht die Größe innerhalb des OpenVPN-Tunnels zu limitieren (wie auch von dir vorgeschlagen @ aqui, daher danke an dieser Stelle!). Ich werde Tests machen, wie sich diese Änderung bewirkt und werde hier dann noch mal kurz Rückmeldung geben.
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-ope ...
Liebe Grüße,
Chris
daher benutze ich ja keine Fritzbox. Vielleicht hast du ja das Geld, dir teure Hardware zu kaufen. Bei mir reichts nur für pfSense. Ich bin trotzdem damit zufrieden und mir machts Spaß damit zu arbeiten! Klar ist da kein teures Cisco- oder Juniper-Label drauf - aber für meine Vorhaben reichen mir die Funktionen, die da drin angeboten werden...
Und: Ein Grund, weswegen ich keine FBs verwende, ist ja genau das VPN-Dilemma.
Zurück aber zum Wesentlichen:
Beim Auswerten der Übertragungsgeschwindigkeiten im VPN-Tunnel ist mir aufgefallen, dass sich der Geschwindigkeits-Graph oft wie eine Säge verhält. Es gibt kurze Momente, in denen gar nichts transferiert wird. Ich habe daraufhin via "mssfix 1424;" versucht die Größe innerhalb des OpenVPN-Tunnels zu limitieren (wie auch von dir vorgeschlagen @ aqui, daher danke an dieser Stelle!). Ich werde Tests machen, wie sich diese Änderung bewirkt und werde hier dann noch mal kurz Rückmeldung geben.
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-ope ...
Leider fehlt dir hier vermutlich der Technik Horizont zu professionellerer VPN Router Hardware denn sonst würdest du solchen Unsinn nicht in
einem Administrator Forum verbreiten
Korrekt, und mir fehlt noch bei sooo vieeel anderen Sachen der Horizont! Daher bin ich ja dankbar, wenn durch Leute wie euch dieser Horizont erweitert wird. Wenn Freizeit- und Hobby-Admins hier nicht posten dürfen, gib bitte noch mal Bescheid... weil dann wusste ich auch das nicht, sorry!..einem Administrator Forum verbreiten
Liebe Grüße,
Chris
daher benutze ich ja keine Fritzbox.
Die hat aber wenigstens IPSec mit an Board und biete auch für den mobilen Zugriff mehrere Apss an, also ist dasschon ganz nett für einen Hersteller und Anbieter aus und für den Heimbereich! Des weiteren ist AVM gar nicht
soooo teuer! Denn eine aktuelle AVM FB gibt es schon für 99 € bis 199 € und gebraucht auch oft noch günstiger
zu haben.
Vielleicht hast du ja das Geld, dir teure Hardware zu kaufen. Bei mir reichts nur für pfSense.
Also eine APU2C4, mit mSATA und WLAN Karte plus Antennen kann auch locker auf mehrerehundert Euro bis hin zu mehreren tausend kommen, so soll das nicht sein und verstanden werden.
Ich bin trotzdem damit zufrieden und mir machts Spaß damit zu arbeiten! Klar ist da kein teures
Cisco- oder Juniper-Label drauf - aber für meine Vorhaben reichen mir die Funktionen, die da drin
angeboten werden...
Cisco- oder Juniper-Label drauf - aber für meine Vorhaben reichen mir die Funktionen, die da drin
angeboten werden...
Und: Ein Grund, weswegen ich keine FBs verwende, ist ja genau das VPN-Dilemma.
Das ergibt sich bei jedem aus dem gesteigerten Bedarf und nicht nach dem Hersteller.Gruß
Dobby
ist ja genau das VPN-Dilemma.
Hätte man mit einer pfSense Firewall ja auch nicht, denn die supportet so gut wie alles was es an VPN Protkollen gibt !
Versuche doch bitte einmal hier an diesen zwei Einstellungen Änderungen vorzunehmen:
Beides ist unter Advanced > Configuration zu finden
Sollte eine Beschleunigung erwirken
Damit kann man eventuell dann diese Zerstückelung der Dateien verhindern bzw. unterbinden,
je nach RAM Größe kann man eben auch mehr auswählen und benutzen.
Wenn auf beiden Seiten die Kompression angeschaltet ist ist der Nutzen Größer.
Intel RAND, kann nur nützen wenn die Hardware es unterstützt
Unbedingt ein Update auf die Version 2.4.0 machen denn, denn da wird dann einiges geändert und dieses mal
auch beschleunigt in Sachen OpenVPN, je nach Hardware halt! Trotz alledem lohnen sich halt auch Änderungen.
- Es wird LZO4 benutzt sollte also immer auf beiden Seiten angeschaltet werden wenn möglich
- AES-NI ist ab Werk angeschaltet und CryptoDev soll nicht noch zusätzlich aktiviert werden!
Gruß
Dobby
Beides ist unter Advanced > Configuration zu finden
UDP Fast I/O -> CheckedSend/Receive Buffer -> 2.00 MiBje nach RAM Größe kann man eben auch mehr auswählen und benutzen.
- LZO Kompression aktivieren
- Intel RDRAND aktivieren)Intel RAND, kann nur nützen wenn die Hardware es unterstützt
Unbedingt ein Update auf die Version 2.4.0 machen denn, denn da wird dann einiges geändert und dieses mal
auch beschleunigt in Sachen OpenVPN, je nach Hardware halt! Trotz alledem lohnen sich halt auch Änderungen.
- Es wird LZO4 benutzt sollte also immer auf beiden Seiten angeschaltet werden wenn möglich
- AES-NI ist ab Werk angeschaltet und CryptoDev soll nicht noch zusätzlich aktiviert werden!
Gruß
Dobby
Hi,
vielen Dank für eure Antworten! Das Problem ist mittlerweile (temporär) gelöst. Es liegen unzählige Teststunden und Konfigurationsänderungen hinter uns. Für den Fall, dass jemand mal das gleiche Problem erleben sollte, fasse ich hier alles Wesentliche von unserem Lösungansatz zusammen:
Zu aller Erst: Das Problem lag nicht am VPN-Tunnel selbst. Stattdessen liegt es an Windows 8.1 / 10. Genauer gesagt an SMBv3. Das erklärt auch, warum Transfers mit beispielsweise FTP-Programmen oder Richcopy erfolgreich waren, aber native Copy&Paste Vorgänge im Windows Explorer korrupt waren
Ich bin mit dem Problem nicht der Einzige. Hier ein Beispiel:
https://social.technet.microsoft.com/Forums/windows/en-US/1208ca4a-47aa- ...
In diesem Fall werden exakt auch die Probleme, die bei mir eingetreten sind, beschrieben: Die Dateitransfers zeigen dieses Valley-Peak-Symptom und sie brechen bei einer genau exakten MByte Zahl ab. In meinem Fall war das jeweils 4,00 MByte, 5,00 MByte oder sehr selten 9,00 MByte.
Es gibt Workarounds seitens Microsoft. Es sind aber wirklich nur Workarounds und keine Ideallösungen: https://support.microsoft.com/de-de/help/2696547/how-to-detect-enable-an ...
Es gilt SMBv3 zu deaktivieren und auf SMBv1 (bzw. SMBv2, sofern möglich) umzusteigen. Microsoft selbst schreibt, dass das nur als temporäre Lösung verwendet werden soll.
Diejenigen, die von diesem Problem betroffen sind, werden aber schnell merken, wie diese Umstellung einiges ändert: Der Traffic-Graph bei den Dateitransfers läuft deutlich flüssiger, wird deutlich häufiger aktualisiert und zeigt kein Valley-Peak-Symptom mehr.
Bezüglich pfSense und OpenVPN selbst haben wir einige Tests unternommen. Wir konnten aber bei keinem Test feststellen, dass das Einstellen von mtu-fragment, mssfix, etcpp. irgendetwas in diesem konkreten Fall gebracht oder geändert hätte. Ich hab mir die Logs von OpenVPN angeschaut und wenn ich es richtig interpretiere, wird die optimale MTU-Size automatisch zwischen den Standorten ausgehandelt. Solange für den WAN-Adapter eine korrekte MTU-Größe angegeben ist, sollten also im OpenVPN Tunnel hier keinerlei Probleme auftreten.
Wie weiter oben vermutet, ist außerdem ein Zusammenhang zwischen dem SMBv3-Fehler mit der Geschwindigkeit der VPN-Tunnels erkennbar. Zu Standorten, die von einer hohen DSL-Geschwindigkeit profitieren, konnte der Fehler mit SMBv3 bis dato nicht reproduziert werden. Betroffen hingegen waren nur Standorte, die eine langsame Geschwindigkeit haben. In unserem Fall waren Standorte mit weniger als 1 Mbit/s von dem SMBv3 Problem betroffen. An dieser Stelle sei anzumerken: Eventuell liese sich das SMBv3 Problem lösen, wenn man eine Geschwindigkeitslimitierung auf den SMBv3-Transfer setzt (routerseitig). Getestet haben wir das aber nicht! Standorte mit 10 Mbit/s konnten uneingeschränkt Dateien transferieren.
Viele Grüße,
Scampicfx
vielen Dank für eure Antworten! Das Problem ist mittlerweile (temporär) gelöst. Es liegen unzählige Teststunden und Konfigurationsänderungen hinter uns. Für den Fall, dass jemand mal das gleiche Problem erleben sollte, fasse ich hier alles Wesentliche von unserem Lösungansatz zusammen:
Zu aller Erst: Das Problem lag nicht am VPN-Tunnel selbst. Stattdessen liegt es an Windows 8.1 / 10. Genauer gesagt an SMBv3. Das erklärt auch, warum Transfers mit beispielsweise FTP-Programmen oder Richcopy erfolgreich waren, aber native Copy&Paste Vorgänge im Windows Explorer korrupt waren
Ich bin mit dem Problem nicht der Einzige. Hier ein Beispiel:
https://social.technet.microsoft.com/Forums/windows/en-US/1208ca4a-47aa- ...
In diesem Fall werden exakt auch die Probleme, die bei mir eingetreten sind, beschrieben: Die Dateitransfers zeigen dieses Valley-Peak-Symptom und sie brechen bei einer genau exakten MByte Zahl ab. In meinem Fall war das jeweils 4,00 MByte, 5,00 MByte oder sehr selten 9,00 MByte.
Es gibt Workarounds seitens Microsoft. Es sind aber wirklich nur Workarounds und keine Ideallösungen: https://support.microsoft.com/de-de/help/2696547/how-to-detect-enable-an ...
Es gilt SMBv3 zu deaktivieren und auf SMBv1 (bzw. SMBv2, sofern möglich) umzusteigen. Microsoft selbst schreibt, dass das nur als temporäre Lösung verwendet werden soll.
Diejenigen, die von diesem Problem betroffen sind, werden aber schnell merken, wie diese Umstellung einiges ändert: Der Traffic-Graph bei den Dateitransfers läuft deutlich flüssiger, wird deutlich häufiger aktualisiert und zeigt kein Valley-Peak-Symptom mehr.
Bezüglich pfSense und OpenVPN selbst haben wir einige Tests unternommen. Wir konnten aber bei keinem Test feststellen, dass das Einstellen von mtu-fragment, mssfix, etcpp. irgendetwas in diesem konkreten Fall gebracht oder geändert hätte. Ich hab mir die Logs von OpenVPN angeschaut und wenn ich es richtig interpretiere, wird die optimale MTU-Size automatisch zwischen den Standorten ausgehandelt. Solange für den WAN-Adapter eine korrekte MTU-Größe angegeben ist, sollten also im OpenVPN Tunnel hier keinerlei Probleme auftreten.
Wie weiter oben vermutet, ist außerdem ein Zusammenhang zwischen dem SMBv3-Fehler mit der Geschwindigkeit der VPN-Tunnels erkennbar. Zu Standorten, die von einer hohen DSL-Geschwindigkeit profitieren, konnte der Fehler mit SMBv3 bis dato nicht reproduziert werden. Betroffen hingegen waren nur Standorte, die eine langsame Geschwindigkeit haben. In unserem Fall waren Standorte mit weniger als 1 Mbit/s von dem SMBv3 Problem betroffen. An dieser Stelle sei anzumerken: Eventuell liese sich das SMBv3 Problem lösen, wenn man eine Geschwindigkeitslimitierung auf den SMBv3-Transfer setzt (routerseitig). Getestet haben wir das aber nicht! Standorte mit 10 Mbit/s konnten uneingeschränkt Dateien transferieren.
Viele Grüße,
Scampicfx
wird die optimale MTU-Size automatisch zwischen den Standorten ausgehandelt.
Jein !Nur in LAN basierten Infrastrukturen, niemals aber bei PPP Overhead wie es z.B. bei PPPoE in xDSL Anschlüssen der Fall ist. Da ist manuelles Nachtunen von MTU und LAN MSS zwingend erforderlich.
