Naja, wir natten. Die Regel
SNAT all – * tun-+ 0.0.0.0/0 0.0.0.0/0 to:185.66.193.49
ist vielleicht auch zu weit gegriffen. Besser wäre ein (fanlin)
-A POSTROUTING -i bat+ -o tun-+ -j SNAT --to-source 185.66.193.49
Willste mal ausprobieren? Dann wird nur das genattet, was über die batman-interfaces rein kommt. Ach, ich mach einfach mal. Ergebnis: „-i“ geht mit POSTROUTING nicht, denn das passiert ja schon nach dem routing. Passt also alles so.
Vielleicht zu viele Anfragen von ein und der selben IP und ein Anti-Angriffs Mechanismus. Man könnte den Tunnel auf fanlin mal abstellen und sehen, ob es an der NAT-IP von fanlin liegt.
An der MSS Regel liegt es nicht. Habe ich gerade für ne Minute ausgeschaltet. Ist jetzt wieder an.
Gibt es noch eine andere Website, außer dem webmailer von 1und1 an der das zu beobachten ist? Ach ja: twitter.com … war mir letztens schon mal aufgefallen. Kann das noch jemand bestätigen? Aber auch nicht jedes mal…
Bei diesem Forum gab es das auch schon mal. Heute nicht.
leere Seite
Eben.
Mögliches Szenario:
Wenn Verbindung erst schnell und dann langsam → 1und1 blockt.
Gibt es das „plötzliche“ langsamer werden öfter und unabhängig von https/TLS?
Domäne 50 ist doch gar nicht auf fanlin drauf, sondern nur auf ausrufer und c1024, oder?
Verkürztes traceroute in Domäne 50
traceroute to spiegel.de (62.138.116.25)
1 10.48.144.3 (10.48.144.3)
2 100.64.6.230 (100.64.6.230)
3 xe-0-0-1-42.cr01.dus01.lwlcom.net
4 xe-0-0-2-0.cr01.bre02.lwlcom.net
Das RST hat IMHO nix mit TLS zu tun, das ist TCP.
Ja aber was ich nicht verstehe das der Absender 1&1 ist.
Wenn das von uns kommen würde müsste doch von da auch das RST kommen?
(Es sein denn der TCP state ist völlig verwirrt)
Ja, meine Frage zielt darauf, dass es bei nicht gesicherten Verbindungen diese Probleme entweder nicht gibt oder eben nur nicht aufgefallen sind, da dann „weniger streng“ auf Serverseite pro RST entschieden wird.
Jemand ™ müsste dann wohl mal am Server mitschneiden …
edit: bei mir funktioniert jetzt gerade alles wie gewohnt… der webmailer und twitter. Die werden nicht bei gleichzeitig was geändert haben. Muss also was bei uns gewesen sein. Aber was?
Ja, bei mir auch.
Kann es sein, dass es mit Geschwindigkeiten und Reihenfolge der Pakete zusammenhängt?
Dafür würde z.B. sprechen, wenn aktuell die Last auf den FF-Systemen jetzt geringer ist als gestern.
jupp, und dann ist in der zweiten Spalte auch ungefähr die gleiche Zeitdifferenz zu sehen von Hello bis ACK wie gestern bis zum RST.
Nutzen Twitter und 1und1 irgendwelche externen Blacklists?
Es gibt zumindest entsprechende Anbieter. In einem Projekt in Hamburg hat mal ein Anbieter versucht sowas in Schulen zu plazieren. Funktion: Bei unerwünschtem Inhalt zum Client ein tcp-reset senden, incl. einer Mitteilung an Lehrer und Eltern. Ich habe das nicht als Lösung empfunden.
