Das längste Thema

  • Leider laden die Hälfte der Screenshots bei mir nicht.

    Scheint mal wieder an meinem Mobilfunkanbieter (Bob/A1) zu liegen. Mir bleiben am Handy gerade sporadisch diverse TLS-Verbindungen hängen. Aktiviere ich das VPN, läuft es plötzlich einwandfrei ohne Ausfälle.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Scheint mal wieder an meinem Mobilfunkanbieter (Bob/A1) zu liegen. Mir bleiben am Handy gerade sporadisch diverse TLS-Verbindungen hängen. Aktiviere ich das VPN, läuft es plötzlich einwandfrei ohne Ausfälle.

    Interessante Beobachtung... meiner Erfahrung nach wenn TLS im Mobilfunknetz und da insbesondere im Roamingnetz scheitert, dann ist es ein MTU-Problem. Wenn das VPN nicht verschlüsselt oder eine kleinere Fragment-Size eingestellt hat, kann es das Problem umschiffen. Ansonsten wäre es bei MTU-Themen selbst betroffen. Wenn sowas passiert, dann gefühlsmäßig eher im 3G Netz. Hatte das zu Beginn mit Yesss auch... jetzt schon länger nicht. Bitte beobachten und vielleicht auch mit 4G-only/3G-only spielen. Vielleicht einmal im LTE-forum.at posten?

  • Das Problem gab es bei den A1 Marken vor einigen Monaten schon ein paar Mal. Da bestätigten es damals zahlreiche User. Ich schau mal, wie es morgen aussieht. Ich bilde mir allerdings ein, dass ich das in den letzten Tagen öfters hatte. Da ich da vorwiegend im WLAN eingebucht war, schenkte ich der Sache bisher keine große Beachtung.


    MTU ist ein gutes Stichwort. Beim VPN verwende ich definitiv eine kleinere MTU.


    PS: 3G-Only. LTE habe ich am Handy deaktiviert.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zum Thema TLS haben wir aktuell im Unternehmensnetz auch eine weniger schöne Erfahrung gemacht.

    Einer der Anwender meldet sich, dass er nicht mehr als Content-Editor auf die Konzern-Webseite zugreifen kann. Das ist natürlich blöd, wenn wir 350.000 Views im Monat haben und wichtige Updates nicht veröffentlicht werden.


    Nach tagelanger Suche hat das Netzwerkteam beim Protokollieren des Traffics von diesem Client festgestellt, dass der Browser sporadisch von TLS 1.2 auf eine niedrige Version schaltet. Das kann aber die Webseite nicht.
    Nach ein paar Minuten gehts dann wieder.

    Liegt aber nicht am Browser, sondern hier zickt das Betriebssystem (Windows 10) rum.

    Ergebnis: Call by Microsoft aufgemacht.

    Learn to sit back and observe. Not everything needs a reaction

  • Ich habe noch einen zweiten Grund gefunden, warum ich wieder bei Netcup gelandet bin.

    Ich hoste meine Fotos für Freunde und Bekannte, ein Album mit rund 2.5 MB Vorschaubildern (lazy load) schafft es tatsächlich laut Performance Test in 334 ms komplett geladen zu sein.
    Der bisherige Hoster (Blau, seit kurzem neuer Name) war auch flott, aber mit 1.2 Sekunden Meilen hinter Netcup.

    Der Vorschlag vom Speedtest, doch ein CDN zu verwenden, ist schon fast Blasphemie :)

    Learn to sit back and observe. Not everything needs a reaction

  • Der Vorschlag vom Speedtest, doch ein CDN zu verwenden, ist schon fast Blasphemie :)

    Naja… ein CDN dürfte aufgrund der Architektur etwas widerstandsfähiger sein ggü. Ausfällen/Störungen im Core-Netzwerk. :P #ichsansnur

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • kerberos da lest man ja Sachen, dachte immer daß der SSL/TLS-Handshake und so vom Programm gemacht wird und das OS darauf keinen Einfluß hätte ob jetzt TLS1.0, 1.2 od. sonstwas zum Zug kommt ...:/

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • kerberos da lest man ja Sachen, dachte immer daß der SSL/TLS-Handshake und so vom Programm gemacht wird und das OS darauf keinen Einfluß hätte ob jetzt TLS1.0, 1.2 od. sonstwas zum Zug kommt ...:/

    Der TLS-Handshake wird zwar von der Applikation gemacht - somit außerhalb des Einflussbereiches des Betriebssystems. Allerdings nutzen diverse Applikationen hierzu die von Windows bereitgestellten Schannel SSP Bibliotheken. Es hängt also von der Applikation (im angesprochenen Fall vom Browser) ab, ob die Entwickler die Betriebssystem-Bibliotheken nutzen oder hierfür eigenen Code mitbringen.

  • Naja… ein CDN dürfte aufgrund der Architektur etwas widerstandsfähiger sein ggü. Ausfällen/Störungen im Core-Netzwerk. :P #ichsansnur

    Naja, ich habe keine User, die aus Timbuktu oder den Fiji-Inseln zugreifen. Und wenn doch, müssen sie halt mit etwas geringfügig höherer Antwortzeit rechnen. Ist nicht mein Problem :)

    Learn to sit back and observe. Not everything needs a reaction

  • Aktuelles Projekt: meine IPv4/IPv6 Failover IPs mit einem Python Script zwischen den Servern hin und her schaltbar machen.

    Anlässlich dieser Ankündigung stelle ich fest, dass der Suchbegriff „Failover“ im Netcup-Wiki eher dürftige Ergebnisse liefert.

    Kann man Failover-IPs/Subnets alternativ zu den dort im SCP/vSCP dokumentierten Wegen konfigurieren? Etwa mittels einer API die statische Route teilautomatisiert anfordern oder per OSPF auf der Maschine ankündigen?

  • Kann es sein, dass die TLS-Bibliothek von Postfix (Debian Stretch) gerade ein Update bekommen hat, welches die TLS 1.3 Unterstützung mitbringt?

    Ich habe nämlich paar Mails erhalten, und im Header sind zu sehen, dass die mit TLS 1.3 verschickt wurden.

    Genauso ist es auch bei Dovecot über IMAP und LMTP.

    Habe ich echt irgendwas in meinem dreiwöchigen Urlaub in Kalifornien verpasst?

    Code
    Received: from mail.domain.de
        (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
        by mail.domain.de with LMTPS
        id Ll24KvQ2/VvwYAAAOUmnOQ
        (envelope-from <joas@domain.com>); Tue, 27 Nov 2018 13:22:12 +0100
    Received: from mail.domain.com (mail.domain.com [188.68.xx.xx])
        (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
        (No client certificate requested)
        by mail.domain.de (Postfix) with ESMTPS id B2802AA000E
        for <mail@joas.de>; Tue, 27 Nov 2018 13:22:10 +0100 (CET)