search

haumacher / phoneblock

Der Spam-Filter für die Fritz!Box
https://phoneblock.net
GNU General Public License v3.0
161 stars 15 forks source link

pb-test: 408-Fehler bei Testanruf #67

Closed JensSpanier closed 3 weeks ago

JensSpanier commented 7 months ago

Gerade die Möglichkeit mit dem AB entdeckt. Sehr coole Idee!

Allerdings funktioniert mein Testanruf nicht. Wenn ich mit meinem Telefon versuche die **620 anruzrufen, hört man erstmal nichts und dann wird auf dem Telefon die Meldung "Keine Antwort" angezeigt. Zusätzlich wird in den Logs der FRITZ!Box folgender Eintrag angezeigt:

Internettelefonie mit ab-8767721510879769 über [2003:fa:ef14:3400:d9c4:4176:4ece:aff9]:50060 war nicht erfolgreich. Ursache: (408) [2 Meldungen seit 24.04.24 09:00:48]

Als Status in der App wird "aktiv" angezeigt.

Eventuell liegt es daran, dass ich als Host einen CNAME-Record eingetragen habe. Allerdings bekomme ich den auch nicht angepasst, obwohl man das Feld bearbeiten kann. Fehlt hier ein Speichern-Button?

Reicht der User ab-8767721510879769 als Information? Oder soll ich noch weitere Infos per E-Mail senden?

haumacher commented 7 months ago

Das Problem liegt offensichtlich an meiner IPv6 Netzwerkkonfiguration. Um ehrlich zu sein, verstehe ich einfach nicht, wie das richtig zu administrieren ist. Der PhoneBlock-Anrufbeantworter läuft auf einem "Server" in meinem Netzwerk "hinter" einer Fritz!Box-Firewall. In der Fritz!Box ist eine Freigabe konfiguriert, so dass VOIP/RTP-Pakete aus dem Internet an gewisse Ports an den PhoneBlock-Server weitergeleitet werden. Für diese Freigabe muss man ein IPv6-Suffix in der Fritz!Box konfigrieren, das den Server im Heimnetz identifiziert:

image

Soweit so gut, das Suffix kann man aus der ifconfig-Ausgabe auf dem Server entnehmen.

Leider ist es jetzt so, dass sich der Suffix ::d9c4:4176:4ece:aff9 des Servers von Zeit zu Zeit einfach ändert. Davon weiß die Fritz!Box aber nichts und leitet daher die Pakete an die falsche Adresse weiter - und die Päckchen lösen sich in ein Logikwölkchen auf...

Aktuell sagt ifconfig: 

root@homepi:~# ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.48  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 2003:fa:ef14:3400:62ca:86a6:8484:c7a1  prefixlen 128  scopeid 0x0<global>
        inet6 2003:fa:ef14:3400:1635:10da:38d:20e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::62ca:86a6:8484:c7a1  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:b6:1e:4d  txqueuelen 1000  (Ethernet)
        RX packets 771205625  bytes 353365802181 (329.0 GiB)
        RX errors 1655  dropped 1659  overruns 0  frame 0
        TX packets 800707235  bytes 687980895987 (640.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

D.h. der Server hat sich die beiden Suffixe :62ca:86a6:8484:c7a1 und :1635:10da:38d:20e "ausgedacht", die aber nicht mehr mit der Konfiguration in der Fritz!Box-Firewall übereinstimmen - daher kommt nichts durch. Ich kann das jetzt zwar in der Fritz!Box anpassen, aber nach ein paar Tagen ist es wieder kaputt.

Ich habe schon versucht ein sog. "Tag" für das Interface eth0 auf dem Server zu konfigurieren - in der Hoffnung, dass man damit den Suffix stabil bekommt - scheint aber nicht zu helfen:

root@homepi:~# ip token get dev eth0
token ::d9c4:4176:4ece:aff9 dev eth0

Für jeden Hinweis/Beratung bin ich dankbar... :-)

