Beiträge von eripek

Zitat von julian-w

Ich glaube der Threadstarter hat die Snapshot-Funktion als "tägliches Backup" angesehen, was so ja nicht ganz vorgesehen ist.

Ich nutze die Snapshot Funktion nur wenn ich grundlegend das System "umbaue" (z.B. OS-Upgrade) und ich im Fehlerfall schnell auf den alten Stand zurück will. Aber auch da läuft vorher ein Backup auf extern. Ansonsten hat die Funktion keine große Bedeutung für mich und ist einfach nur ein nettes Feature wenn man etwas experimentieren will.

Ich mache das auch so, wenn ich gröber umbaue.

Für sonstige Aufgaben sind rsync, rsnapshot oder duplicity verbunden mit automysqlbackup eher das Mittel der Wahl. Oder gibt's schon wieder bessere Lösungen (Amanda kenn ich noch, ein Freund schwört auf Veeam.)?

Ich denke, das bezog sich auf Posting nur #3 wo Hecke29 Felix zitiert.

Ich hab da einmal eine dämliche Frage... rsync von einem externen Rechner aus ist keine Option? Somit ein inkrementelles Backup das von einem externen Host aus gesteuert wird? Einzig die Datenbankdumps sollte man vorher erstellen, was auch Platz brauchen wird. Die DBs könnte man aber auch von Aussen dumpen. Oder man sichert gleich auf einen nfs-mount oder einen sshfs-mount oder curlftpmount weg (letzteres wäre für on-the-fly schreiben zu langsam).

Was lokal die Platte nicht belegt, muss ich nachher auch nicht trimmen.

Zitat von H6G

MTU Probleme im Netcup-internen Netz? Halte ich für sehr unwahrscheinlich.

Im ICMPv6 sind einige Message-Types freigeschaltet. Vorher gab es in die Richtung ja eher keine Probleme.

Unwahrscheinlich ja, aber vollkommen unmöglich wird es wohl nirgendwo sein. Die Troubles mit pMTUd treten aber meiner Erfahrung nach eher auf den Internetleitungen wo DSL, UMTS und LTE und Co im Spiel sind (PPP*+VLAN einerseits, Tunneling beim Carrier andererseits, einhergehend mit Fragmentierung auf dieser Ebene.). Man sieht beizeiten so einiges...

Wie schaut es mit der Erreichbarkeit über die linklokalen Adressen aus? Wenn dabei kein Paketverlust auftritt, wäre das die Differentialdiagnose, die bestätigt, dass intern soweit einmal Einiges richtig läuft, wenn die Host in derselben Broad- respektive der richtigen MC-Domain liegen.

BTW - eventuell ähnliche Meldung vor zwei Stunden https://forum.netcup.de/netcup…routing-kaputt/#post93151

Zitat von A:H

[...]

Ich verzweifle seit einigen Tagen/Wochen an Verbindungsabbrüchen bei meinen UniFis.

Ich habe hier im Haus 3 Stück davon, relativ nah bei einander.

Im 2,4GHz Netz hab ich in einem Raum das Problem, dass andauernd eine ‚Passwort fehlerhaft‘ Meldung aufspringt und ich die Verbindung verliere.

Überlappende Kanäle gibts so gut wie garkeine. Weder von mir selbst, noch von Nachbarn. Ich nutze auf dem 2,4GHz Band die Kanäle und 1,6,11.

Zudem ist sehr auffällig, dass ich sehr viele verworfene und wiederholte Pakete habe, was sich auch auf der Auslastung des Kanals wiederspiegelt.

Mein FireTV mit Kodi (connected auf meine Vu+) ruckelt auch bei HD-Streams pausenlos, obwohl das Signal mit gut 60-70db gut bis sehr gut ist.

Ich bin leider mit meinem Latein am Ende.

Achja, 5GHz funktioniert ohne Abbrüche, aber ebenfalls mit Ruckeln beim FireTV Stick..

lg.

