Warning: Undefined variable $galink_author_id in /var/www/clients/client3/web8/web/wp-content/plugins/google-author-link/google-author-link.php on line 148

T-Com (Telekom) – Anruf bricht nach 15 Minuten ab (900 Sekunden)

Die Foren sind voll von diesem Problem:

Ein Anruf von einem T-Com Anschluss zu einem anderen Provider bricht nach ca. 15 Minuten ab. (Oftmals bleibt der Anruf bestehen, aber man hört den Gesprächspartner nicht mehr.)

Die wenigen Lösungsvorschläge bestehen in der Regel darin, den vorhandenen Router durch eine FritzBox zu ersetzen – das kann im privaten Umfeld, wo die SIP-Registrierungen im Router hinterlegt sind, eine Lösung sein, ist jedoch für größere TK-Anlagen mit SIP-Registrierung in der TK-Anlage ggf. nicht praktikabel.

Das Problem entsteht, wenn ein REINVITE im SIP-Protokoll nach einer bestimmten Zeit – bei T-Com-Anschlüssen sind dies 15 Minuten (900 Sekunden) – initiiert wird und diese nicht mit der im Endgerät konfigurierten Zeit übereinstimmt. Im Endgerät, auf dem die SIP-Registrierungen konfiguriert sind, kann meist ein Parameter „SIP-Session-Timer“ gesetzt werden. Steht dieser nicht auf 900 Sekunden, kommt es zu oben beschriebener Problematik.

Die FritzBox hat vermutlich die 900 Sekunden als Standardparameter konfiguriert. Deshalb klappt mit ihr die Verbindung einwandfrei.

Wer also das beschriebene Problem hat und die SIP-Registrierungen direkt in der TK-Anlage hinterlegen möchte, sollte sich den Parameter „SIP-Session-Timer“ (o.ä.) genauer ansehen.

Beispiel Unify TK-Anlage:

Synology – Dateisystemmigration ext4 zu Btrfs

Ich übernehme keine Verantwortung für diese Anleitung. Ihr handelt auf eigene Gefahr! Erstellt in jeden Fall vorher ein Backup der kompletten Synology.

Dies ist eine einfache Möglichkeit vom Dateisystem ext4 zu Btrfs zu wechseln, ohne Neustart durchführen zu müssen. Ich gehe von einer Diskstation mit zwei Festplatten aus welche als RAID-Typ SHR (Synology Hybrid RAID) eingerichtet sind. Folgende Schritte sind dazu notwendig:

  1. Datensicherung vom Synology mit „Hyper Backup“ erstellen (Alle Daten inkl. Anwendungen).
  2. Festplatte 1 ziehen und an einem PC formatieren.
  3. Festplatte 1 wieder einstecken und einen neuen Speicherpool mit RAID-Typ SHR und Dateisystem Btrfs auf dieser Festplatte erstellen.
  4. Nun die einzelnen Freigaben über die „Systemsteuerung“ -> „Gemeinsame Ordner“ einzeln von Volume1 auf Volume2 migrieren. Dies kann nur hintereinander pro Freigabe durchgeführt werden und dauert je nach Datenmenge eine Weile.
  5. Wenn alle Daten migriert sind, dann Festplatte 2 ziehen und an einem PC formatieren.
  6. Alle Anwendungen über das „Paket-Zentrum“ reparieren. Ich konnte meine installierten Anwendungen nacheinander reparieren (auch „Hyper Backup“ welche gleich benötigt wird) bis auf die „PhotoStation“ – dazu später mehr!
  7. Den alten als „abgestürzt“ angezeigten Speicherpool nun löschen. Seid hier vorsichtig und überlegt 2x ob Ihr auch den richtigen erwischt habt 🙂
  8. Festplatte 2 wieder einstecken und den Speicherpool vom RAID-Typ SHR und Dateisystem Btrfs auf diese Festplatte erweitern (Festplatte dem Speicherpool hinzufügen). Nun wird das RAID initialisiert und synchronisiert. Dieser Vorgang dauert…
  9. Ab diesem Zeitpunkt konnte ich auch die „PhotoStation“ ohne Probleme wieder installieren.
  10. Nun mittels „Hyper Backup“ die einzelnen Anwendungen wiederherstellen.
  11. Das wars… Das Synology NAS ist nun auf Btrfs migriert und die Vorteile wie z.B. Snapshots etc. können genutzt werden.

Ich habe auf diese Weise eine Migration durchgeführt, welche einwandfrei funktionierte.

Check_MK Windows Zertifikatsprüfung

Die immer häufigere Anbindung von LDAPS (siehe frühere Beiträge) führt unter anderem zu dem Problem, dass die exportierten Zertifikate unbemerkt nach einer Weile auslaufen.

Um dies zu verhindern, kann man mit Check_MK die Windows Zertifikate, welche für die LDAPS Anbindung verwendet werden, überwachen.

Folgendes Skript auf dem entsprechenden Domaincontroller im Pfad „C:\ProgramData\checkmk\agent\local\windows_zertifikate_pruefen.ps1“ speichern:

# Zertifikate in cert:\LocalMachine\My\ suchen welche in 14 Tagen auslaufen

$zertifikatsabfrage = Get-ChildItem cert:\LocalMachine\My\ -recurse -ExpiringInDays 14 | Select-Object -property Subject

if($zertifikatsabfrage){
	# Ausgabe falls Zertifikate ablaufen:
	Write-Host '1 DMC-Zertifikate - Zertifikat: ' $zertifikatsabfrage
}
else{ # Ausgabe falls keine Zertifikate ablaufen: Write-Host '0 DMC-Zertifikate - Keine Zertifikate zum verlaengern.' }

Danach den Server über Check_MK neu inventarisieren. Ab jetzt kann man sich rechtzeitig um die ablaufenden Zertifikate kümmern.

Check_MK LDAP Anbindung über SSL (LDAPS)

Es wird vorausgesetzt, dass eine funktionierende LDAP Verbindung besteht. Um diese zu bearbeiten, im WATO Menü zu folgendem Punkt navigieren: „Users“ → „LDAP connections“
Dann die gewünschte LDAP Verbindung auswählen.

Hier müssen folgende Punkte ergänzt werden:

  • LDAP Server: Vollständigen Servernamen eintragen (nicht die IP-Adresse, da sonst das Zertifikat nicht übereinstimmt)
    Tipp: Bei mehreren Servern entweder alle Zertifikate bekannt machen (s.u.) oder einen Server fix auswählen, von dem das Zertifikat bekannt gemacht wird. Hier muss jeder selbst die Ausfallsicherheit entscheiden.
  • TCP Port: 636
  • Use SSL: Haken setzen
  • Alle anderen Parameter bleiben gleich wie bei LDAP ohne Verschlüsselung.

Ein Windows-Zertifikatsexport habe ich bereits hier beschrieben.

Dieses Zertifikat muss auf dem Linuxserver bekannt gemacht werden:

mv dmc_certificate.cer /usr/local/share/ca-certificates/dmc_certificate.crt
update-ca-certificates
systemctl restart apache2

Nun sollte sich Check_MK per LDAPS mit dem Active Directory Server verbinden.