JensSpanier commented 7 months ago

Scheint so, als würde da die Privacy-Extensions von IPv6 seine Spielchen treiben. Was für ein Betriebssystem läuft denn auf dem Pi? Gibt es dort z.B. netplan? Auf meinem Heimserver mit Ubuntu 22.04 funktioniert folgende Konfiguration mit netplan super:

/etc/netplan/00-installer-config.yaml:

network:
  ethernets:
    enp0s31f6:
      dhcp4: true
      dhcp6: true
      ipv6-address-token: '::1'
  version: 2

Damit bekommt der Server dann die IP 2a0a:abcd:abcd::1. In der Fritzbox sieht es dann so aus:

grafik

Finde es übrigens sehr faszinierend und beeindruckend, dass das alles "nur" auf einem Pi läuft.

haumacher commented 7 months ago

Auf dem Pi läuft Raspbian GNU/Linux 11 (bullseye). /etc/netplan/ gibt es da leider nicht.

Ich habe bisher mit dem folgenden Skript versucht, den Pi dazu zu überreden, einen statischen Suffix für die IPv6-Adresse zu verwenden - allerdings "vergisst" er nach einer Weile die accept_ra-Einstellung wieder...

echo 1 > /proc/sys/net/ipv6/conf/eth0/accept_ra
ip token set ::62ca:86a6:8484:c7a1/64 dev eth0

Ich habe das jetzt alles nochmal aktualisiert - mit dem neuen Suffix 62ca:86a6:8484:c7a1. ifconfig zeigt jetzt zwei globale Adressen, eine mit meinem gewählten Suffix und eine andere - jeweils mit einer anderen "prefixlen" - was könnte das wohl bedeuten?

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 2003:fa:ef14:3400:62ca:86a6:8484:c7a1  prefixlen 128  scopeid 0x0<global>
        inet6 2003:fa:ef14:3400:1635:10da:38d:20e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::62ca:86a6:8484:c7a1  prefixlen 64  scopeid 0x20<link>

Davon ist jetzt die mit "prefixlen 128" die neue öffentliche IP - welche die Fritz!Box routet:

# dig phoneblock.net AAAA
phoneblock.net.     273 IN  AAAA    2003:fa:ef14:3400:62ca:86a6:8484:c7a1

Kannst Du jetzt auf diese zugreifen?

JensSpanier commented 7 months ago

curl -6 '[2003:fa:ef14:3400:62ca:86a6:8484:c7a1]' bringt leider keinen Erfolg:

curl: (7) Failed to connect to 2003:fa:ef14:3400:62ca:86a6:8484:c7a1 port 80 after 4029 ms: Couldn't connect to server

curl -6 '[2003:fa:ef14:3400:1635:10da:38d:20e]' bringt dagegen Erfolg:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://home.haumacher.de/">here</a>.</p>
<hr>
<address>Apache Server at 2003:fa:ef14:3400:1635:10da:38d:20e Port 80</address>
</body></html>

Welche ungefähren Spezifikationen bräuchte denn ein VPS bei einem Hostinganbieter? Oder ist das keine Option?

haumacher commented 7 months ago

OK - ich glaube, jetzt habe ich die IPv6-Connectivity wieder notdürftig zusammengeflickt. Die Adresse, die sich der Pi mit "prefixlen 128" zuletzt ausgesucht hat, als ich das "Token" auf die Endung der zuletzt aktiven Adresse gestellt hatte hat für das Routing von der Fritz!Box nicht funktioniert. Neues Token, neue Freigabe,...

Sollte jetzt wieder tun:

curl -6 "[$(dig phoneblock.net AAAA +noall +answer | cut -f 6)]"

Ach ja, ich habe gesehen, dass Du für deine Webseite den Dienst statuscake.com für das Server-Monitoring verwendest. Habe ich für PhoneBlock auch mal ausprobert, aber ich habe keine Option gefunden, damit die IPv6-Connectivity überwachen zu können - deren Bots greifen immer mit einer IPv4-Adresse zu...

