Das längste Thema

Mein extern nicht über IPv6 erreichbarer Server kann ebenfalls (api/core).telegram.org nicht über IPv6 erreichen. Von anderen Servern und Daheim geht's allerdings.

Zitat von mainziman

whoami0501 kannst Du api.telegram.org bzw. core.telegram.org IPv6-pingen?

Ja, kann ich auch. Unabhängig vom Status der Mangle Regel. Das ist ziemlich merkwürdig.

EDIT:

Zitat von frank_m

Jedenfalls sind die MSS Probleme häufig auf zu strenge ICMPv6 Einschränkungen zurückzuführen. Kommt besonders gern an PPPOE Anschlüssen vor, liegt aber eher am Server.

Telekom Business VDSL über PPPoE - richtig vermutet.

Abgesehen von forum.netucp.de außerhalb des netcup-Netztes kann ich alles per IPv6 von überall aus pingen.

vmk wie sieht es mit curl -6 --head https://api.telegram.org/ aus?

[vmk@xxx ~]$ curl -6 --head https://api.telegram.org/
HTTP/2 302 
server: nginx/1.18.0
date: Sat, 18 Jun 2022 19:10:39 GMT
content-type: text/html
content-length: 145
location: https://core.telegram.org/bots
strict-transport-security: max-age=31536000; includeSubDomains; preload
access-control-allow-origin: *
access-control-allow-methods: GET, POST, OPTIONS
access-control-expose-headers: Content-Length,Content-Type,Date,Server,Connection
[vmk@xxx ~]$

Das Ergebnis ist immer gleich, egal von wo aus.

Zitat von vmk

Das Ergebnis ist immer gleich, egal von wo aus.

dann hast Du auch das Problem nicht ...

Falls es hilft: Telekom FTTH, opnsense innerhalb von Proxmox als Router, Magenta TV über Ubiquiti WLAN per IGMPv3 funktioniert ebenso.

Zum Thema von gestern Abend: Hat noch jmd. "defekte" IPv6 Routen zu Netcup?

Gibt es auf Grundlage der u. g. Traces noch etwas, das ich tun kann, oder ist das ein Fall für den Support?

Routenverfolgung zu forum.netcup.de [2a03:4000:35:8e2::95]
über maximal 30 Hops:

  1     2 ms     1 ms     1 ms  [...].dip.versatel-1u1.de [...]
  2    13 ms     9 ms     9 ms  2001:1438::62:214:63:96
  3    11 ms     9 ms     8 ms  2001:1438:0:1::742
  4    17 ms    15 ms    16 ms  fra1813aihb001.versatel.de [2001:7f8::22b1:0:1]
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.

Routenverfolgung zu server1.bei.netcup [...]
über maximal 30 Hops:

  1     3 ms     1 ms     1 ms  [...].dip.versatel-1u1.de [...]
  2    12 ms    13 ms    11 ms  2001:1438::62:214:63:96
  3    11 ms     8 ms     8 ms  2001:1438:0:1::742
  4    17 ms    15 ms    16 ms  fra1813aihb001.versatel.de [2001:7f8::22b1:0:1]
  5    22 ms    19 ms    37 ms  ae3-1337.bbr02.anx25.fra.de.anexia-it.net [2001:7f8::a5e9:0:3]
  6    21 ms    19 ms    21 ms  2a00:11c0:47:1:47::140
  7     *     2024 ms     *     2a00:11c0:47:3::21
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.

Routenverfolgung zu server2.bei.netcup [...]
über maximal 30 Hops:

  1     3 ms     1 ms     2 ms  [...].dip.versatel-1u1.de [...]
  2    12 ms     9 ms    10 ms  2001:1438::62:214:63:96
  3    20 ms    22 ms     8 ms  2001:1438:0:1::742
  4    18 ms    15 ms    17 ms  fra1813aihb001.versatel.de [2001:7f8::22b1:0:1]
  5    41 ms    16 ms    16 ms  ae3-1337.bbr02.anx25.fra.de.anexia-it.net [2001:7f8::a5e9:0:3]
  6    20 ms    20 ms    19 ms  2a00:11c0:47:1:47::140
  7    22 ms    19 ms    19 ms  2a00:11c0:47:3::21
  8    59 ms    19 ms    19 ms  2a03:4000:ff00:1::1
  9    23 ms    20 ms    19 ms  server2.bei.netcup [...]

Zitat von axstet

Hat noch jmd. "defekte" IPv6 Routen zu Netcup?

na ja, es geht eigentlich nur um das Problem von forum.netcup.de, seit dem es ein Update erfahren hat;

alles andere passt ja - siehe Dein 3ter TRACEroute;

beim 2ten TRACEroute liegt das Problem serverseitig - schau ihn Dir nochmal genauer an, ob Du da nicht zu rigoros an der Firewall Pakete verwirfst;

/cc

Moderatoren kann man schon etwas sagen, ob nicht doch etwas unothodox zuviel an der Firewall von forum.netcup.de geblockt wurde?

Zitat von frank_m

