[gelöst] Eine einzige Webseite nicht immer erreichbar

[radiergummi]

Damit wir hier weiterkommen wäre nun abzuklären, ob Mitglieder von zerspanungsbude.net, die am selben Provider hängen wie du, das Problem auch orten können.

Die Frage nach Sitzungsabbrüchen habe ich im Forum bereits vor ein paar Monaten in allgemeinerer Form und die nach Paketverlusten gestern nochmal ganz explizit gestellt. Die mtr-Logs zeigen für den Telekom-Kunden das gleiche Problem der Paketverluste, wenn auch weniger, aber Sitzungsabbrüche scheint es dort aber keine zu geben.
Ich werde die Frage nochmal wiederholen - so ich denn durchkomme. Soll ich auch um den nmap-test (https) bitten? Belastet dieser Test den Hoster oder die Webseite besonders?
Ich werde vielleicht am besten den Seitenbetreiber vorher fragen.

Gruß,
Radiergummi

 

[radiergummi]

... und eben hatte ich einen solchen Abbruch mit diesem Forum hier. Ich hatte auf den Link zu den Logs im vorigen Post geklickt.

Gruß,
Radiergummi

 

[radiergummi]

Hallo,
der Seitenbetreiber ist einverstanden ("... solange ihr mir die Kiste nicht lahmlegt").

Ich habe einen Forumskollegen gefunden, der ebenfalls Telekom-Kunde ist, den nmap-Test machen und hier posten wird.

Bin gespannt.

Gruß,
Radiergummi

 

[radiergummi]

Ich möchte jetzt kurz einen Zwischenbericht geben.

Die Testergebnisse eines anderen Forenmitglieds stehen noch aus, werden aber kommen. Jedoch gehe ich davon aus, dass es nicht zu Verbindungsabbrüchen gekommen ist. Es hätten sich dann sicher schon lange auch andere User gemeldet.

In der Zwischenzeit habe ich weiter gelesen und getestet.

Die in den nmap-Reports, oben, sporadisch auftauchenden "GET"-requests erklären sich aus gescheiterten "HEAD" requests. Das NSE-Skript http-header versucht ein GET, wenn HEAD scheitert.

  -- Check if the user didn't want HEAD to be used
  if(useget == nil) then
    -- Try using HEAD first
    status, result = http.can_use_head(host, port, nil, path)
  end

  -- If head failed, try using GET
  if(status == false) then
    stdnse.debug1("HEAD request failed, falling back to GET")
    result = http.get(host, port, path)
    request_type = "GET"
  end

Ob das von Bedeutung ist, vermag ich nicht zu sagen.


Tests während der beiden letzten Tage:

Morgens zwischen 7 und 8 Uhr kann ich die Webseite benutzen, mtr zeigt nur wenige Paketverluste und ein traceroute geht direkt durch bis zum Ziel. Zu Abbrüchen kommt es dann nicht.

Später in den Tag hinein kommt es zu ersten Verbindungsabbrüchen und am späten Nachmittag und Abend ist der Abbruch beim zweiten Klick auf der Seite fast sicher.

Daher bin ich der Meinung, dass die jeweils vorliegende Last im Telekom- bzw. Hetzner-Netz eine Rolle spielen könnte.


Clients:
Auf den Rechnern (alle im selben Netz) läuft grundsätzlich Firefox 74 64bit auf Ubuntu 16.04 oder 18.04. Das Verhalten ist überall identisch. Es kommt zu Verbindungsabbrüchen und nmap meldet

443/tcp filtered https   no-response

ABER:
Eben habe ich versucht, die Geschichte mit Chromium auf Ubuntu 18.04 nachzustellen. Hier kommt es nicht zu Verbindungsabbrüchen. Beim direkt danach erfolgten Test mit FF kam es nach wenigen Klicks wieder zum Abbruch. Zurück zu Chromium, läuft die Sache wieder. Die Seite hängt in Chromium nur dann, wenn ich parallel FF benutze und da einen Hänger produziere.

Weder verstehe ich warum Chromium läuft und FF nicht noch verstehe ich warum eine zu Chromium bestehende Verbindung unterbricht, wenn eine Sitzung in FF abbricht.

Für mich sieht das nach drei verschiedenen Baustellen aus: a) Lasteffekte im Providernetz, b) Routing von Paketen mit verschlüsseltem Inhalt zwischen meinem Anschluss und einer einzigen URL und c) Browser-Software.

Um b) zu prüfen, würde ich gerne mal eine zweite bei Hetzner gehostete Seite versuchen - weiß aber nicht, wie ich eine finden kann

Soll ich mir mal eine neue IP holen? Die aktuelle habe ich am 22.11.2019, irgendwann zwischen 0 und 3 Uhr, bekommen.

Spass beiseite, meine Ratlosigkeit ist nicht weniger geworden.