Alles anzeigen

Mit Ubnt UniFy habe ich keine Erfahrung, kann also nur das Demo-System nützen: https://demo.ubnt.com/manage/site/default/dashboard

WLAN-Geräte „relativ nah beieinander“ sind an sich keine gute Idee, da im unmittelbaren Nahbereich Übersteuern im gesamten 2.4 Band möglich ist. Bei den alten WRT54G/GL, die noch 802.11b/n nützten hat das einmal jemand bei Funkfeuer Graz gemessen. Den Link finde ich nicht mehr. Das Phänomen wird aber auch mit QAM-Modulationen unter ac noch auftreten.

Überlappende Kanäle:

https://de.wikipedia.org/wiki/Wireless_Local_Area_Network empfiehlt für 802.11b 1,6,11, hingegen für 802.11g und 802.11n 1,5,9 und 13.

(bei b sind aufgrund DSSS 11 MHz Flanke von der Mittenfrequenz anzunehmen sohin 22 MHz Mindestabstand zu den Kanälen, während g mit OFDM „steilere“ und klar abgegrenze Flanken zeigen. Bei n mit 40MHz wird zeitweise nur die Verwendung von 3+ und 11- empfohlen, für ac weiß ich das nicht - bei 80MHz weiss das Gerät es am besten...). Ich tendiere mittlerweile dazu, auf automatische Kanalwahl zu stellen, da der Router so auf Störungen im Sendebereich schneller mit Kanalwechsel reagieren kann, als der Client den AP wechselt. Und Störungen können von der Mikrowelle über das Babyphon, die analoge VÜ bishin zu kaputten WLAN-Geräten reichen.

Gegen zahlreiche verworfene Frames hilft nur die Absicherung der Übertragung zumindest durch CTS-to-self oder RTS/CTS. Übermäßige Verwendung von RTS/CTS ist aber auch nachteilig - Stichwort: RTS-Flooding.

Das Ruckeln von Kodi am FireTV-Stick kann unterschiedliche Ursachen haben: Erstens die Wlan-Qualität, zweitens das Audio-Decoding (Audio Passthrough einstellen für IPTV Simple), drittens das Decoding und Buffering - weiss nicht mehr ... durchprobieren, viertens Empfangsstörungen der Sat-Anlage (wenn es denn SAT>IP wäre) auf den HD-Sendern.

Also zusammenfassend: Packet Aggregation aktivieren, RTS/CTS mit hoher Schwelle 2344 oder 2345 einstellen, Kanalwechsel automatisieren, APs beträchtlich weiter als drei Meter auseinanderstellen, Sendeleistung eher reduzieren als voll aufdrehen (Faustregel 2dB mehr als gerade noch gut geht). Tip: APs niemals auf Metallregale stellen.

Zitat von H6G

Nanü? Beide Endpunkte zeigen auch von meinem Internetanschluss einzelne Pakete mit hoher Antwortzeit.

Ein Neustart der Beiden hat es jetzt gerichtet - obwohl beide erst seit 30 Tagen laufen.

(die zwei anderen waren wohl statistische Ausreißer dazu...)

Kernel 4.14.20

Strange... was die ICMPs anbelangt... request, reply und message to big sollte man (in der jeweils sinnvollen Richtung) immer durchlassen - sonst gibt's früher oder später einmal MTU Probleme, was sich vor allem bei Verschlüsselung bemerkbar macht.

Ich könnte mir vorstellen, dass die fehlenden Antworten nicht zwangsläufig auf ein Problem hindeuten müssen. Mittlerweile sind Router beizeiten so intelligent unter Last nur einen Teil der RTTs zu beantworten. Sorgen würde es mir machen, wenn auch Paketverluste auftreten.

Siehst Du einen Unterschied, wenn Du reine ICMP-Traceroutes (traceroute -I) oder TCP-Traceroutes (traceroute -T) anstelle von Standardtraceroutes machst?