Welche ungefähren Spezifikationen bräuchte denn ein VPS bei einem Hostinganbieter? Oder ist das keine Option?

Der Pi langweilt sich immer noch mehr oder weniger. Aus heutiger Sicht sollte das CardDAV-Update lastmäßig für bis zu 25.000 Fritz!Boxen gar kein Problem sein (ca. Faktor 4 zu den heutigen Nutzerzahlen). Mein Internetanschluss sollte sogar ein Update von bis zu 120.000 Boxen aushalten.

Wie das mit dem Cloud-Anrufbeantworter aussehen würde weiß ich noch gar nicht, da gibt es aktuell nur eine halbe handvoll Beta-Tester. Die Fritz!Box hat die unangenehme Eigenschaft, dass sie von einem IP-Telefon verlangt, dass es sich alle 5 Minuten bei ihr meldet (REGISTER). Und noch schlimmer AVM ist zu faul ein optimiertes Re-Register zu implementieren, so dass für jede Anmeldung ein voller Authentifizierungs-Zyklus Register-Unauthorized-Register-OK notwendig ist. Bei 25.000 Boxen, die alle 5 Minuten mit 4 geschwätzigen VOIP-Messages kontaktiert werden wollen ist das ein ganz ordentlicher Traffic (333 Messages/s).

Der Pi hat 4 "mäßig schnelle" CPUs und 8G RAM, von denen er aber nur 4G braucht. Das wäre dann so ungefähr die Spezifikation für einen Hosting-Anbieter, wenn man nur CardDAV unterstützen wollte.

Der Hosting-Anbieter muss dem Server erlauben Mails zu schreiben für die Registrierung (was z.B. hetzner.com nur nach explizitem Bitten macht).

Außerdem hat PhoneBlock einen Crawler/Meta-Suche mit dem er angefragte Nummer bei diversen anderen Diensten abgleicht. Bei erhöhtem Anfragevolumen landet meine IP aber regelmäßig auf deren Blackliste, was mir bei einer dynamischen Telekom-DSL-IP relativ egal ist, wenn die IP des Hostinganbieters aber blockiert wird, dann wird das schon eher lästig.

Aus obigen beiden Gründen habe ich bisher davor zurückgeschreckt, den Service "auszulagern" - würde ja auch den Spaß nehmen, den Dienst mit einem Pi vom eigenen Schreibtisch aus anzubieten... :-)

JensSpanier commented 7 months ago

Sollte jetzt wieder tun

Ja, die IPv6 ist jetzt erreichbar. Allerdings bekomme ich beim Versuch **620 anzurufen immer noch die Meldung

Internettelefonie mit ab-8767721510879769 über [2003:fa:ef14:3400:d9c4:4176:4ece:aff9]:50060 war nicht erfolgreich. Ursache: (408)

Irgendwie ist da noch die alte IP. Hab den Anrufbeantworter auch schon aus und wieder eingeschaltet.

Ach ja, ich habe gesehen, dass Du für deine Webseite den Dienst statuscake.com für das Server-Monitoring verwendest. Habe ich für PhoneBlock auch mal ausprobert, aber ich habe keine Option gefunden, damit die IPv6-Connectivity überwachen zu können - deren Bots greifen immer mit einer IPv4-Adresse zu...

Hab ich mal. Mittlerweile hoste ich eine eigene Instanz von Uptime Kuma. Statuscake nutze ich jetzt nur noch um zu checken, ob meine Instanz von Uptime Kuma noch erreichbar ist. Statuscake kann IPv6, allerdings kommt es vermutlich darauf an, welcher Server gerade den Test durchführt. Nicht alle können anscheinend IPv6: https://www.statuscake.com/locations/

Eine Möglichkeit wäre vielleicht, extra Records anzulegen, bei denen nur die IPv4 bzw. IPv6 hinterlegt ist. Damit erzwingt man den Zugriff dann über das Protokoll. Also z.B. ipv4.phoneblock.net und ipv6.phoneblock.net. Google bietet auch sowas an: https://ipv6.google.com/