Gruß,
Radiergummi

 

[Gräfin Klara]

Ich möchte jetzt kurz einen Zwischenbericht geben.

Und ich fange von hinten an.

Spass beiseite, meine Ratlosigkeit ist nicht weniger geworden.

Wir arbeiten uns vom server hin zu deinem System und nicht von deinem System hinaus zu einem server.
Das kann sich durchaus als Fehler herausstellen, nämlich dann, wenn die Aussage: "Eine einzige Webseite nicht immer erreichbar"
nicht richtig ist. Davon gehe ich aber nicht aus, deshalb ist die Richtung der Suche dieser Aussage angepasst.
Das dauert, deine Ratlosigkeit entspricht dem Stand der Suche.

Soll ich mir mal eine neue IP holen? Die aktuelle habe ich am 22.11.2019, irgendwann zwischen 0 und 3 Uhr, bekommen.

Alle Adressen aus dem dhcp pool stammen aus einem Adress_segment und werden über dieses Segment geroutet
Egal welche Adresse du abholst, jede ist DIR zugeordnet und alle Pakete nehmen hin und zurück den selben Weg.
Sie sind alle der gleichen Konfiguration unterworfen. Diese Aussage ist aber NUR dann richtig, wenn du die IP über dhcp abholst.
Ist es ein anderes Verfahren, dann ändere sie und bleib dabei.

Um b) zu prüfen, würde ich gerne mal eine zweite bei Hetzner gehostete Seite versuchen - weiß aber nicht, wie ich eine finden kann

Der Hoster ist nicht das Problem. das wissen wir ja schon.
Das Problem liegt in der source Adresse, Pakete aus einem bestimmten Adresssegment kommen nicht mehr zurück.

zerspanungsbude.net hat 195.201.85.4
Diese IP stammt aus einem pool von 65.535 Adressen, die an ein russisches Unternehmen vergeben wurden und die von
diesem weiter vergeben werden. 65.535 Adressen entspricht der Netzadresse 195.201.0.0/16
Die nächstliegenden Server zu zerspanungsbude.net, die ssl unterstützen, entnehme ich dem Segment 195.201.85.0/27 = 32 Hosts.
Das wären:
foren.pro-serv.de (195.201.85.7)
sender.dev.my.ua (195.201.85.10)
zamojin.blackout.ai (195.201.85.13)
server4.pxmedia.de (195.201.85.19)
Ob die alle zu Hetzner gehören, habe ich nicht geprüft weil es keine Rolle spielt. Brauchst du mehr? Dann gib es bekannt.

Der logisch nächste Test wäre das Abholen der Zertifikate von einigen dieser server, die sich alle im problematischen Segment befinden.
Beispiel:

# nmap -Pn -sT -vvvv -p https --script ssl-cert foren.pro-serv.de

Jedes positive Resultat muß das Server-Zertifikat beinhalten. Bitte nicht schneller als 4 Sek.

Die in den nmap-Reports, oben, sporadisch auftauchenden "GET"-requests erklären sich aus gescheiterten "HEAD" requests. Das NSE-Skript http-header versucht ein GET, wenn HEAD scheitert.

Alle Server unterstützen nach Definition HTTP/1.x GET, aber nicht jeder Server antwortet auf HEAD, weil unter HTTP nicht als zwingend definiert.
zerspanungsbude.net kann HEAD.
Weicht in diesem Fall das script auf GET aus, dann liegt ein Fehler vor.
Bei anderen Servers, die HEAD nicht unterstützen, wird der header mit GET abgeholt.
In dem Fall ist GET und vorhandene header_daten ok.

Jetzt ist einstweilen genug, ich melde mich wieder
Gruß
Gräfin Klara

 

[radiergummi]

... wenn du die IP über dhcp abholst.

ich gehe davon aus, dass es DHCP ist. Wenn ich den Router neu starte (vom Strom trenne), holt er sich eine Adresse.

Der logisch nächste Test wäre das Abholen der Zertifikate von einigen dieser server

Ich habe mir die Zertifikate von zweien der genannten Seiten heruntergeladen. Die Zertifikate von heute gleichen denen von gestern (wovon ich ausgegangen wäre). Während eines Verbindungsabbruchs kann ich kein Zertifikat herunterladen - no response - (eigentlich auch klar).

Weicht in diesem Fall das script auf GET aus, dann liegt ein Fehler vor.

Kann/muss ich dazu etwas prüfen?


Um die Sache nachzuvollziehen, habe ich mich auch auf die Suche begeben und bin auf ipinfo.io und robtex.com gestossen. ipinfo verweist für weitere Details auf robtex.
Hier habe ich auch Angaben zu gehosteten Webseiten (hosted domains) gefunden.

1.) ipinfo.io