Du könntest auch einmal schauen, ob die beiden Hosts nicht ohnedies einander linklokal sehen. -> ping6 -c2 fe80::[EUI64 von ldap2] und vice versa. Wäre dies der Fall, müssen wir den Gateway erst gar nicht bemühen, sofern das zugelassen wird.

Zitat von H6G

Apt-Log von Mittwoch

Code

Start-Date: 2018-04-03  10:49:37
Commandline: apt-get upgrade
Requested-By: pzillmann (1000)
Upgrade: openssl:amd64 (1.1.0f-3+deb9u1, 1.1.0f-3+deb9u2), libsystemd0:amd64 (232-25+deb9u2, 232-25+deb9u3), libicu57:amd64 (57.1-6+deb9u1, 57.1-6+deb9u2), udev:amd64 (232-25+deb9u2, 232-25+deb9u3), libudev1:amd64 (232-25+deb9u2, 232-25+deb9u3), systemd-sysv:amd64 (232-25+deb9u2, 232-25+deb9u3), libpam-systemd:amd64 (232-25+deb9u2, 232-25+deb9u3), systemd:amd64 (232-25+deb9u2, 232-25+deb9u3), libssl1.1:amd64 (1.1.0f-3+deb9u1, 1.1.0f-3+deb9u2), libssl1.0.2:amd64 (1.0.2l-2+deb9u2, 1.0.2l-2+deb9u3), tzdata:amd64 (2018c-0+deb9u1, 2018d-0+deb9u1)
End-Date: 2018-04-03  10:50:30

Am Abend darauf fingen die Probleme an. Aktuell wieder ICMPv6 Probleme zu zwei Hosts.

Hat jemand gerade ähnliche Probleme? Ist kein Root-Server

Mach uns ein paar Traceroute6, bitte. UDP oder ICMP oder TCP, egal...

Zitat von perryflynn

Wobei Windows Server ja noch einfach ist. Son Windows 10 direkt ins Netz zu stellen ist schon ziemlich Dumm.

Sollte das dann nicht eigentlich OpenWindows heissen?!

Sei offen für Alles!

Zitat von Pappy

Vielen Dank für eure Mühe mir das ganze ein wenig zu erklären. Ich habe jetzt noch einmal alles neu aufgesetzt und auf den Netgear Router die Firmware DD-WRT geflasht. Hab versucht den Router damit direkt als OpenVPN Client zu konfigurieren, jedoch bekomme ich diesen nicht so eingestellt, dass er sich mit dem Server verbindet. Also läuft das ganze erstmal wieder über den Pi und der Festplattenzugriff funktioniert mit der neuen Firmware jetzt auch (wenn auch immernoch sehr langsam: OpenVPN App 800kbit/s in, OpenVPN Connect App 100kbyte/s in / 4kbyte/s out). Ich werde jetzt erst einmal auf die Fertigstellung des Breitbandausbaus bei mir warten und dann schauen ob sich was an der VPN Geschwindigkeit getan hat (50000 werden bei mir verfügbar sein), da sich bisher gefühlt keine Einstellung auf die Geschwindigkeit ausgewirkt hat.

https://www.dd-wrt.com/wiki/in…/OpenVPN#GUI:_Client_Mode

DD-WRT benütze ich schon ewig nicht mehr - zuletzt auf den WRT54G/GL

Kann OpenWRT mit Deinem Router umgehen? https://wiki.openwrt.org/toh/s…lt%5BBrand*%7E%5D=netgear

Zum PI: man muss wissen, dass bei all diesen Handy-SOC-Mini-Rechnern der Netzwerkanschluss über USB läuft. D.h. bei 100Mbit/s hast Du schon „Fullspeed“ bei Gigabit Ethernet beschränkt der SoC den Durchsatz auf zumeist 480 Mbit/s bei USB 2.0. Wenn Du eine lokale USB-Platte über das Netzwerk ansprichst teilen sich die die Bandbreite auch noch über den eingebauten Hub.

