Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

Eine einzige Webseite nicht immer erreichbar

Alles rund um das Internet, Internet-Anwendungen (E-Mail, Surfen, Cloud usw.) und das Einrichten von Netzwerken einschl. VPN unter Linux

Moderator: Moderatoren

radiergummi
Member
Member
Beiträge: 68
Registriert: 14. Feb 2009, 12:34

Re: Eine einzige Webseite nicht immer erreichbar

Beitrag von radiergummi » 25. Mär 2020, 19:54

Gräfin Klara hat geschrieben:
25. Mär 2020, 18:48
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

Werbung:
radiergummi
Member
Member
Beiträge: 68
Registriert: 14. Feb 2009, 12:34

Re: Eine einzige Webseite nicht immer erreichbar

Beitrag von radiergummi » 25. Mär 2020, 20:06

... 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
Member
Member
Beiträge: 68
Registriert: 14. Feb 2009, 12:34

Re: Eine einzige Webseite nicht immer erreichbar

Beitrag von radiergummi » 26. Mär 2020, 07:20

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
Member
Member
Beiträge: 68
Registriert: 14. Feb 2009, 12:34

Re: Eine einzige Webseite nicht immer erreichbar

Beitrag von radiergummi » 28. Mär 2020, 15:25

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.

Code: Alles auswählen

  -- 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

Code: Alles auswählen

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
Hacker
Hacker
Beiträge: 464
Registriert: 23. Jun 2008, 20:51

Re: Eine einzige Webseite nicht immer erreichbar

Beitrag von Gräfin Klara » 28. Mär 2020, 17:59

radiergummi hat geschrieben:
28. Mär 2020, 15:25
Ich möchte jetzt kurz einen Zwischenbericht geben.
Und ich fange von hinten an.
radiergummi hat geschrieben:
28. Mär 2020, 15:25
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.
radiergummi hat geschrieben:
28. Mär 2020, 15:25
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.
radiergummi hat geschrieben:
28. Mär 2020, 15:25
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:

Code: Alles auswählen

# 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.
radiergummi hat geschrieben:
28. Mär 2020, 15:25
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

Antworten