Jo jo, so is dat ...
@frank_m24
Als erstes möchte ich dir danken für die Beantwortung (Bild) meiner Frage und zum anderen für den
Lösungsansatz (kommt noch), allerdings möchte ich mir für die restliche Beantwortung auch noch etwas
Zeit nehmen. Die hab ich ja zur Zeit. Bin Strohwitwer, mit einer Teilmenge meiner Kinder.
Jubel (nicht ganz ernst gemeint, liebe meine Plagen nämlich ganz dolle).
frank_m24 schrieb:
Dein Edit habe ich übrigens erst jetzt gesehen. Das ist wohl gerade entstanden, als ich den anderen Beitrag
geschrieben habe.
Wenn du die Seite des Screenshots aus dem Anhang meinst: Die geht absolut reibungslos und zügig, und zwar
sowohl mit einer T-Com IP als auch mit einer Telefonica IP. Einloggen kann ich mich zwar nicht mangels Konto,
aber bis zur Aufforderung komme ich.
Wie schon gesagt, danke.
frank_m24 schrieb:
[*]Die DNS Server können es nicht sein: Alternative DNS Server liefern keine Verbesserung, Pings und tracerts
funktionieren. Hätte mich auch gewundert. Bei den Routingproblemen der 77er IPs wurden auch immer DNS Probleme
an erster Stelle genannt, da war es genau so großer Humbug.
Hatte ich durch die alternativen Provider ausgeschlossen und war für mich ab dem Zeitpunkt auch
absolut unwahrscheinlich.
frank_m24 schrieb:
[*]Das MTU Problem, wie im verlinkten Beitrag erläutert. Weitere Kandidaten für so ein Problem sind der
GMX Webmailer und eBay. Dein Problem müsste dann auch auf anderen Seiten auftreten, nicht nur bei der Deutschen Bank.
War bei wenigen URLs auch der Fall. Z. B.
www.berlitz.de oder zähes ebay (meine Vermutung
temporäres Bandbreitenproblem oder Serverauslastung zu hoch). MTU-Wert hatte ich für mich ja auch
schon in der Geiz-ist-geil-Mentalität (MTU-Wert 1450 Byte) abgehandelt und ausgeschlossen. Ja ja, die
Lösung war so nahe.
frank_m24 schrieb:
... Das können viele Heimrouter (wie z.B. die Fritzboxen) nicht und eine DNS Abfrage schlägt fehl.
Typische Kandidaten dafür sind Server mit langen URLS und vielen IPs in der Antwort. eBay Seiten
(Mein eBay z.B.) stehen da oben auf der Liste. Abhilfe ist dann, in die Windows IP-Konfiguration
andere DNS Server einzutragen, dann müsste es gehen. Da bei der Deutschen Bank Seite weder die URL
besonders lang und auch nur eine IP in der Antwort enthalten ist, halte ich diese Variante
für sehr unwahrscheinlich. nslookups in verschiedenen Konfigurationen sorgen für Klarheit.
War mir so nicht bekannt, hatte ich durch erfolgreiches nslookup, alternative DNS-Server und
alternativer Provider unwissender Weise ausgeschlossen.
frank_m24 schrieb:
Sind https Seiten generell betroffen? Hast du mal einen anderen Browser probiert? Vielleicht gibts
Plugins, die den Zugriff verhindern? Auch Firewalls oder Virenscanner sind schon mal beleidigt, wenn
man https Seiten aufruft. Das gemeine dann: Man muss sie deinstallieren, deaktivieren reicht nicht.
Https-Seiten waren nicht generell betroffen. Hatte ich durch erfolgreiche Tests bei vielen anderen Banken
Postbank, Commerzbank, Sparda Bank, Sparkasse, Deutsche Bank (einige Auslandsseiten) und auch andere
funktionierenden Login-Seiten (https) von z. B. Webshops ausgeschlossen.
Hmmmmm... Desktop-Firewall, AV-Soft und AntiSpy-Software hatte ich nur deaktiviert. Würde mich jetzt
interessieren, ob sie wirklich deinstalliert werden müssen.
frank_m24 schrieb:
... Da gabs ein Problem mit dem Zertifikat des Servers. Irgendwie hat Firefox (aus dem Browser-Cache?
Konnte nie abschließend geklärt werden) ein falsches Zertifikat verwendet. Folge war natürlich,
dass sich Browser und Server nicht auf einen Session Key einigen konnten. Geholfen hat damals,
alle persönlichen Daten (Cache, Cookies, Passwörter ...) vom Firefox zu löschen. Danach ging es sofort wieder.
Hatte ich auch noch im Hinterkopf und habe entsprechend verfahren. Zudem testete ich alternative
Browser, auch in einem alternativen OS. War somit ausgeschlossen.
Rücksprung, weils besser paßt ...
frank_m24 schrieb:
Das konntest du gut verbergen bislang. Für den DNS Verdacht habe jedenfalls recht wenige analytisch ermittelte
Gründe gesehen. Mindestens ein nslookup Ergebnis hätte ich erwartet.
Nicht analytisch posten ist nicht synonym dafür zu sehen, nicht analytisch vorzugehen. Verkneife mir
jetzt eine Spitze, will ich auch nicht mehr in diesem Thread platzieren ..., sollte auch nicht die Basis der
Kommunikation sein!
Hatte natürlich im Vorfeld ping, tracert, nslookup zur z. B. Deutschen Bank erfolgreich getestet,
allerdings läßt sich die Loginseite (https) nicht anpingen etc. Dies geschah nach meinem ersten Posting.
Und erst im folgenden, weil mich mein Schwiegervater dauernd anbohrte, habe ich mich näher damit
befaßt. Nachdem ich dann auch noch meine Support-Anfragen durch 1&1 und der Deutschen Bank
vorliegen hatte, bemerkte ich einen leicht ansteigenden Brechreiz in mir und ich entschied mich dem
Sachverhalt auf den Grund zu gehen.
Im folgenden nochmals alles getestet ==> ping, tracert, nslookup auf unterschiedlichste Ziele (TCP/ IP,
Gateway, NAT, DNS waren i. O); alternative DNS-Server (in dem Moment, wo das Problem noch nicht
gefixt war ist es kein Humbug dies zu probieren und als Lösungsmöglichkeit zu betrachten, obwohl man
es auch als unwahrscheinlich ansieht ==> als letztes stirbt die Hoffnung); alternative Provider; MSS,
MTU und RWIN erfolgversprechend via speedguide.net (MTU zusätzlich von 1450 Byte fünferschrittweise
bis Meldung "Paket müsste fragmentiert werden" kam via ping -f -l 1450
www.deutsche-bank.de); MTU-Wert 1450 im Client
konfiguriert (und die Lösung lag so nahe); alternative Onlinebanking-Loginseiten (https), ausländische
Onlinebanking-Loginseiten der Deutschen-Bank (die waren erreichbar!!!); alternative Browser (FireFox,
Opera, IE, Konqueror, Nautilus, Galeon etc.); alternatives OS und nicht zuletzt, Schimpf-Mails an die
Supporter der Deutschen Bank.
Man nervte das alles und es brachte keine Lösung, zudem einen haufen unnütz (nicht ganz) vertaner Zeit.
Deine Postings taten ihr übriges dazu, allerdings bewirkten sie auch, dass ich sie mir genau durchlas. Ich bemerkte bei dir und in den Links das große Augenmerk, dass auf den MTU-Wert gelegt wurde.
Hatte ich zwar für mich schon abgschlossen, weil getestet. Aber ich dachte mir, na gut, konfiguriere ich
doch einfach mal den Client mit einem
MTU-Wert von 1300 Byte. Neu gebootet und siehe da das
Problem war geloest. Man, man, man ....... das ist halt was aus dem Leben.
Habe dann schrittweise den MTU-Wert bis auf !!!!!!! 1440 Byte !!!!!!! wieder anheben können, ohne
Verlustigkeit der wiedererlangten Funktion (nochmal Man, man, man ........, hatte doch bis auf
1450 Byte getestet).
Ja, ja, man lernt nie aus ...
Dass ich ein wenig genervt oder provozierend auf dich reagiert habe, hat mit einem anderen Thread zu tun. Dort hast du nämlich genau so reagiert wie du es mir in deinem letzten Posting süffisant vorgeworfen hast.
Nichts für ungut, in Zukunft sollten wir sachlicher miteinander umgehen, es ist mit Sicherheit effizienter und sachdienlicher, auch für die Community.
Jetzt habe ich doch so viel geschrieben, obwohl ich es in diesem Thread vermeiden wollte. Betrachte dies
einfach als Anerkennung deinerseits und für unsere Mitleser, wobei vielleicht auch dem ein oder anderen
hiermit geholfen wird.
Und jetzt Prost, :saufen2: habe wieder Zeit mich mit meiner noch nicht beendeten Baustelle zu beschäftigen (Samba+OpenLDAP+CentOS und die Abkehr von der Datenredundanz).
