# IPLogger DB – IP- und Verfügbarkeitsüberwachung
## Überblick
Der `iplogger-db.sh` ist ein datenbankgestützter IP-Logger zur dauerhaften Überwachung der eigenen Internetverbindung und der öffentlichen WAN-IP-Adresse.
Das Script wurde dafür entwickelt, langfristig und nachvollziehbar festzuhalten:
- welche öffentliche IP-Adresse zu welchem Zeitpunkt aktiv war
- ob eine Internetverbindung vorhanden war
- ob lediglich die IP-Ermittlung fehlgeschlagen ist
- welche Prüfdienste funktioniert oder versagt haben
- wie lange einzelne IPs aktiv waren
- wann Provider oder Verbindungen ausgefallen sind
Der Fokus liegt nicht auf einer simplen „Wie ist meine IP“-Abfrage, sondern auf einer historisch nachvollziehbaren Langzeitaufzeichnung mit Auswertung und Zeiträumen.
Das System arbeitet vollständig datenbankbasiert und speichert jede einzelne Messung dauerhaft ab.
---
# Ziel des Systems
Der Logger beantwortet unter anderem folgende Fragen:
- Welche öffentliche IP war am 12.03.2024 um 14:00 Uhr aktiv?
- Wie lange blieb eine bestimmte IP bestehen?
- Wann erfolgte ein DSL-/WAN-Reconnect?
- War die Leitung tatsächlich offline oder nur ein Prüfdienst gestört?
- Welche Provider lieferten fehlerhafte Antworten?
- Welche DNS-/Connectivity-Ziele waren erreichbar?
- Wie oft kam es zu Unterbrechungen?
- Wie stabil arbeitet die Internetanbindung?
Gerade bei:
- DSL-Zwangstrennungen
- CGNAT-/Providerwechseln
- VPN-/Tunnelproblemen
- Routingfehlern
- sporadischen Ausfällen
- Providerstörungen
liefert die Historie eine klare technische Nachvollziehbarkeit.
---
# Architektur
Das System besteht aus mehreren Komponenten:
Komponente
Aufgabe
`providers`
Öffentliche IP-Abfragedienste
`connectivity_checks`
Prüft, ob Internet grundsätzlich erreichbar ist
`state`
Speichert Rotationszustände
`iplog`
Historische Hauptdatenbank
`summary_*`
Auswertung und Zusammenfassung
PDF-/CSV-Export
Archivierung und Dokumentation
---
# Grundlogik
Der Ablauf einer Messung sieht vereinfacht so aus:
```
1. Connectivity prüfen
2. Wenn Internet vorhanden:
3. Öffentliche IP ermitteln
4. Ergebnis speichern
5. Statistiken aktualisieren
```
Wichtig dabei:
Das Script unterscheidet sauber zwischen:
Zustand
Bedeutung
`OFFLINE`
Keine Internetverbindung
`CHECK_FAILED`
Internet vorhanden, aber IP nicht ermittelbar
`OK`
IP erfolgreich ermittelt
`INVALID_RESPONSE`
Provider lieferte ungültige Antwort
`NO_RUN`
Reservierter Status
Dadurch wird verhindert, dass ein einfacher Fehler eines einzelnen IP-Dienstes fälschlich als Internetausfall interpretiert wird.
---
# Initialisierung
## Einstiegspunkt: `init`
```
./iplogger-db.sh init
```
Dieser Befehl erstellt die komplette Datenbankstruktur.
Dabei werden automatisch angelegt:
- Tabellen
- Standardprovider
- Connectivity-Ziele
- Rotationsstatus
---
# Datenbanktabellen
Es muss vorab ein Benutzer und eine Datenbank erstellt sein. Die init-Datenbankinitialisierung erstellt dann die Tabellen.
## providers
Enthält alle IP-Ermittlungsdienste.
Standardmäßig:
- icanhazip.com
- ifconfig.me
- api.ipify.org
- checkip.amazonaws.com
Gespeichert werden zusätzlich:
- Erfolgszähler
- Fehlerzähler
- letzter Erfolg
- letzter Fehler
- Timeoutwerte
Beispiel:
Name
URL
icanhazip.com
[https://icanhazip.com](https://icanhazip.com)
api.ipify.org
[https://api.ipify.org](https://api.ipify.org)
---
## connectivity\_checks
Prüft die generelle Internetverfügbarkeit.
Standardmäßig:
- Google DNS (`8.8.8.8`)
- Quad9 (`9.9.9.9`)
- Cloudflare (`1.1.1.1`)
Die Prüfung erfolgt per Ping.
---
## state
Speichert interne Rotationsinformationen.
Dadurch wird nicht immer derselbe Provider zuerst verwendet.
Beispiele:
Name
Wert
next\_provider\_index
2
next\_connectivity\_index
1
---
## iplog
Die zentrale Historientabelle.
Hier wird jede Messung dauerhaft gespeichert.
Gespeichert werden unter anderem:
- Messzeitpunkt
- öffentliche IP
- Status
- verwendeter Provider
- Anzahl Versuche
- Fehlermeldungen
- Rohantworten
- Connectivity-Status
---
# Rotationssystem
## Warum Rotation?
Würde immer derselbe Provider zuerst verwendet werden:
- wäre dieser stärker belastet
- Fehler würden schwerer auffallen
- andere Provider würden kaum genutzt
Deshalb arbeitet das System rotierend.
---
## Beispiel
### Durchlauf 1
```
1. icanhazip.com
2. ifconfig.me
3. ipify
```
Dadurch verteilt sich die Last gleichmäßig.
---
# Connectivity-Prüfung
## Einstiegspunkt: `check` oder `run`
```
./iplogger-db.sh check
```
oder:
```
./iplogger-db.sh run
```
Beides startet dieselbe Messlogik.
---
## Ablauf der Connectivity-Prüfung
Vor der eigentlichen IP-Ermittlung wird geprüft:
- besteht überhaupt Internet?
- ist Routing vorhanden?
- funktionieren externe Ziele?
Dazu werden mehrere bekannte Ziele angepingt.
Erst wenn mindestens eines erreichbar ist, wird die IP-Abfrage gestartet.
---
# Provider-Prüfung
Nach erfolgreicher Connectivity-Prüfung:
```
curl -> Provider -> Antwort validieren
```
Dabei wird geprüft:
- ist die Antwort leer?
- ist die Antwort eine gültige IPv4?
- ist die Antwort eine gültige IPv6?
Nur dann gilt der Durchlauf als erfolgreich.
---
# Beispielabläufe
## Erfolgreicher Lauf
```
Connectivity OK
Provider erreichbar
IP gültig
→ Status OK
```
Gespeichert wird beispielsweise:
```
2026-05-12 22:00:00
IP: 93.192.117.44
Status: OK
```
---
## Internet vorhanden, aber Provider kaputt
```
Connectivity OK
Provider liefert Müll
→ CHECK_FAILED
```
Das Internet funktioniert trotzdem.
---
## Komplett offline
```
Google DNS nicht erreichbar
Cloudflare nicht erreichbar
Quad9 nicht erreichbar
→ OFFLINE
```
---
# Summary-System
Das eigentliche Kernstück ist die Verlaufsanalyse.
Einzelne Messungen werden zu Zeiträumen zusammengefasst.
---
# Einstiegspunkt: `summary`
## Tabellenansicht
```
./iplogger-db.sh summary tabelle
```
---
# Wie die Periodenerkennung funktioniert
Die Funktion `summary_rows()` analysiert die komplette Historie.
Sobald sich die IP ändert:
```
alte Periode schließen
neue Periode beginnen
```
Zusätzlich werden innerhalb der Periode gezählt:
- Offline-Ereignisse
- Fehler
- erfolgreiche Samples
---
# Detailmodus
## Einstiegspunkt
```
./iplogger-db.sh summary export pdf details
```
Der Detailmodus erzeugt eine vollständige Zeitauflistung aller erfolgreichen Messungen innerhalb einer Periode.
---
## Beispiel
```
16.02.2020 05:00 Uhr - 16.02.2020 11:00 Uhr:
IP 93.192.117.44 (24x online)
- 16.02.2020 05:00 06:00 07:00 08:00
- 16.02.2020 09:00 10:00 11:00
```
Oder bei Tageswechsel:
```
07.02.2021 04:00 05:00 06:00
08.02.2021 00:00 01:00 02:00
```
Dadurch werden lange Zeiträume kompakt lesbar dargestellt.
---
# PDF-Export
## Einstiegspunkt
```
./iplogger-db.sh summary export pdf
```
oder:
```
./iplogger-db.sh summary export pdf details
```
Der Export erzeugt automatisch:
- TXT-Zwischendatei
- PDF-Datei
- Überschrift
- Datum
- Seitenzahlen
Verwendet werden bevorzugt:
- `enscript`
- `ps2pdf`
Alternativ:
- `pandoc`
---
# CSV-Export
## Einstiegspunkt
```
./iplogger-db.sh summary export csv
```
Exportiert die zusammengefassten Perioden in maschinenlesbarer Form.
Beispiel:
```
begin_at;end_at;ip;samples;offline;fails
2026-05-01 10:00;2026-05-03 02:00;93.192.117.44;91;0;0
```
Der CSV-Import dient primär zur Übernahme historischer Daten aus der ersten Generation des IPLoggers.
Dabei werden ältere Aufzeichnungen in die neue Datenbankstruktur übernommen.
Unterstützt werden:
- erfolgreiche IPs
- Offline-Einträge
- Fehlerzustände
---
# Typische Einsatzszenarien
## WAN-Reconnects nachvollziehen
```
IP 1:
01:00 - 12:00
IP 2:
12:05 - aktuell
```
→ DSL-Zwangstrennung klar sichtbar.
---
## Providerprobleme erkennen
```
15x CHECK_FAILED
aber keine OFFLINE-Zustände
```
→ Internet vorhanden, aber IP-Dienst gestört.
---
## VPN-/Tunnelprobleme analysieren
Wenn:
- Connectivity vorhanden
- aber bestimmte Ziele nicht erreichbar
kann nachvollzogen werden:
- wann Routingprobleme begannen
- wie lange sie bestanden
- ob WAN-Wechsel beteiligt waren
---
# Besonderheiten
## IPv4 und IPv6
Das System akzeptiert beide Varianten automatisch.
---
## Zeitbasierte Rotation
Provider und Connectivity-Checks werden nicht statisch verwendet.
Das verhindert:
- Single-Point-Abhängigkeiten
- einseitige Last
- verfälschte Statistiken
---
## Dauerhafte Historie
Die Datenbank arbeitet append-only.
Neue Einträge werden ausschließlich ergänzt.
Dadurch bleibt die komplette Historie nachvollziehbar erhalten.
---
# Beispiel für Cronjob
```bash
0 * * * * /srv/scripte/iplogger-db.sh check >/dev/null 2>&1
```
Dadurch erfolgt stündlich eine neue Messung.
---
# Fazit
`iplogger-db.sh` ist kein einfacher „Wie ist meine IP“-Checker, sondern ein vollständiges Langzeit-Überwachungs- und Auswertungssystem für:
- öffentliche WAN-IPs
- Internetverfügbarkeit
- Providerstabilität
- Fehleranalysen
- historische Zeiträume
- dokumentierbare Verbindungsverläufe
Besonders wertvoll wird das System durch:
- die periodische Zusammenfassung
- die saubere Statusunterscheidung
- die rotierenden Prüfmechanismen
- die nachvollziehbare Langzeithistorie
- die Exportfunktionen für Archivierung und Dokumentation
### **💾 Download**
Das **Programm** kann hier in immer der neuesten Version heruntergeladen werden:
##### **[IPlogger Script](https://public.mariobeh.de/scripts/iplogger-db.sh)** (via mariobeh.de)