Und noch schlimmer AVM ist zu faul ein optimiertes Re-Register zu implementieren, so dass für jede Anmeldung ein voller Authentifizierungs-Zyklus Register-Unauthorized-Register-OK notwendig ist.

Ach herrje. Ich bin ja echt ein Fan von FRITZ!Boxen, aber manche Sachen sind da schon merkwürdig umgesetzt.

Aus obigen beiden Gründen habe ich bisher davor zurückgeschreckt, den Service "auszulagern" - würde ja auch den Spaß nehmen, den Dienst mit einem Pi vom eigenen Schreibtisch aus anzubieten... :-)

Vielen Dank für die ausführliche Antwort. Ich kann deine Gründe sehr gut nachvollziehen. Auch die Faszination für den Pi auf dem Schreibtisch kann ich sehr gut nachempfinden. Den einzigen Vorteil bei einem VPS sehe ich aktuell bei den statischen IP-Adressen. Aber das mit der IPv6 ist ja sicherlich auch irgendwie in den Griff zu bekommen.

Ich bin mit ein paar Hobbyprojekten bei netcup und kann mich absolut nicht beklagen. E-Mail-Versand muss dort nicht extra freigeschaltet werden. Allerdings hört man im Forum ab und zu von Problemen mit Microsoft und Blackholing. Wobei die letzte Meldung in der Richtung schon länger her ist. Da gibt es auch etwas versteckt Mini-Server für kleines Geld. Aber das nur so am Rande. :)

haumacher commented 6 months ago

Ich glaube, ich habe die Netzwerk- und Registrierungsprobleme so langsam im Griff. Das Problem, dass der Pi nach einer Weile keine Router-Advertisments mehr akzeptiert hat war der DHCP-Server. Diesen muss man auf IPv4-only konfigurieren, damit er sich nicht in die IPv6-Adressvergabe einmischt. Der nächste spannende Test ist, ob die Verbindung auch stabil bleibt, wenn die Telekom das nächste Mal beschließt, meiner Box eine neue IP-Adresse zuzuweisen.

Das Update von Adressen der Client-Boxen habe ich jetzt glaube ich auch griffig (5b2ba767008fc0695389cd71a8a3ddc3e5db227d). Habe gesehen, dass Du noch einen Test-Anruf gemacht hast. Hast das funktioniert - bzw. hast Du was gehört? Nach den Logs zu urteilen hat der Pi dich jedenfalls nicht gehört - oder hast Du Dich nicht getraut mit ihm zu sprechen?

JensSpanier commented 6 months ago

Ich glaube, ich habe die Netzwerk- und Registrierungsprobleme so langsam im Griff.

Super, das klingt vielversprechend!

Hat das funktioniert - bzw. hast Du was gehört?

Ja, ich hab gespannt zugehört und nichts gesagt. Hab jetzt aber nochmal angerufen und ein bisschen was geredet.

mecki77 commented 6 months ago

Nachdem ich in einem anderen Thread gelesen habe:

"Beta-Tester für den Cloud-Dienst helfen aktuell mehr. Test System: https://phoneblock.net/phoneblock/anrufbeantworter/ (erfordert separate Anmeldung)"

Hab ich das glatt mal in meiner FritzBox 7590 eingerichtet - tolle Sache und bei mir funktioniert der Testanruf über die Nummer **624 (bei mir dem PhoneBlock AB zugewiesen) einwandfrei. Schon lustig, dachte zuerst, da ist ech einer dran ;) Scheint jetzt also im allgemeinen soweit zu funktionieren.

MarkyMarkDE commented 4 months ago

Ja, die Lösung quasi stets die komplette BLOCKLIST nutzen zu können, mittels Cloud AB ist genial und ein Alleinstellungsmerkmal

haumacher commented 3 weeks ago

Die Verbindungsprobleme sollten gelöst sein: