Website lädt von zuhause nicht (UPC Take IT max)

[Philee]

Aus dem Wireshark Log werde ich leider auch nicht schlauer.

[zid]

hallo philipp,

>"...Aus dem Wireshark Log werde ich leider auch nicht schlauer..."
hm, und wie sollen wir schlauer werden, wenn du uns nur einen screenshot, aber keine volle .pcap präsentierst?
daß ein rst,ack im spiel ist, wissen wir schon seit deinem ersten post, weil du da von "ERR_CONNECTION_REFUSED" redest, und variationen auf "connection refused/CONNECTION REFUSED" bekanntlich umschreibungen für rst,ack sind. "blöderweise" können rsts aus vielen gründen ausgelöst werden, und die sieht man nur, wenn man die packet details der syns vorliegen hat, und dazu brauchts eben die volle .pcap.
nichtsdestotrotz gibts good news für dich:
die rsts,acks sind sicher nicht lokal generiert, weil sie mit rd. 600 ms verzögerung relativ langsam reinkommen. wenn sie lokal generiert wären, würden wir nicht über ms, sondern über µs reden. schaut bei mir so aus (camelcamelcamel.com steht auf einer meiner privaten blacklists):

local_reject_with_tcp-reset.png (25.31 KiB) 23972-mal betrachtet

unterm strich passiert bei mir das gleiche wie bei dir, nur halt deutlich schneller, und genau das ist der hinweis, daß die rsts,acks von meiner firewall stammen.


>"...Ich wüsste nicht, warum die mich blockieren sollten. Habe die Seite erst empfohlen bekomme und nie zuhause aufgerufen..."
das hat überhaupt nix zu sagen. wenn man blacklists aufsetzt, dann macht man idr. nicht "verdächtige" einzel-ips platt, sondern gleich ganze netze, was zur folge hat, daß völlig unbeteiligte auch unter die räder kommen.
hast du eine statische oder dyn. ip?

post jetzt mal deine volle .pcap, und danach reden wir weiter...

lg
zid

[rolex]

Ich kann zwar nicht viel beitragen, nur folgendes:

Mit FireFox, ZenMate und deutschem Server kommt "Connection refused", stelle ich auf Rumänien, wird die Seite geladen.

Anscheinend entweder Geo-Block oder Routing?

[Philee]

Danke für die Antworten!
Also wie es scheint liegt das Problem nicht bei mir.

zid, danke für deine Unterstützung und die Informationen!

Ich habe den Wireshark Log angehängt.
Vielleicht wirst du schlau daraus

[zid]

die syns sind ok,...

hallo philipp,

...womit einmal malformed tcp-options (okee, nicht sehr wahrscheinlich, aber theoretisch durchaus möglich) ausgeschlossen werden können.
jetzt müssen wir nur noch das thema, das der rolex angeschnitten hat, abarbeiten.
thx, rolex , an die anonymisierungsdienste hab ich gar nicht gedacht.

anonymisierungsdienste werden immer öfter geblockt, weil sie für angriffe mißbraucht werden. rennt bei dir ein wie immer gearteter anonymisierungsdienst (proxy, vpn relay, tor...)?

I. wenn ja:
dann deaktivieren und nachschauen, ob camel.com nicht anonymisiert funkt.

II. wenn nein:
in dem fall mußt du dich zwangsläufig an upc wenden, und zwar schriftlich.
das problem bei der aktion ist sicher mal die tatsache, daß kein provider es gerne hört/liest, daß eine seiner ips irgendwo black-listed is. so eine behauptung is net unbedingt ein stimmungsaufheller und muß deshalb handfest untermauert werden. tust du das nicht, dann hast du diskussionen bis ende nie. gsd. hast du deine hausaufgaben sehr sauber erledigt und kannst wirklich satt argumentieren:

1. es ist kein anonymisierer im spiel, du gehst also wirklich mit einer ip von upc ins inet.

2. die namensauflösung von camelcamelcamel.com ist korrekt. insbesondere findet kein dns spoofing von camelcamelcamel.com auf die 127.0.0.1 statt. das geht sich schon vom timing her gesehen nicht aus. wenn dns spoofing auf die 127.0.0.1 im spiel ist, dann werden die rsts,acks direkt am rechner generiert und sind deshalb um mindestens 1-2 zehnerpotenzen schneller da als jene, die von einer lokalen firewall generiert werden. schaut bei mir konkret so aus (meine rechner sind eher langsam, mit schnellen rechnern kommst du wirklich in den ns-bereich, nixi µs):

dns_spoofing_127.0.0.1_rst_ack.png (19.01 KiB) 23818-mal betrachtet

3. camel.com wird von dir nicht geblockt. i.e. bei dir rennt keine firewall, die eine regel dieses kalibers enthält:

Code: Alles auswählen

iptables -I FORWARD -p tcp -d 216.151.25.134 -j REJECT --reject-with tcp-reset

der grund is eh schon diskutiert worden: die rsts,acks kommen viel zu langsam rein.

4. die syns, die du zu camel.com schickst, sind korrekt, keine malformed tcp-options, und somit gibt es für den server keinen grund, den verbindungsaufbau von sich aus mit einem rst,ack abzuwürgen.

5. geo-blocking kommt nicht zum tragen, weil andre kunden von upc.at problos auf camel.com zugreifen können. s. a. die rückmeldungen von wajowi und viennaboy.
btw. wenn ich in meiner blacklist den eintag für camel.com deaktivier, dann komm ich problos mit all meinen ips auf diese seite, und ich werd von anexia versorgt. weiters hab ich inzwischen auch ips aus .de, .nl, .fr und .us angetestet -> nullo problemo.

so, und was kommt jetzt raus, wenn man die punkte #1-#5 aufaddiert?
deine ip bzw. das netz, in dem deine ip angesiedelt ist, ist black-listed, punkt.

zum abschluß noch ein kleiner praktischer hinweis:
häng an dein upc-mail *auf alle fälle* deine volle .pcap an, sodaß die tecs von upc deine argumente auch von sich aus nachvollziehen können.


lg
zid

[Philee]

Vielen Dank nochmals für eure Unterstützung!

Ich bin noch eine Auflösung des Problems schuldig

Die Ursache war, dass der IP-Bereich auf Seiten von camelcamelcamel.com gebannt war.
Inzwischen funktioniert die Seite problemlos!