Die Adresse 195.201.85.4 kommt aus dem Autonomous System (AS) mit der Nummer 24940 (ASN), welches der Hetzner Online GmbH zugeordnet ist.

https://ipinfo.io/AS24940

Dem AS24940 - hetzner.de - ist neben vielen anderen auch der Adressbereich 195.201.0.0/16 zugeordnet.

siehe hierzu https://ipinfo.io/AS24940/195.201.0.0/16

Dieser Adressbereich ist in 128 /23er Subnetze aufgeteilt. Von 195.201.0.0/23 bis 195.201.256.0/23

/23 -> Maske mit 9 Nullen 2^9 = 512 Adressen
510 Hosts: 195.201.84.1 - 195.201.85.254 (plus 84.0 und 85.255 für Netzwerk und Broadcast)

Das Subnetz 195.201.84/23 scheint nicht weiter in kleinere Subnetze unterteilt zu sein. Entsprechend findet man darunter direkt 510 (=512-2) IP-Adressen. Auch 195.201.84.255 und 195.201.85.0 als Hosts -> also nicht 2 x (256-2) = 508 sondern 2 x 256 - 2 = 510. Hier frage ich mich, ob 195.201.84.255 und 195.201.85.0 nutzbare Adressen sind, die ja in /24er Netzen die broadcast- bzw. Netzwerk-Adressen wären.



https://ipinfo.io/AS24940/195.201.0.0/16-195.201.84.0/23

Unter den IP-Adressen findet man diese und viele weitere. Die Mehrheit scheint aus Adressen zu bestehen, die Hetzner dynamisch für gehostete Kundenseiten verwendet. Adressen, wie z. B. 195.201.85.57 static.57.85.201.195.clients.your-server.de.

195.201.85.4 zerspanungsbude.net +weitere gehostete Domains
195.201.85.7 foren.pro-serv.de +weitere gehostete Domains
195.201.85.10 sender.dev.my.ua keine gehosteten Domains
195.201.85.13 zamojin.blackout.ai keine gehosteten Domains
195.201.85.19 server4.pxmedia.de +weitere gehostete Domains



2.) robtex
Hier findet man den Verweis auf Russland. Eine Adresse 10 liniya v.o. (in St. Petersburg?).

robtex sagt, dass AS24940 dieser "10th liniya" zugeordnet sei und dass für DNS-Anfragen ein Pointer (PTR) auf Hetzner zeigt (static.0.0.201.195.clients.your-server-de).

This section shows a quick analyis of the given host name or ip number.

195.201.0.0 has one PTR.
Your-server PTR

The PTR is static.0.0.201.195.clients.your-server.de. The IP number is in Russia. It is hosted by 39-55 10th liniya V.O..

We investigated one host name that point to 195.201.0.0.

Zur Segmentierung des Adressbereiches habe ich bei robtex (ohne Anmeldung) nichts gefunden. Es werden 195.201.84.0 und 195.201.85.0 als eigene Netze gezeigt. Allerdings ist auch keine Netzmaske angegeben.


Hoffentlich habe ich nicht zuviel durcheinander geworfen.

Gruß,
Radiergummi

 

[Gräfin Klara]

ich gehe davon aus, dass es DHCP ist. Wenn ich den Router neu starte (vom Strom trenne), holt er sich eine Adresse.

Ist dhcp

Kann/muss ich dazu etwas prüfen?

Nein, wenn header_daten vorhanden, alles ok.

Ich habe mir die Zertifikate von zweien der genannten Seiten heruntergeladen. Die Zertifikate von heute gleichen denen von gestern (wovon ich ausgegangen wäre). Während eines Verbindungsabbruchs kann ich kein Zertifikat herunterladen - no response - (eigentlich auch klar).

D.h. die Aussage "Eine einzige Webseite nicht immer erreichbar" ist unrichtig.

Telekom und Hetzner sind mit Sicherheit unschuldig.
Wir sollten den Fehler in deinem System suchen.

Hoffentlich habe ich nicht zuviel durcheinander geworfen.

Nein, das ist sehr interessant was du da alles ausgehoben hast.

Gruß
Gräfin Klara

 

[radiergummi]

D.h. die Aussage "Eine einzige Webseite nicht immer erreichbar" ist unrichtig.

Diese Schlussfolgerung aus dem, was ich gemacht habe, habe ich nicht verstanden.

Mein Statement aus dem Titel ist eh falsch, da ich schwerlich alle Webseiten getestet haben kann. Präziser müsste es lauten:
Unter den von mir regelmäßig besuchten Webseiten gibt es genau eine, zu der aufgebaute Verbindungen häufig abbrechen.

Mit

Während eines Verbindungsabbruchs kann ich kein Zertifikat herunterladen - no response - (eigentlich auch klar).