Kommt besonders gern an PPPOE Anschlüssen vor, liegt aber eher am Server.

bei mir ist es ein 6in4-Tunnel; das Problem hat aber in der Natur der Dinge in gewisserweise die selbe Ursache,

weil ja bei PPPoE ja auch ein Tunnel intern verwendet wird ..., nur etwas anders;

Zitat von mainziman

beim 2ten TRACEroute liegt das Problem serverseitig - schau ihn Dir nochmal genauer an, ob Du da nicht zu rigoros an der Firewall Pakete verwirfst;

Vielen Dank für Deine Hilfe. Mit einem Neustart der Firewall hat sich das Problem erledigt. Warum der Neustart gestern Abend nicht geholfen hat, bleibt mir allerdings ein Rätsel.

Zitat von mainziman

das Problem hat aber in der Natur der Dinge in gewisserweise die selbe Ursache,

weil ja bei PPPoE ja auch ein Tunnel intern verwendet wird ..., nur etwas anders;

Ja, das sehe ich auch so. Es passiert immer, wenn man aus irgendwelchen Gründen die MTU bzw. MSS reduzieren muss, z.B. durch zusätzlichen Protokoll-Overhead.

axstet: Die Probleme mit dem Forum sind ja bekannt, und die auf deinem server1 hast du vermutlich selber zu verantworten.

Passend zu den aktuellen Temperaturen

Zitat von [netcup] Lars S.

Hallo mainziman,

die rDNS-Einträge sind nun korrekt gesetzt (es kann aufgrund des DNS-Cachings ggf. ein wenig dauern, bis dir dies korrekt angezeigt wird).

Das Forum ist via IPv6 erreichbar:

Oder funktioniert dies in deinem / eurem Fall nicht? Es werden jedoch Ping-Antworten (ICMP) per IPv6 blockiert, ich werde abklären, ob wir dies ändern können.

Alles anzeigen

Hallo [netcup] Lars S. ,

hast du ein Update dazu?

Hat hier irgendjemand (administrative) Erfahrung mit Coturn bzw. Anrufen in Nextcloud Talk?

Ich wollte nur schnell Nextcloud Talk (*) mit einem eigenen STUN/TURN Server testen, größtenteils anhand dieser Anleitung. Zuerst mit einem Testsetup im lokalen Netzwerk, also mit privaten IP-Adressen, jetzt sogar extra auf einem frisch installierten VPS von netcup. Allerdings funktioniert es nicht, egal was ich versuche. In den Logs taucht andauernd so eine Meldung auf, wobei die bemängelte IP-Adresse immer gleich ist:

ERROR: A peer IP 10.24.***.*** denied in the range: 10.0.0.0-10.255.255.255

Das Problem daran: Das ist nicht meine IP-Adresse. Ich verwende so ein Subnetz nirgends. Auch Upstream gibt es dieses Subnetz gar nicht. Woher zum Teufel nimmt der das?

* Frische Nextcloud Installation, zwei LineageOS Geräte mit der Talk App. Die Geräte hängen in verschiedenen Netzwerken, sind also durch eine Firewall getrennt und müssen zwingend TURN verwenden.

Würde ja gerne behaupten ich hätte das, aber haben das ziemlich schnell durch BBB abgelöst.

warum ich den rotierenden rost vom großen H so hasse? hat doch glatt mein vorbenutzer der festplatte keinen write cache aktiv gehabt.

diskstats_latency-day.png

Zitat von hoedlmoser

warum ich den rotierenden rost vom großen H so hasse? hat doch glatt mein vorbenutzer der festplatte keinen write cache aktiv gehabt.

diskstats_latency-day.png

Vermutlich aus dem einfachen Grund, dass er bei nem Powerloss keinen Datenverlust riskieren wollte. Gerade bei Backup oder Archivsystemen ist das durchaus legitim, wenn Integrität wichtiger als I/O ist.

whoami0501

Mooooment!

Wir wollten hier gerade schön gemütlich den dummen Vorbesitzer bashen. Da kannst du jetzt nicht einfach mit Argumenten und so kommen, so läuft das im Internet nicht!

Zitat von ThomasChr

Wir wollten hier gerade schön gemütlich den dummen Vorbesitzer bashen

Ich bash den trotzdem. Immerhin kann man auch einfach ordentlich FSYNC durchführen, als ob mich jetzt interessiert ob die Hälfte oder ein Viertel der Datei weg geschrieben wurde. Wenn der FSYNC nicht mehr durch kommt bringt mir das auch nix mehr.

Und den Nachbesitzer interessiert es gar nicht wieso es dazu kam, er bekommt halt 'ne durchgenudelte Platte.

Zitat von hoedlmoser

warum ich den rotierenden rost vom großen H so hasse? hat doch glatt mein vorbenutzer der festplatte keinen write cache aktiv gehabt.

diskstats_latency-day.png

Das muss so sein wie 'ne gebrauchte GPU zu kaufen, wo sich heraus stellt dass sie aus einer mining farm kommt.