Asterisk-Bootproblem auf Raspberry Pi beheben und automatisches Ausführen von APIBAN

7. Mai 2024

Nach einem Stromausfall bootet mein Raspberry Pi wie gewohnt, wenn der Strom wieder da ist und Asterisk fährt ebenfalls wieder hoch. Allerdings bootet Asterisk nicht korrekt und die Telefonverbindungen funktionieren nicht ordnungsgemäß.

Umgebung: Raspberry Pi 3 B, Raspbian GNU/Linux 10 (buster), Asterisk 16.2.1~dfsg-1+deb10u2

Fehler: Nicht alle Endpunkte melden sich nach dem Booten des Raspberry korrekt an. Der Ton wird nicht übertragen. Die Telefonteilnehmer sehen statt der öffentlichen IP des Asterisk-Servers die lokale IP des Raspberry Pi, auf dem Asterisk läuft. Asterisk befindet sich hinter einem Router mit Portweiterleitung. In der Asterisk-Console erscheinen regelmäßig Fehlermeldungen, dass etwas mit dem „Socket“ nicht stimmt. Leider habe ich die genaue Fehlermeldung nicht kopiert. Der Fehler ist nach einem Update oder Upgrade entstanden. Ich weiß es leider nicht mehr.

Abhilfe: Eingabe der Befehlszeile

sudo systemctl restart asterisk

Dadurch wird Asterisk neu gestartet und der Fehler ist verschwunden. Das ist natürlich keine dauerhafte Lösung, wenn der Stromausfall in  Abwesenheit geschieht und im schlimmsten  Fall mehrere Wochen verreist ist.

Deshalb soll dieser Befehl durch den Cron-Dienst automatisch ausgeführt wird. Ich habe das ungewöhnlicherweise mit der Grafischen Oberfläche gemacht, um Korrekturen besser vornehmen zu können.

Wir gehen dazu in den Ordner /etc/cron.d und legen dort eine Datei namens „startasterisk“ an. Diese Datei bekommt alle Root-Rechte.  In dieser Datei steht:

# 6.05.24 - Starten von Asterisk nach Stromausfall
@reboot /usr/local/bin/startasterisk.sh

Die Reboot-Anweisung verweist also auf die Ausführung der Bash-Datei /usr/local/bin/startasterisk.sh:

#!bin/bash
sleep 120
sudo systemctl restart asterisk

Der Umweg über die Bashdatei ist natürlich umständlich. Man hätte das auch in der /etc/cron.d/startasterisk mit einer einzigen Zeile erledigen können:

# 6.05.24 - Erneutes Starten von Asterisk 120 Sekunden zeitverzögert nach Stromausfall
@reboot sleep 120 && sudo /bin/systemctl restart /usr/sbin/asterisk

Wichtig sind eventuell die vollständigen Pfadangaben, die man wie folgt herausbekommt:

which asterisk
which systemctl

Leider bin ich nicht sicher, ob es so tatsächlich funktioniert.

# # # # # #

Erweiterung für APIBAN: Die Bash-Datei habe ich für  die automatische Blacklist APIBAN erweitert. APIBAN ist ein Muss für SIP-Server, um SIP-Scanner und Angriffe auf den SIP-Server zu blocken (siehe https://elektronikbasteln.pl7.de/apiban-schuetzt-sip-telefon-server-automatisch-vor-boesartigen-angriffen-aus-dem-internet ). So sieht die erweiterte startasterisk.sh aus:

#!/bin/bash
sleep 120
sudo systemctl restart asterisk
sleep 180
sudo /usr/local/bin/startapiban.sh &

Das „&“ in der letzten Zeile sorgt dafür, dass die startapiban.sh im Hintergrund ewig läuft.

Die startapiban.sh hat folgenden Inhalt:

#!/bin/bash
while true
do
    /usr/local/bin/apiban.sh
    sleep 3600
done

Dadurch wird die Bash-Datei /usr/local/bin/apiban.sh jede Stunde immer und ewig erneut ausgeführt, um jede Stunde die Blacklist zu aktualisieren Die apiban.sh ist im Artikel über APIBAN beschrieben.

Ob APIBAN gestartet ist und funktioniert, lässt sich mit folgenden Befehlen herausfinden:

######################################################################
# Alle IPs in der Chain APIBAN
iptables -L APIBAN --line-numbers -n -v | awk '$2 != "0" {print}'
# Anzahl der Regeln in der Chain APIBAN
iptables -L APIBAN -n --line-numbers | grep -v "Chain\|num" | wc -l
# Anzahl der Regeln in APIBAN, die tatsächlich abgewehrt wurden
iptables -L APIBAN -n --line-numbers -v | awk '$2 != "0" && NR > 2 {print}' | wc -l
# Fail2Ban zum Vergleich
fail2ban-client status asterisk
#######################################################################

Ich gebe zu, dass es etwas umständlich ist, die Aufgaben über mehrere Dateien zu verteilen. Dahinter steckt die historische Entwicklung. Da es jetzt endlich funktioniert, belasse ich es so.