meinte ich, dass ich während eines Abbruchs der Verbindung zu zerspanungsbude.net kein Zertifikat von da bekommen konnte. Die Verbindung zu pro-serv oder trekkerpedia.com ist nicht abgebrochen.


Aber weiter...

ich muss jetzt erst mal verstehen, was Du danach noch zu Routen und Gateways geschrieben hast ...

Als Gateway von meiner Seite aus in dein VPN habe ich verwendet 80.157.206.242

Das benutzt auch Hetzner.
Dort sind Deine Pakete in das Telekom VPN eingestiegen und dann hast Du

die gesamte Liste aller für dich zuständigen Gateways bzw. Routes von DE.NET.DTAG.DE

das heißt, alle "Ausgänge" aus dem Telekom VPN durchprobiert und dahinter jeweils einen Router für eine Antwort gesucht. Von allen hast Du korrekte Antworten erhalten.

Hier ist die Liste. Die wird dir ja irgendwie bekannt vorkommen

Nein. Segment "N" und "F" sagt mir nichts.
Allerdings sind im oberen Teil, Seg. N, die Adressen/Hops zu finden, die ich aus den mtr-logs kenne und für Telekom Router in deren VPN gehalten habe.
z. B.
n-ea9-i.N.DE.NET.DTAG.DE (217.5.75.90)
n-ea9-i.N.DE.NET.DTAG.DE (62.154.24.222)
n-ea9-i.N.DE.NET.DTAG.DE (62.154.24.218)

Warum die alle gleich heißen, aber unterschiedliche IPs haben verstehe ich nicht. Allerdings: die IPs könnten dynamisch aus einem Pool vergeben worden sein, schließlich entstanden die mtr-logs zu unterschiedlichen Zeitpunkten.

Die Liste unter Seg. F sagt mir nichts, außer dass die Nummern nach Stichproben alle zur Telekom gehören. Ich hätte darin die uns bekannten Gateways erwartet, z. B. 80.157.206.242. Die Adresse ist aber nicht enthalten.

Du hattest geschrieben

Verbunden habe ich mich auf mehrere private router im VPN. Die selbstinstallierten sind ja fast alle verwendbar.
[Klara] -->[Gateway] --> [dein VPN] --> [privater router]-->[retour über eines der NET.DTAG.DE Gateways] ---> [Router]-->[Klara]

Das hatte ich zunächst für mich in das hier umgearbeitet:
[Klara] --> [Router] -->[Hetzner-Gateway] --> [Telekom VPN] --> [Gateway-x] --> [privater router] -->[Gateway-x] --> [Telekom VPN] --> [Hetzner Gateway] --> [Router]-->[Klara]

weil ich dachte, Du hättest damit das hier

[Hetzner] --> [Hetzner-Gateway] --> [Telekom VPN] --> [Gateway-x] --+
                                                                    + <-->[Router]      (<--> [Forumsmitglied])
[Hetzner] <-- [Hetzner-Gateway] <-- [Telekom VPN] <-- [Gateway-x] --+

nachbilden wollen (indem Du Dich an Hetzners Stelle setzt), wenn auch in umgekehrter Richtung.

Letztenendes habe ich es aber dann doch nicht verstanden.

Gruß,
Radiergummi

@Gräfin Klara
Du hast Dein Posting nochmal editiert. Soll ich meine Zitate auf die entfernten Inhalte löschen?

 

[Gräfin Klara]

Diese Schlussfolgerung aus dem, was ich gemacht habe, habe ich nicht verstanden.

Während eines Verbindungsabbruchs kann ich kein Zertifikat herunterladen - no response - (eigentlich auch klar).

meinte ich, dass ich während eines Abbruchs der Verbindung zu zerspanungsbude.net kein Zertifikat von da bekommen konnte. Die Verbindung zu pro-serv oder trekkerpedia.com ist nicht abgebrochen.

Dann ist das ein Missverständnis. Ich ging von Abbrüchen bei Tests der Liste foren.pro-serv.de, sender.dev.my.ua, etc. aus.
Reset, Urzustand

ich muss jetzt erst mal verstehen, was Du danach noch zu Routen und Gateways geschrieben hast ...

Als Gateway von meiner Seite aus in dein VPN habe ich verwendet 80.157.206.242

Das benutzt auch Hetzner.
Dort sind Deine Pakete in das Telekom VPN eingestiegen

Im Gegensatz zu dir bin ja ich kein Mitglied dieses VPNs, deshalb muß ich irgendwo hinein.
Du bist ja schon drinnen.

.. und dann hast Du

die gesamte Liste aller für dich zuständigen Gateways bzw. Routes von DE.NET.DTAG.DE

das heißt, alle "Ausgänge" aus dem Telekom VPN durchprobiert und dahinter jeweils einen Router für eine Antwort gesucht. Von allen hast Du korrekte Antworten erhalten.

Nicht ganz. (Eingang/Ausgang aus meiner Sicht, nicht deiner)
Ich habe über diesen Eingang einen verwendbaren router gesucht, der mir jeweils über einen bestimmten dieser Ausgänge (Gateways) antwortet.
D.h. mein Request entspricht deinem Response und natürlich umgekehrt.
Damit ist der gesamte Traffic nachgebildet, der routing und alles andere beinhaltet.
Da die meisten user ziemlich locker sind und ihr router einen web server offen anbietet und dieser https kann, ist auch ssl getestet.

Hier ist die Liste. Die wird dir ja irgendwie bekannt vorkommen

Nein. Segment "N" und "F" sagt mir nichts.

Mach ein reverse DNS query auf eine IP aus der Liste (nicht alle sind auflösbar).
Dann kommst du auf hostnames wie
xyz.N.DE.NET.DTAG.DE
aus Seg.N
oder
xyz.F.DE.NET.DTAG.DE
aus Seg.F
über beide mußt DU drüber.

Warum die alle gleich heißen, aber unterschiedliche IPs haben verstehe ich nicht.

Weil es unterschiedliche routes gibt, die ja irgendwo realisiert werden müssen.
Für jedes Netz-Segment eine IP. Aus einigen läßt sich der dhcp pool ableiten, sonst hätte ich keinen router finden können.

.. hätte darin die uns bekannten Gateways erwartet, z. B. 80.157.206.242. Die Adresse ist aber nicht enthalten.

Ich brauche einen Eingang. Vergleiche diese IP mit meiner obigen Erklärung.

Das hatte ich zunächst für mich in das hier umgearbeitet:
[Klara] --> [Router] -->[Hetzner-Gateway] --> [Telekom VPN] --> [Gateway-x] --> [privater router] -->[Gateway-x] --> [Telekom VPN] --> [Hetzner Gateway] --> [Router]-->[Klara]

Nein, ich kann mich nicht an Stelle Hetzner setzen, ich bin ja nicht die NSA.
Mein Test war nichts anderes als "HTTPS/SSL aus deinem VPN hinaus in die Welt" über alle möglichen routing Instanzen.
Das war ja der logisch nächte Schritt, weil es an Hetzner nicht liegt. Das wissen wir schon.
Nun wissen wir auch, dass es nicht am VPN liegt, also zwischen dir und der ganzen Klapperatur hinaus ins Web.
Wir stehen nun an deiner Haustür, direkt an deinem router, Adsl_seitig.
Der nächste Test ist von deinem router bis nach Seg.N. Wie? Muß ich erst nachdenken.

@Gräfin Klara
Du hast Dein Posting nochmal editiert. Soll ich meine Zitate auf die entfernten Inhalte löschen?

Egal, nur die Liste muß nicht hier sein.
Gruß, melde mich wieder

 

[radiergummi]

Danke für die Antwort - muss ich erst noch mal richtig lesen.

Das nur kurz zwischendurch:

Es gibt eine neue Form des Verhaltens.
Die Seite lädt nur sehr langsam, die Verbindung bricht also nicht ab.

Die Netzwerkanalyse in FF gibt an, dass 63 Sekunden (>63.000ms) für den Connect vergingen. TLS/SSL hat 21ms gebraucht, 66ms wurde gewartet und die Inhalte brauchten nochmal 1ms.

Einen Verbindungsabbruch habe ich heute Nachmittag noch nicht zustande gebracht.

Gruß,
Radiergummi

 

[Gräfin Klara]

Es gibt eine neue Form des Verhaltens.
..
Die Netzwerkanalyse in FF gibt an, dass 63 Sekunden (>63.000ms) für den Connect vergingen. TLS/SSL hat 21ms gebraucht, 66ms wurde gewartet und die Inhalte brauchten nochmal 1ms.

Du meinst FF Developer Tools > Network ? Das Tool ist recht zuverlässig aber was bedeutet das jetzt?
Wir hatten doch die Stelle, an der die Unterbrechungen auftreten, ausgemacht. Alle tcp connect() hatten bisher bei jedem Test funktioniert.
Zumindest mit nmap und das -sT für connect() war immer vorhanden. Und jetzt das! Ich verstehe es nicht.
Was machen wir jetzt? Hast du eine Vermutung?

 

[radiergummi]

Hallo,

Du meinst FF Developer Tools > Network ?

Ja. Das hatte ich vorher noch nicht benutzt und gerade mal ausprobiert. Dabei sind mir ein paar Sachen aufgefallen:
ich beziehe mich hier nur auf forum.zerspanungsbude.net (zb) und betrachte mal lediglich die erste Zeile der Liste geladener Elemente/Dateien in der Netzwerkanalyse, selektiere sie und wähle aus den Detailreports "Zeit" aus.

Fall 1, Seiten, die normal laden:
Status 200 (ok), ... , Host [ssl-Schlösschen]zb, ... und bei den Zeiten in [ms]: DNS 1, Connect 19, TLS 71, Warten 78, Empfangen 19
gleichzeitiger nmap-Report mit Header-Daten

Fall 2, Seiten, die erst kurz hängen, dann aber doch laden:
Status 200 (ok), ... , Host [ssl-Schlösschen]zb, ... und bei den Zeiten in [ms]: DNS 0, Connect 19, TLS 929, Warten 71, Empfangen 19
gleichzeitiger nmap-Report mit Header-Daten

Fall 3, Seiten, die lange hängen, dann aber doch laden: (kam heute noch nicht vor)
Status 200 (ok), ... , Host [ssl-Schlösschen]zb, ... und bei den Zeiten in [ms]: DNS kA, Connect 63.000, TLS 21, Warten 66, Empfangen 1
nmap-Report nicht verfügbar

Fall 4, Seiten, die nicht laden, weil die Verbindung abbricht:
kein Status, ... , Host [ssl-Schlösschen durchgestrichen]zb, ... keine Zeiten
gleichzeitiger nmap-Report "443/tcp filtered https no-response"

aber was bedeutet das jetzt?

Das kann ich nicht sagen. Alles was ich kann, ist beobachtete Phänomene absteigend nach vermuteter Relevanz sortieren und hier davon berichten.

Ob Fall 2 die Vorstufe zu Fall 4 ist kann ich nicht sagen.

Was machen wir jetzt?

Ich zucke nur mit dem Schultern. Sorry.

Hast du eine Vermutung?

Nein.

• es betrifft nur eine mir bekannte Webseite (gibt es andere Seiten, bei denen ich das Problem auch hätte?)
• es scheint nur bei mir so zu sein
• Abbrüche treten entweder kaum oder massiv und dann reproduzierbar auf (Netzlast?)
• Hohe Anzahl (bis 100%) von Paketverlusten bei den Telekom und Hetzner Hops (hat das mit dem Problem überhaupt zu tun?)
• eine bestehende ssl-verschlüsselte Verbindung bricht nach dem connect ab (warum? weil Prüfsummen nicht mehr stimmen? weil plötzlich Klartext gesendet wird?)
  
• mit Chromium (aus Paket, nicht lokal gebaut) passiert das nicht (den will ich aber nicht benutzen, anderes Thema) (handelt es sich doch um ein lokales Problem?, würde das Problem auch bei anderer ssl-verschlüsselter Kommunikation (kein Browser) auftreten?)

Eine andere Auffälligkeit im Zusammenhang mit den gezogenen Zertifikaten. Ich hatte die mir mal angesehen:
Moment, ich setze kurz den Aluhut auf.
Wie zufällig muss die Zeichenfolge eines mit nmap heruntergeladenen ssl-Zertifikats sein? Oder anders gefragt, was sagt die maximale Länge sich exakt wiederholender Zeichenfolgen in einem Zertifikat über dessen Qualität aus?


Gruß,
Radiergummi

EDIT: beim Abspeichern dieses Posts war die Verbindung zweimal weg.

 

[Geier0815]

Ich unterbreche eure überaus spannenden Gedankengänge nur ungern aber hast Du es schon mal mit der primitivsten Form eines Browsers versucht? Links, elinks oder w3m? Und dann kannst Du es auch mal mit einer Live-DVD ala siduction oder so mal versuchen ob da die Probleme auch auftreten. Wenn Du inzwischen Aluhutträger bist, läßt Du das Image von einem anderen Rechner aus ziehen und auf einen Stick bzw DVD ziehen oder brennen.

 

[radiergummi]

Hallo Geier0815,
ich finde ja auch, dass sich die Geschichte (mein Problem) komisch entwickelt. Moving Targets haben sich bisher (fast) immer als etwas herausgestellt, an das man anfänglich gar nicht dachte. Die Unterbrechungen nerven kolossal und ich wundere mich, dass sonst niemand davon berichtet. Ich hab zu wenig Ahnung, um selbst weiter zu kommen.

hast Du es schon mal mit der primitivsten Form eines Browsers versucht?

Jetzt ja. Habe mir eben links2 installiert. Auch damit kommt es zum Abbruch. nmap meldet nach ein paar Klicks auf der Seite "443/tcp filtered https no-response".

Gruß,
Radiergummi

 

[Gräfin Klara]

Hi

Deine Zuverlässigkeit und Präzision sind wirklich beeindruckend. In Wahrheit habe ich nämlich überhaupt keine Zeit.
Ich sitze da mit Mund- Nasenschutz und alle 20 Min. klopft mir jemand auf die Schulter und fragt: "Wann sind sie denn endlich fertig?"
Egal, Abwechslung muß auch sein.

Ob Fall 2 die Vorstufe zu Fall 4 ist kann ich nicht sagen.

Fall 2 ist ok, selbst mit 1000mS wäre das noch in Ordnung. Dieser ganze TSL Zirkus ist nicht trivial und braucht seine Zeit.

Fall 3 zeigt etwas auf, das ich leider falsch beurteilt habe.
Es gibt das connect() und das Connect wie oben angeführt.
Das connect() haben wir mit nmap x-fach geprüft und es war immer in Ordnung.
Dieses connect() ist das reine TCP connect, also eine Verbindung noch vor jedem darüberliegenden Protokoll.
Das Connect, das der Browser oben anzeigt und mit dem er offensichtlich Probleme hat, ist das Connect auf der Protokollebene http.
Erst als das erfolgreich war, kam der Status 200 (ok), das den erfolgreichen Beginn einer http Sitzung anzeigt.
Bis er aber das 200 (ok) ausgegeben hatte, vergingen x Sek. Genau an dieser Stelle wird unterbrochen.
Danach, als das http Connect doch noch abgeschlossen werden konnte, ging es weiter mit TLS (also Certifikat)
und das ging sehr schnell. Genau da liegt mein Fehler. Die nmap Zeile hätte nämlich lauten müssen:

# nmap -Pn -sT -vvv -p https --script http-headers,ssl-cert forum.zerspanungsbude.net

Dann hätten wir nämlich sofort gesehen, dass schon der header nicht ankommt und DESHALB das Certifikat gar nicht ankommen kann.
Dann wäre ich auf die blöde Idee mit SSL nicht gekommen.
pffffh

Moment, ich setze kurz den Aluhut auf.
Wie zufällig muss die Zeichenfolge eines mit nmap heruntergeladenen ssl-Zertifikats sein? Oder anders gefragt, was sagt die maximale Länge sich exakt wiederholender Zeichenfolgen in einem Zertifikat über dessen Qualität aus?

Jedes Zertifikat pro Server sieht immer gleich aus, egal wie oft du es abfragst. Unterschiede wären schwere Fehler.
Die Länge des Zertifikats sagt nur dann etwas etwas über die Qualität aus, wenn es sich um ein RSA Zertifikat handelt.
Es gibt andere Verfahren als RSA mit wesentlich kleineren Zertifikaten aber die Qualität der Verschlüsselung besser ist.
Das Zertifikat von zerspanungsbude.net ist ein RSA Zertifikat mit einer Verschlüsselungstiefe von 2048 Bits.
Das ist mehr als die meisten haben.

Wenn du schreibst: "Wie zufällig muss die Zeichenfolge .. sein" dann sehe ich daran, dass du an eine symetrische Verschlüsselung denkst.
Je verschwurbelter und gewürfelter umso sicherer. Das ist hier nicht der Fall. Das Zertifikat ändert sich nicht.
Wie dieser Mechanismus abläuft, kann ich dir gerne erläutern, wenn Interesse.

Ich bin nun der Meinung, du solltest deinen router untersuchen.

Gruß
Gräfin Klara

 

[radiergummi]

Ich bin nun der Meinung, du solltest deinen router untersuchen.

Ich wäre soweit. Was muss ich tun? Was genau sollte ich mir ansehen?
Kannst Du mir ein Stichwort geben?

Ich habe noch ein Detail, das mir bisher nicht aufgefallen war:

als ich eben diesen Beitrag hier schreiben wollte, bekam ich die Fehlermeldung
Fehler: Verbindung fehlgeschlagen (die Tabe sagte "Seitenladefehler")

ich habe dann sofort versucht die ZB aufzurufen, was auch zu einer Fehlermeldung führte. Die lautete aber anders
Seite wurde nicht gefunden (die Tabe sagte "Server nicht gefunden")

Da ich in FF keine Fehlercodes sehen konnte, kann ich leider nicht sagen, was genau (technisch) damit jeweils gemeint war.
Ist der erste Fehler ein gescheitertes connect und der zweite ein routing-Problem?

Gruß,
Radiergummi

 

[gehrke]

Sorry, habe den Thread hier nicht im Detail verfolgt.

Mein Hinweis: Evtl. hilft ja ein cronjob, welcher regelmäßig (alle x Minuten) mal einen Request via curl oder wget absetzt und dabei die relevanten Informationen (Dauer, Performance, Größe) protokolliert. Zeigt vielleicht ein zeitliches Muster auf und ist etwas leichter zu vergleichen als ein fetter Browser wie Chrom* oder Firefox.

Falls das Unsinn ist oder das schon jemand anders hatte, ignorier mich einfach.

 

[Gräfin Klara]

Ich wäre soweit. Was muss ich tun? Was genau sollte ich mir ansehen?
Kannst Du mir ein Stichwort geben?