Dennoch ist der Flaschenhals bei Dir definitiv das „Breitband“ Deines Providers. Da kann etwas Tuning keine Wunder bewirken, aber zumindest die Verlässlichkeit und die Latenzen verbessern helfen.

Ad Warten auf das Ende vom Breitbandausbau: Kein Freifunk oder etwas in der Art in Deiner Stadt? https://freifunk.net/
Manchmal muss man die Dinge eben auch selbst in die Hand nehmen. Funk ist zwar immer noch volatil, und garantiert ist nichts, aber Du kannst ja immer noch auf das DSL als Backup zurückgreifen.

Zitat von alhazred

Zum Routing: Man kann euch einfach die Route auf dem Router setzen. bei FB ist das kein Problem. Dann braucht man keine statische Route per DHCP (oder manuell) setzen, sondern der Router schickt einfach alles zum VPN Einstiegspunkt weiter.

Aber nur dann, wenn der Default Router dieser Router ist. Ein Verwandter hatte so ein Providermodem, wo man dies nicht konnte, weil alles wichtige gesperrt war. Die Lösung mit den Hostrouten war damals der praktikabelste Zugang, da ich ihm einen alternativen Router gebaut habe, der aber nicht Defaultrouter war und wo ich keine NAT-Kaskaden wollte.

Zitat von StefanG

Macht das ganze einen Unterschied, wenn ich zu Innogy wechsel mit VDSL Vectoring 120/40 MBit? Ich bekomme mit meinem eigenen Router keine offentliche IPv4 zugewiesen. Ich muss ein Werksrouter nehmen, den ich nicht will. Ansonsten werde ich die Tage mal den Open VPN Server aufsetzten. Ich hatte mal kurz den c't Artikel umflogen, glaube Ausgabe 2. Sie gehen dort einen ganz anderen weg. Der Heimserver baut eine SSH Verbindung zum Server per RSA Key zum root User auf. Dort gibt es dann Regeln, welche Ports er dann weiterleitet zum Heimserver. Weiß net, finde VPN Verbindung irgendwie besser.

Mit deutschen DSL-Providern kenne ich mich leider nicht aus, aber soweit mir bekannt ist, sind solche Angebote meist „best effort“, die Bandbreiten also Maximalwerte. Da sollte man nachschauen was vertraglich das Minimum ist. Ich selbst habe mit UMTS-Sticks auf OpenWRT für eine VÜ begonnen. Das war schon ok, da die nur bei Alarm Bilder gesendet hat. Der Stream war eher nicht damit möglich. Mittlerweile hat mein Prepaidprovider das LTE auf maximal 100/50 Mbit aufgestockt, der Alternativprovider hat 50/10. Zufriedenstellend war es für mich schon mit 20/6 Mbit/s, wobei effektiv 10:10 drübergegangen sind. Es ist also vieles machbar.

Den Heise-Artikel habe ich nicht bei der Hand -ich kaufe das nur sporadisch, wenn das Inhaltsverzeichnis mich anspringt- ich habe aber kürzlich für eine Freifunk-artige Organisation die Wartung des Tunnelservers übernommen und da fahren wir mit ein paar handvoll Tunneln im peer2peer Mode über das besagte Bridge-Setup mit tap+ebtables+olsr, wobei die peers über unterschiedliche Anbindungen hereinkommen.

ssh kann Portforwarding:

ssh -L 26:192.168.1.1:25 meinrechner.meinedoma.in

würde etwa Port 25 von 192.168.1.1, der hinter meinrechner.meinedoma.in liegt, auf dem lokalen Rechner, der ssh ausführt, unter port 26 verfügbar machen. Das ganze geht auch umgekehrt, meines Wisses mit "-g". Man kann übrigens mehrere "-L ..."-Optionen zusammen verwenden.

Hier gibt es eine Anleitung für ssh reverse tunnel - vielleicht auch interessant:

https://blog.devolutions.net/2…verse-ssh-port-forwarding

sshfs hingegen würde gleich ein remote-Dateisystem als lokalen Mountpoint einbinden.

Es gäbe auch curlftpfs - damit würde man einen FTP-Account lokal einbinden.

Möglichkeiten gibt es viele - man muss nur den Wunsch genau artikulieren

Was auch lustig ist, ist socat:

http://www.dest-unreach.org/socat/doc/README - verwende es entweder wie netcat oder als VPN-Lösung oder als Modemserver oder als Terminalprogramm. Ich liebe es, aber es ist auch anspruchsvoll.

Zitat von alhazred

Gut geschrieben. Ein paar Anmerkungen:

MTU: Wenn man einen DSLite Zugang hat (UnityMedia z.B.) muss man mit der MTU weiter runter gehen.

Routing: Wenn man das Netz Zuhause komplett erreichen will und der Router auch nicht der VPN EndPoint ist, muss man dem Netz auch (z.B. über DHCP) die richtige Route mitgeben. Die Lösung habe ich so umsetzen müssen.

Danke!

Zu DSLite kann ich leider nichts beitragen. Mein Provider gibt mir natives Dual-Stack IP via PPPoE. Die minimal empfohlene MTU für IPv6 ist ohnedies 1280. Das muss man eben mit den ICMP-Probes mit don't fragment austesten, was die Obergrenze ist. Auf einer der OpenVPN-Listen hat sich einmal jemand die Mühe einer Tabelle gemacht, die scheint aber nur für tap-Devices zu gelten.

Ad Routing: guter Punkt - Wenn der Heimrouter zugleich auch OpenVPN-Endpunkt und Default-Router für das Heimnetz ist, erübrigt sich das wohl.

Ist er das nicht nicht, habe ich hier ein Posting dazu: https://forum.funkfeuer.at/t/r…manipulieren-solved/164/5 - kurz gefasst:

Was zumeist funktioniert ist DHCP-Option 33 Hostrouten (RFC 2132).

Nicht immer - vor allem nicht mit Android bis 4.4 funktioniert: RFC 3442: Option 121 (Classless Routes).

Microsoft Option 249 ist ein Thema für sich...

Und jetzt würde ich mich über eine Erfolgsmeldung freuen

Zitat von Pappy

[...]

Ich befürchte auch langsam das dir Verbindung bei meiner Leitung nicht schneller werden kann bei maximal 1Mbit/s upload. Die andere OpenVPN APP(nicht Connect) zeigt immerhin auch mal Geschwindigkeiten bis 700kbit/s an.

Das ist natürlich ein wesentlicher Faktor, wenn es um den Upload vom VPN-Client Richtung Server geht. OpenVPN beherrscht allerdings auch Kompression - comp-lzo und neuerdings auch lz4. Die Kompressionseinstellung kann man in einer server - client - Konfiguration übrigens auch pushen. Die Firewall und Captive-Portal-Software pfSense ist übrigens für OpenVPN überaus komfortabel, wenn ich mir den Tip erlauben darf. Es handelt sich um ein BSD-Derivat. Auch OPNSense ist eventuell in ähnlicher Weise gut zu gebrauchen.

Anbei eine ältere Konfiguration, wie ich sie bei den UMTS und LTE-Clients eingesetzt habe.

remote gegenstelle.meinedomain.at

tun-mtu 1500

fragment 1400

mssfix

dev tun0

dev-type tun

proto udp

client

tls-auth ta.key 1

ca /etc/openvpn/meineCA.crt

cert /etc/openvpn/meinClient.crt

key /etc/openvpn/meinClient.key

remote-cert-tls server

verb 5

key-method 2

auth SHA256

cipher AES-256-CBC

fast-io

comp-lzo adaptive

dh /etc/dhparam2048.pem

persist-tun

persist-key

Variante:

# dev tap0

# dev-type tap

# script-security 3

# up /etc/scripts/ovpn-updown.sh

# down /etc/scripts/ovpn-updown.sh