Tur mir leid, ich bin zur Zeit im Stress.

Wie bist du mit dem router verbunden? wired/wireless?
Woher hast du deine externe IP?
Sei dir sicher und hol sie mit

# dig @208.67.222.222 -4 +short +time=5 myip.opendns.com

Versuche deine externe IP zu pingen.
Funktioniert Ja/nein?

Ich kann leider nicht direkt helfen, weil innerhalb des VPN wegen der firewall ganz andere Regeln gelten als von Außen

Gruß

 

[radiergummi]

Hallo,
@gehrke
entschuldige, dass ich mich erst jetzt melde.
Ich glaube, ich verstehe Deine Idee. Bloß, was soll ich in ein solches Skript reinschreiben?
Meinst Du so etwas?

date >> log
# ping -c 20 >> log
mtr -c 20 >> log
nmap https-headers ssl-cert >> log
wget auf die Startseite (Abruf eines Beitrags klappt nicht ohne Eingabe von Enter) >> log

Ich bin nicht sicher, ob das eine Chance hätte den Fehler zu produzieren. Versuchen könnte ich es ja mal.

Tur mir leid, ich bin zur Zeit im Stress.

Ha. Soweit kommt's ja noch. Ich bekomme hier Hilfe von sehr engagierten guten Seelen - für ein "Problem" das mir selbst immer abstruser erscheint. Alles gut!

Wie bist du mit dem router verbunden? wired/wireless?

So sieht es bei uns aus:

--- Telekom VPN (all IP) ---  [Router 1] <192...> [Router 2] <172...> [Switch] --- [servers und clients]
                                 |                                  
                                 +- Telefonie     
                                 +- Fernsehen

Alles ist verkabelt, kein WLAN. Die Firmware ist aktuell.

Woher hast du deine externe IP?

Die hole ich mir über einen cronjob alle 3 Stunden von checkip.dyndns.org ab.

Die dort angegebene IP stimmt mit der Deines Vorschlags überein. Die von mir öfter mal besuchte Seite bei Heise Security zeigt auch diese Nummer an.
Beim Stöbern zu dem Thema bin ich gestern allerdings auf https://ipinfo.info gestossen. Dort wird mir abhängig von der Sprachauswahl (ganz unten, links) bei Deutsch die korrekte und bei Englisch eine falsche IP (Cloudflare) angezeigt.

Versuche deine externe IP zu pingen. Funktioniert Ja/nein?

Funktioniert.

Danke und Gruß,
Radiergummi

 

[radiergummi]

Noch ein Zwischenergebnis:
Ich habe eben im Log der Firewall folgenden Einträge gefunden. Sie korrespondieren zu 100% mit den Abbrüchen.
Der zweite Eintrag erschien, als ich vorhin am Client einen Abbruch provoziert habe.

Idx.  System-Zeit           Quell-Adr  Ziel-Adresse  Prot.   Quell-Port   Ziel-Port  Filterregel     Limit	    Schwelle  Aktion
0001  03.04.2020 14:50:06   192.       195.201.85.4  6       19318        443        DoS protection  00000001    0         Drop
0002  03.04.2020 08:15:27   192.       195.201.85.4  6       22022        443        DoS protection  00000001    0         Drop

195.201.85.4 gehostet bei Hetzner (Zerspanungsbude)


Meine Fragen dazu:

• Wieso denn DoS??
• Wieso wird meine Adresse als Source gezeigt und die der aufgerufenen Webseite als Target (und nicht umgekehrt)?
• Hat mich mein Router von einem DoS-Angriff abgehalten und daher die Verbindung abgebrochen?? (ist doch Quatsch)
• Muss man Quelle und Ziel genau anders herum interpretieren?
• Aber selbst dann, die Bude (195.201.85.4) greift mich doch nicht per DoS an.

EDIT:

Habe noch ein Beispiel gefunden.

Router 1
########
Idx.  System-Zeit           Quell-Adr  Ziel-Adresse   Prot.  Quell-Port   Ziel-Port  Filterregel     Limit    Schwelle  Aktion
0041  28.03.2020 12:22:29   192...     138.201.75.252 6      25530        443        DoS protection  00000001 0         Drop

Router 2
########
Idx.  System-Zeit           Quell-Adr  Ziel-Adresse   Prot.  Quell-Port   Ziel-Port  Filterregel     Limit    Schwelle  Aktion
0001  28.03.2020 12:22:30   172...     138.201.75.252 6      58976        443        DoS protection  00000001 0         Drop

138.201.75.252 gehostet bei Hetzner (Liliane Susewind)

Zusätzlich zu den Fragen oben:

• Warum führt dieser Aufruf zu Verbindungsabbrüchen auf beiden Routern und nicht nur auf dem "Äußeren", Router 1 wie in allen Fällen oben?

Gruß,
Radiergummi