Anmerkungen dazu: fragment 1400 bewirkt, dass eben keine Pakete größer als 1400 Byte gesendet werden. Die tun-mtu ist per Default-Einstellung 1500 und von den OpenVPN-Leuten wird empfohlen, die immer so zu belassen. Ebenso soll man link-mtu nicht angreifen und lediglich fragment und/oder mssfix verwenden) Da musst Du Dich mit Schätzwerten eben spielen, bis der optimale Wert gefunden ist (28 Byte habe ich abgezogen, weil wieder UDP im Spiel ist (nfs, samba, ...) und UDP-Header 8 Byte lang sind - genau wie im Beispiel oben mit ICMP. Wenn der Ping mit 1472 Byte problemlos durchgeht, dann ist daran aber auch nichts zu tun.

type tun verwende ich, da ich nur IP routen möchte. Den ganzen Ethernetheader wie bei Tap zu übertragen, wäre overkill in meiner Broadcastsuppe; keine Ahnung, wie Du das machst, aber bei kompletten Ethernetframes, eventuell vlan müssen wir anders rechnen und womöglich mit tun-mtu-extra als Parameter arbeiten.

Der Einser hinter tls-auth key 1 ist die Richtungsangabe. ca,cert,key: selbsterklärend. remote-cert-tls siehe https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage; script-security 3 (oder 2) brauche ich, wenn ich das Tunnelinterface etwa in eine Bridge legen möchte. Das up und down-Skript erfordern diese Berechtigung. auth und cipher müssen freilich bei client und server verfügbar und eingestellt sein. fast-io hilft CPU-Last unter Linux zu verringern. comp-lzo ist in den neueren OpenVPN-Versionen deprecated - stattdessen soll man nun „compress“ verwenden. Version 2.3 versteht den Parameter noch nicht. Compress alleine bewirkt aber nur packet framing compression... also compress lz4 oder compress lzo verwenden - muss auf Server und Client identisch sein. Debian 9 dh params muss man selbst erstellen, um sie benützen zu können: openssl dhparam -out /etc/dhparam.pem 2048 (da das auf Homeroutern sehr lange dauern kann, kann man das auf dem PC erstellen und rüberkopieren. persist-key behält die Tunnelkeys bei SIGUSR1 oder --ping-restart im Speicher, detto behält persist-tun die Konfiguration des tun-interfaces in diesen Fällen bei. Wenn Du mit up/down-script arbeitest um tun0 oder tap0 in eine bridge zu legen, wäre es überflüssig. Wenn Du übrigens tap-Devices verwendest, aber keine Notwendigkeit besteht alle Broadcasts zu übertragen, kannst Du mit ebtables -A FORWARD -j DROP auf der Bridge die direkte Kommunikation zwischen den Bridgeports vermeiden.

Das Routing erledigt bei mir der Server der routen setzt: route 17.31.12.0/24 und dem Client Routen pusht: push "iroute 172.31.13.0/24"... Am Ende muss der Kernel dies dann nur richtig forwarden,... womit auch immer.

Ist jetzt etwas viel Info und in Details nicht ganz korrekt, sollte aber als Starthilfe genügen.

BTW: Kennst Du sshfs? Wäre vielleicht auch eine Lösung mit weit weniger Aufwand.

Zitat von CmdrXay

Hay,

das nützt nichts, da ich KEINE Mobiltelefonie auf dem Gerät habe. Ich habe IMMER eine VoIP-Verbingung über das von Android automatisch hergestellte Netz zu meiner Telefonanlage und sonst nichts.

CU, Peter

Für all jene, die nur ab und zu raustelefonieren wollen, gibt es unzählige VoIP-Out-Dienste eines meistens Luxembourgischen Unternehmens, das ich nicht näher bezeichnen werde, und seiner Partner (man findet die über Google und deren Impressum ohnehin raus und es gibt ganze Listen voll mit den Marken. Die Angebote gibt es in den Varianten SIP und proprietäre App und die sind je nach Rufziel mal da, mal dort billiger. Wenn man die Rufnummer verifizieren lässt, „darf“ man sie sogar faken - dass das so nicht ganz den Intentionen des Gesetzgebers entsprechen wird, lassen wir einmal aussen vor... Im Internet gibt es unterschiedliche Bewertungen dazu, die von Betrug bis Alles OK reichen. Ich selbst habe zwei dieser Marken einmal in Anspruch genommen und Prepaid-Guthaben aufgeladen. Die sind praktisch wenn ich von .at nach .de telefoniere, und seit drei Jahren gibt es für mich keinen Grund zur Beanstandung. Die proprietären Verbindungen kann der Handynetzbetreiber nur schwer blocken, SIP dagegen eher leicht (wobei alles eine Frage von DPI...). Eingehende Anrufe kämen weiter via 2G/3G/VoLTE/VoWifi herein - es löst also das Empfangsproblem bei eingehenden Verbindungen nicht - außer man setzt sich einen VoIP-Server mit 2G-Dongle und Sim und Wlan (Ras-/banana-/Orange pi) selbst auf, und stellt ihn ans Fenster. Als VoIP-App ist CSipSimple immer noch mein Liebling. Würde mich über andere Erfahrungsberichte freuen.

Irgendwie mühsam, wenn man sein Posting nicht editieren darf. Ich habe einfach die Platte im Servercontrolpanel „gelöscht“ - danach wurde die „Platte“ wieder erkannt. Es scheint so, als ob das anfängliche Partitionierungsproblem das QCOW oder RAW zerlegt hat, wodurch die Einbindung nicht geklappt hat. Eine neue Erfahrung für mich - interessant.

Ich wollte gerade die Eierkanone mit Debian 9 Netinstall neu aufsetzen (ich mag es einfach, wenn es unmodifizierte Images sind) und stehe vor dem Problem, dass das Netinstallimage den SCSI-Treiber der Eierkanone nicht zu erkennen vermag (keine Festplatte erkannt). Eigentlich absurd bei KVM mit recommended SCSI - wie sonst auch immer... Hat dieses Phänomen ausser mir sonst jemand beobachtet?

Manche Kunden haben in anderen Threads von I/O-Problemen berichtet - gibt es da eventuell einen Zusammenhang?

Zitat von Pappy

mtu ist wieder raus, mssfix auf 1250. Zum Test einmal "OpenVPN für Android" auf dem Handy installiert (vorher OpenVPN Connect). Nun lassen sich alle Geräte untereinander anpingen. Verbindung trotzdem noch sehr langsam.

Also ich habe mich selber mit OpenVPN -v.a. über LTE „Roadwarriors“ (also mobile Clients) eine Weile gespielt. Das Performanceproblem und das MTU-Problem hängen oft miteinander zusammen.

Ich gebe einmal ein paar allgemeine Tips:

1. Ermittlen der optimalen MTU:

ping -c2 -M do -s 1472 openvpnserver-ipv4adresse

ping6 -c2 -M do -s 1452 openvpnserver-ipv6adresse

Diese beiden Kommandos senden je zwei Pingpakete mit einer Nutzlast für eine MTU von 1500 unter Verwendung des „Don't Fragment“ Flags an den Zielhost. Kommen sie nicht durch, war das Paket zu groß. Kommen sie durch und es wird eine Antwortzeit ausgegeben, passt alles.

Mathematik dazu: Eine Nutzlast von 1472 addiert um 8 Byte für den ICMP-Header und 20 Byte für den IP-Header ergibt eine MTU von 1500 Byte.

Bei IPv6 ist der IP-Header doppelt so groß, darum 40 Byte + 8 Byte +1452 Byte = 1500.

2. Wie schon ein Vorposter meinte, kann man neben mss-fix auch Fragmente anpassen. Das OpenVPN-Manual meint dazu, dass man nur fragment und tun-mtu anpassen sollte.

tun-mtu ist die Paketgröße innerhalb des Tunnels, fragment die, die über die Providerleitung geschickt wird. Da trägt man den größten Wert ein, bei dem der Ping mit IPv6 noch funktioniert hat. (Wenn nur Singlestack v4 benützt wird, diesen Wert.)

Je mehr Pakete fragmentiert werden, desto mehr rechnet der Router und desto mehr Latenz gibt es.

Exkurs zur MTU:

Ein MTU-Problem löst man besser direkt am Providerrouter, falls möglich. PPPoE und VLANs (für Tripleplay-Dienste etc) verringern die MTU. Wenn ein Router Baby-Jumbo-Frames unterstützt und der Provider dies auch zulässt, dann arbeitet damit, um die MTU am Router auf 1500 anzuheben.

(RFC4638). Gerade DSL-Modems mit älterem Linux-Kernel, respektive DSL-Treiber können das nicht. Etwa TP-Link VR200(v) ist so ein Problemkind, auch die Providerversionen der Fritzbox 7360v1, für die es keine Updates mehr gibt. Draytek-Modems im PPPoE-Passthrough-Mode kommen aber etwa damit zurecht.

3. OpenVPN und Buffer...

Frühere Versionen von OpenVPN hatten mit den Buffern bei Verwendung unterschiedlicher Binaries für Windows, Linux, *BSD Probleme.

Es hilft manchmal, die Buffer fix einzustellen - auf beiden Seiten:

sndbuf 524288
rcvbuf 524288

Mssfix hilft nur bei TCP. Auf UDP hat es keinen Einfluss. D.h. die in 1 und 2 genannten Tricks funktionieren umfassender.

Wenn' s nicht hilft, bitte Deine Config (ohne Keys u.d.gl.) hier einmal posten.

Noch ein Hinweis: Die Route zum VPNServer und die vom VPNServer muss nicht dieselbe MTU haben... Wenn Deine Gegenstelle hinter einem Carrier Grade NAT arbeitet oder ICMP blockt, funktioniert die MTU Path Discovery nicht. Wenn dann noch die effektive MTU kleiner ist, hast Du vor allem dann, wenn Du Openvpn verschlüsselst nützt plötzlich mehr Errors im OpenVPN Log. Es empfiehlt sich dann u.U. auch serverseitig die tun-mtu und fragments anzupassen.

Zitat von fisi

Den such ich auch noch, hab alles durchgeforstet. Den schirm hab ich haber noch nicht gefunden

RaaS war zuletzt auf der Seite mit den Jobs...

Zitat von geekmonkey

Gone, ...

War bereits Sonntag ausverkauft, wurde Montag nachgefüllt, ... mit einem riesen Kontingent von 3 VPS oder so

Also auf die nächste Aktion warten

Bei sowas kann ich dann auch nachvollziehen, wenn Leute sich einen Vorteil/Ausgleich zu verschaffen versuchen - ohne aber Verständnis dafür aufbringen zu können. Ich hab mich auch bei mehreren Aktionen darüber geärgert, dass das jeweilige Ei vor Abschluss der Bestellung wieder aus dem Korb gerollt ist - Bestellschlüssel ungültig oder Produkt nicht mehr verfügbar. Diesmal hat es auch nur geklappt, weil ich jedes Ei sofort im Eilzugtempo bestellt habe. Und selbst da war ich beim VPS innert einer Minute noch zu langsam und durfte die 25 Minuten einmal abwarten. Es wäre nett, wenn so was nicht passieren würde. Vielleicht wären zeitlich eng begrenzte Voucher (Gutscheincodes) die bessere Lösung - da wüsste man wie lange man noch stöbern kann.

Zitat von jay

macht das nicht eh jeder wenn keiner hinguckt? ;-P

Das gleitet jetzt in Richtung Werbung für einen Technikhändler ab ... Warum crawlt der Hase die Ostereier mit Pythonscripts? Weil ers kann!