home
erste Version am 07.05.2014
letzte Änderung am 31.10.2014

Erstellung einer OpenVPN-Gateway-VM


Hier dokumentiere ich die Einrichtung einer OpenVPN-Gateway-VM zu Hide.me.
Sinn und Zweck dieser VM ist es, nur an genau einer Stelle einen Tunnel zu Hide.me aufzubauen, um diesen dann von diversen Rechnern oder WLAN-Routern im LAN nutzen zu können.
Der Ansatz ist, die IP-Adresse der VM als Default-Gateway bei all den Rechnern einzutragen, die über den Tunnel laufen sollen.
Um die von Hide.me initiierte Zwangstrennung nach 24 Stunden abzufangen, kommt ein Python-Script zur Aufrechterhaltung des Tunnels zum Einsatz.

Die zweite Version meiner Tunnel-VM ist hier dokumentiert.


Inhalt
  1. Die Architektur
  2. VM erstellen
  3. OpenVPN installieren und einrichten
  4. Das Routing aktivieren
  5. Einrichtung eines Tunnel-Watchdogs
  6. Das cron-Logging bremsen
  7. Die Arbeitsweise des Tunnel-Watchdogs
  8. Erweiterung des Scripts zur Überwachung einer Transmission-VM

Die Architektur


Eine Fritzbox 7390 stellt den Zugang zum Internet her.
Ihr LAN-Port landet auf einem Switch, an dem alle anderen Rechner angeschlossen sind.
Die Fritzbox selbst hat die IP 192.168.178.1 und vergibt an die Clients Adressen von 192.168.178.20 - 192.168.178.200.

Die Gateway-VM hat eine IP im 192.168.178.x-Netz, über die der Tunnel via Fritzbox zu Hide.me läuft.
Auf einer zweiten IP im 192.168.178.x-Netz werden Pakete angenommen und durch den Tunnel geleitet.
Diese zweite IP wird als Default-Gateway für die Systeme eingestellt, die den Tunnel nutzen sollen.


VM erstellen


Erstmal wird eine neue VM angelegt.
Installationsquelle ist: debian-7.1.0-i386-CD-1.iso
Settings sind: 1 CPU, 512MB RAM und 2GB Platte
Also etwa so:
die Zusammenfassung der Settings der VM


Innerhalb der Installation wird unter Softwareauswahl eingestellt:
    SSH server
    Standard-Systemwerkzeuge

Der Hostname lautet tunnel, der User heißt dede.
Ansonsten sind die ersten Settings analog zu der Seite Build-Umgebung für Ar71xx im Abschnitt "VM erstellen"  einzustellen.

Zusätzlich kann vielleicht noch der Grub-Timeout runtergesetzt werden, damit die VM schneller startet.
sudo nano /etc/default/grub
Und darin dann den Parameter GRUB_TIMEOUT von 5 auf 1 stellen, speichern, nano verlassen und aktivieren mit:
sudo update-grub


OpenVPN installieren und einrichten


Mit
sudo apt-get install openvpn
wird openvpn installiert.
Dabei wird ein Config-Verzeichnis /etc/openvpn angelegt, in das die Config-Dateien von Hide.me kopiert werden müssen.
Zuerst sind diese aber mal zu besorgen....

Unter Serverliste sind die Config-Dateien zum jeweiligen Server-Standort über den Details-Button ladbar.
Für "Niederlande" erscheint etwa folgendes:
Downloadquelle für Config-Dateien

Nach Klick auf "Linux" öffnet sich ein Download-Fenster für die Datei Netherlands.zip.
langweiliges Download-Popup
In diesem ZIP finden sich die zwei Dateien:
    Netherlands.ovpn
    TrustedRoot.pem

Diese beiden Dateien sind nach /etc/openvpn auf der Gateway-VM zu kopieren.
Dort wird dann erstmal eine Arbeitskopie erstellt, deren Name sinnigerweise mit .conf endet (s.u.):
cd /etc/openvpn
sudo cp Netherlands.ovpn hideme.conf

Die Datei hideme.conf enthält zunächst:
client
dev tun
proto udp
remote nl.hide.me 3478
cipher AES-128-CBC
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca TrustedRoot.pem
verb 3
auth-user-pass
reneg-sec 0

Darin werden zwei Zeilen geändert auf:
client
dev tun
proto udp
remote nl.hide.me 3478
cipher AES-128-CBC
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings

ca /etc/openvpn/TrustedRoot.pem
verb 3
auth-user-pass /etc/openvpn/login.auth
reneg-sec 0
Die Datei login.auth existiert noch nicht und ist folglich anzulegen. Sie soll zwei Zeilen enthalten.
In die erste Zeile gehört die UserID des Hide.me-Accounts, in die zweite Zeile das Passwort.
Also etwa:
userid@tunnelvm
passwort

Als Gerätename wurde hier tunnelvm genutzt.
Bei Hide.me ist ein gleichnamiges Gerät anzulegen:
Dialog "Gerät anlegen" bei Hide.me

Nach einem Klick auf "Bestätigen" sollte ein
sudo service openvpn start
in der Gateway-VM bereits den Tunnel aufbauen.
Wegen der Speicherung von Netherlands.ovpn als hideme.conf findet openvpn seine Konfiguration automatisch.
Im OpenVPN-Howto heißt es:

Linux

If you install OpenVPN via an RPM or DEB package on Linux, the installer will set up an initscript. When executed, the initscript will scan for .conf configuration files in /etc/openvpn, and if found, will start up a separate OpenVPN daemon for each file.


Auf Hide.me sollte nun sowas angezeigt werden wie:
Geräteanzeige auf Hide.me


In der Gateway-VM sollte ein sudo route anzeigen, dass die Default-Route über das tun0-Interface läuft. Etwa so:
dede@tunnel:~$ sudo route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         10.3.62.194     0.0.0.0         UG    0      0        0 tun0
10.3.62.0       *               255.255.255.0   U     0      0        0 tun0
nl-16.hide.me   fritz.box       255.255.255.255 UGH   0      0        0 eth0
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0


Für einen richtigen Test aus der Gateway-VM heraus wird curl benötigt. Also:
sudo apt-get install curl

Danach die externe IP der Gateway-VM dadurch ermitteln, dass ein entsprechender Dienst befragt wird:
curl v4.ident.me;echo

Das Kommando liefert die externe IP und ein whois auf diese IP liefert dessen "Besitzer" samt Adresse und sieht beispielsweise so aus:
dede@tunnel:~$ curl v4.ident.me;echo
95.211.90.168
dede@tunnel:~$ whois 95.211.90.168
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '95.211.89.96 - 95.211.90.255'

% Abuse contact for '95.211.89.96 - 95.211.90.255' is 'abuse@leaseweb.com'

inetnum:        95.211.89.96 - 95.211.90.255
netname:        LEASEWEB
descr:          LeaseWeb
descr:          P.O. Box 93054
descr:          1090BB AMSTERDAM
[.......]

Die Gateway-VM kommt also schon mal in Amsterdam raus.
So weit, so gut....


Das Routing aktivieren


Nun ist die Gateway-VM so einzurichten, dass sie ankommende IP-Pakete durch den Tunnel leitet.
Erstmal wird ein zweites Interface angelegt:
sudo nano /etc/network/interfaces
Darin anhängen von:
auto eth0:0
 iface eth0:0 inet static
 address 192.168.178.201

Die IP 192.168.178.201 ist statisch und muß deswegen außerhalb der DHCP-Range der Fritzbox liegen.

Nun ist IP-Forwarding zu aktivieren in /etc/sysctl.conf. Also:
sudo nano /etc/sysctl.conf
Und vor net.ipv4.ip_forward=1 das Raute-Zeichen entfernen, speichern und nano verlassen.
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

Beides aktivieren mit:
sudo reboot
Dadurch kann auch gleich getestet werden, ob der Tunnel nach einem Reboot automatisch wieder aufgebaut wird.

Nach Reboot und ssh-Verbindungsaufbau werden drei Regeln für iptables angelegt:
sudo iptables -A FORWARD -s 192.168.178.0/24 -i eth0:0 -o eth0 -m conntrack --ctstate NEW -j REJECT
sudo iptables -A FORWARD -s 192.168.178.0/24 -i eth0:0 -o tun0 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
Die erste Regel weist direkte Kommunikation von eth0:0 nach eth0 ab - erzwingt also den Tunnel.
Die zweite Regel erlaubt Kommunikation von eth0:0 nach tun0 - also den Weg durch den Tunnel.
Die dritte Regel NAT'et bzw. mappt die IPs aus dem LAN auf die eine Tunnel-IP.

Für das dauerhafte Speichern der iptables-Regeln wird iptables-save genutzt:
sudo bash
iptables-save >/etc/iptables.up.rules

exit
Allerdings müssen diese Regeln nach einem Reboot wieder reaktiviert werden.
Das passiert in /etc/network/interfaces. Also:
sudo nano /etc/network/interfaces
Und dort unterhalb von
    iface eth0 inet dhcp
die Zeile
 post-up iptables-restore < /etc/iptables.up.rules
zufügen.

Das gesamte /etc/network/interfaces sollte nun folgendermaßen aussehen:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
 post-up iptables-restore < /etc/iptables.up.rules

auto eth0:0
 iface eth0:0 inet static
 address 192.168.178.201


Damit arbeitet das OpenVPN-Gateway schon mal als Gateway.
Schnell ein kurzer Test auf einem beliebigen Linux-Client.
dede@deb7txt:~$ curl v4.ident.me;echo
xxx.xxx.xxx.xxx  
(da stand meine IP ohne Tunnel - und die hat hier nichts zu suchen)
dede@deb7txt:~$ sudo route del default
dede@deb7txt:~$ sudo route add default gw 192.168.178.201
dede@deb7txt:~$ sudo route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.178.201 0.0.0.0         UG    0      0        0 eth0
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0
dede@deb7txt:~$ curl v4.ident.me;echo
109.201.143.105
dede@deb7txt:~$

Nach der Änderung des Default-Gateways auf die IP der Gateway-VM ist das System mit einer IP aus den Niederlanden unterwegs.
Klappt also offenbar so, wie es soll.


Einrichtung eines Tunnel-Watchdogs


Um der täglichen Zwangstrennung durch Hide.me entgegen zu treten, wird noch ein Python-Script auf der Gateway-VM eingesetzt, das den Tunnel regelmäßig prüft und ggf. neu aufbaut.

Zwar kann OpenVPN auch selbst mittels eines regelmäßigen Test-Pings den Tunnel prüfen und ggf. neu aufbauen - praktisch hat das auch eigentlich geklappt, aber irgendwie hatten einige Systeme nach so einem Reconnect immer gewisse Probleme mit der Verbindung. Nach sudo service openvpn stop und sudo service openvpn start waren diese Probleme dann jeweils weg. Ohne beliebig lange Fehler-Analyse zu betreiben, dessen Test-Frequenz ja bei unerfreulichen 1 pro 24 Stunden gelegen hätte, habe ich dieses Script gebaut.

Das Script benötigt python-pycurl. Folglich ist das Paket mittels
sudo apt-get install python-pycurl
zu installieren.

Aus Ordnungs-Gründen wird ein bin-Verzeichnis im Home-Verzeichnis angelegt:
cd
mkdir bin

und dieses Script dann nach ~/bin kopiert.

Nach dem Download muß das Script noch mit
chmod +x ~/bin/tunnel_watchdog.py
ausführbar gemacht werden.

Das Script geht davon aus, dass die Fritzbox mit ihrer Default-IP (192.168.178.1) betrieben wird.
Bei Bedarf muß die IP der Fritzbox im Script angepasst werden. Und zwar in der Zeile:
FRITZBOX_IP ="192.168.178.1"
Weil das Script die Fritzbox (bzw. konkret dessen externe IP) via UPnP abfragt, darf der Haken bei "Statusinformationen über UPnP übertragen" unter Heimnetz/Netzwerk/Netzwerkeinstellungen nicht entfernt worden sein.
Screenshot aus dem Fritzbox-WebGUI

Über den Wert der Variable AUTO_RECONNECT_AT wird festgelegt, zu welcher Uhrzeit täglich ein automatischer Neuaufbau des Tunnels erfolgen soll.
AUTO_RECONNECT_AT="04:00"
Bei obiger Einstellung wird der  Tunnel also um 04:00 Uhr nachts neu aufgebaut werden.
Ist kein automatischer Neuaufbau des Tunnels gewünscht, ist der Wert auf "--:--" einzustellen.

Meine Fritzbox läuft derzeit noch mit FRITZ!OS 06.03.
In FRITZ!OS 06.20 wurden offenbar Änderungen am upnp-API vorgenommen.
Gemäß einem Post zu meinem Bandbreitenmonitor ist dazu die Zeichenfolge "upnp/control/" durch "igdupnp/control/" zu ersetzen.
In tunnel_watchdog.py sind also in den Zeilen 201 und 208 die drei Zeichen "igd" vor dem "upnp/control/" einzufügen, wenn die Fritzbox-Firmware >=6.20 ist.
Sobald ich meine Fritzbox auf diese Version aktualisiert habe, wird das Script automatisch auch mit Firmware-Versionen >=6.20 umgehen können.

Das Script soll den Tunnel regelmäßig (1x pro Minute) prüfen. Der Aufruf erfolgt via cron-Job mittels:
crontab -e
und anhängen von
*  * * * *   $HOME/bin/tunnel_watchdog.py
Dadurch wird das Script nun 1x pro Minute aufgerufen - auch wenn Niemand an der Gateway-VM angemeldet ist.


Das cron-Logging bremsen

Bei jedem Aufruf des Watchdog-Scripts werden Einträge in /var/log/auth.log und /var/log/syslog erzeugt.
Weil das einmal pro Minute passiert, steht fast nichts anderes mehr in den Logs, als diese Einträge.

/var/log/auth.log:
Jul 25 19:59:01 tunnel CRON[25020]: pam_unix(cron:session): session opened for user dede by (uid=0)
Jul 25 19:59:11 tunnel CRON[25020]: pam_unix(cron:session): session closed for user dede
Jul 25 20:00:01 tunnel CRON[25033]: pam_unix(cron:session): session opened for user dede by (uid=0)
Jul 25 20:00:11 tunnel CRON[25033]: pam_unix(cron:session): session closed for user dede
Jul 25 20:01:01 tunnel CRON[25071]: pam_unix(cron:session): session opened for user dede by (uid=0)
Jul 25 20:01:11 tunnel CRON[25072]: pam_unix(cron:session): session closed for user dede

/var/log/syslog:
Jul 25 19:59:01 tunnel /USR/SBIN/CRON[25021]: (dede) CMD ($HOME/bin/tunnel_watchdog.py)
Jul 25 20:00:01 tunnel /USR/SBIN/CRON[25034]: (dede) CMD ($HOME/bin/tunnel_watchdog.py)
Jul 25 20:01:01 tunnel /USR/SBIN/CRON[25073]: (dede) CMD ($HOME/bin/tunnel_watchdog.py)



Um das abzustellen, wird erstmal cron das Logging im syslog abgewöhnt. Dazu:
nano /etc/default/cron
und anhängen von:
EXTRA_OPTS="-L 0"
Aktivieren mit:
/etc/init.d/cron restart


Dann das Logging in auth.log in eine eigene Datei umleiten. Anlegen von:
nano /etc/rsyslog.d/30-cron.conf
und einfügen von:
# Cronjob-Spam umleiten
:msg, contains, "pam_unix(cron:session):" -/var/log/cronauth
& ~
Aktivieren mit:
/etc/init.d/rsyslog restart

Und dann noch logrotate für das neue Logfile einrichten:
nano /etc/logrotate.d/cronauth
und einfügen von:
/var/log/cronauth
{
        rotate 4
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}
Dadurch wird für /var/log/cronauth nun täglich eine neue Datei angelegt und es werden Backups von den letzten vier Tagen vorgehalten.


Die Arbeitsweise des Tunnel-Watchdogs


Das Script legt zwei Dateien im Home-Verzeichnis an.

log_tunnel_watchdog.txt
Diese Datei ist das Logfile des Scriptes. Hier werden alle Status-Änderungen mit einem Zeitstempel protokolliert. Bei Bedarf kann es mittels
tail -f log_tunnel_watchdog.txt
dauerhaft angezeigt werden.
.tunnel_watchdog.conf
In dieser [quasi unsichtbaren] Datei merkt sich das Script
  • die zuletzt für gut befundene externe IP-Adresse (um dadurch nicht jede Minute sämtliche Tests durchlaufen zu müssen, wenn sich die externe IP gar nicht geändert hat).
  • einen Zähler für unmittelbar aufeinander folgende erfolglose Versuche, die externe IP der Gateway-VM zu ermitteln (um nach fünf Fehlversuchen den Tunnel neu aufbauen zu können).
  • einen Zeitstempel von dem Zeitpunkt, an dem das Script den Tunnel zuletzt überprüft hat (nur zur Info).
  • die Länderkennung der externen IP (nur zur Info).
  • einen Zeitstempel von dem Zeitpunkt, an dem der Tunnel oder die VM (je nachdem, was jünger ist) zuletzt neu gestartet wurde (nur zur Info).

Das Script prüft (einmal pro Minute) einige der folgenden Zustände bzw. Gegebenheiten:

Der Ablauf des Scriptes ist folgender:
    wenn die Außenwelt erreichbar ist
        und die externe IP ungleich der externen Fritzbox-IP ist
            dann ist alles gut...
        wenn externe IP gleich der externen Fritzbox-IP ist
            dann steht der Tunnel nicht mehr
            Tunnel neu starten
    wenn die Außenwelt nicht erreichbar ist
        Info-Ausgabe: läuft openvpn, Default-GW
        wenn openvpn läuft und Default-GW==tun0
            etwas warten
            Außenwelt-Test 3x wiederholen
        wenn Außenwelt immer noch nicht erreichbar ist
            Tunnel neu starten

Der Inhalt des Logfiles sieht dann etwa so aus:
2014.05.13-04:00:01 Der Tunnel wird geplant neu aufgebaut!
2014.05.13-04:00:01 Tunnel wird neu aufgebaut!
2014.05.13-04:00:01 stoppe openvpn
2014.05.13-04:00:02 stoppe openvpn
2014.05.13-04:00:03 stoppe openvpn
2014.05.13-04:00:03 openvpn gestoppt
2014.05.13-04:00:06 starte openvpn
2014.05.13-04:00:06 openvpn gestartet
2014.05.13-04:00:06 warte auf tun0
2014.05.13-04:00:07 warte auf tun0
2014.05.13-04:00:08 warte auf tun0
2014.05.13-04:00:09 warte auf tun0
2014.05.13-04:00:10 warte auf tun0
2014.05.13-04:00:11 warte auf tun0
2014.05.13-04:00:12 warte auf tun0
2014.05.13-04:00:13 warte auf tun0
2014.05.13-04:00:14 warte auf tun0
2014.05.13-04:00:16 tun0 steht
2014.05.13-04:00:16 Tunnel wurde aufgebaut
2014.05.13-04:01:01 Tunnel nach NL steht!  extIP=109.201.143.237  FbIP=xxx.xxx.xxx.xxx

2014.05.13-06:14:06 Die Außenwelt ist nicht erreichbar!
2014.05.13-06:14:06 openvpn hoch:True defaultGW==tun0:True
2014.05.13-06:14:06 Wiederholung des Außenwelt-Erreichbarkeits-Tests
2014.05.13-06:14:24 Tunnel wird neu aufgebaut!
2014.05.13-06:14:24 stoppe openvpn
2014.05.13-06:14:25 stoppe openvpn
2014.05.13-06:14:26 stoppe openvpn
2014.05.13-06:14:27 stoppe openvpn
2014.05.13-06:14:27 openvpn gestoppt
2014.05.13-06:14:30 starte openvpn
2014.05.13-06:14:30 openvpn gestartet
2014.05.13-06:14:30 warte auf tun0
2014.05.13-06:14:31 warte auf tun0
2014.05.13-06:14:32 warte auf tun0
2014.05.13-06:14:33 warte auf tun0
2014.05.13-06:14:34 tun0 steht
2014.05.13-06:14:34 Tunnel wurde aufgebaut
2014.05.13-06:15:01 Tunnel nach NL steht!  extIP=83.149.126.130 
FbIP=xxx.xxx.xxx.xxx

2014.05.13-18:43:06 Externe IP konnte 2x in Folge nicht ermittelt werden!
2014.05.13-18:44:02 Externe IP konnte ermittelt werden!
2014.05.13-23:16:06 Externe IP konnte 2x in Folge nicht ermittelt werden!
2014.05.13-23:17:01 Externe IP konnte ermittelt werden!

2014.05.14-04:00:01 Der Tunnel wird geplant neu aufgebaut!
2014.05.14-04:00:01 Tunnel wird neu aufgebaut!
2014.05.14-04:00:01 stoppe openvpn
2014.05.14-04:00:02 stoppe openvpn
2014.05.14-04:00:03 stoppe openvpn
2014.05.14-04:00:03 openvpn gestoppt
2014.05.14-04:00:06 starte openvpn
2014.05.14-04:00:06 openvpn gestartet
2014.05.14-04:00:06 warte auf tun0
2014.05.14-04:00:07 warte auf tun0
2014.05.14-04:00:08 warte auf tun0
2014.05.14-04:00:09 warte auf tun0
2014.05.14-04:00:10 tun0 steht
2014.05.14-04:00:10 Tunnel wurde aufgebaut
2014.05.14-04:01:01 Tunnel nach NL steht!  extIP=83.149.126.141 
FbIP=xxx.xxx.xxx.xxx

Damit läuft mein (offenes) WLAN schon seit einigen Wochen stabil über einen Tunnel.


Erweiterung des Scripts zur Überwachung einer Transmission-VM

Weil Transmission besser läuft, wenn auf Hide.me "UPnP aktivieren" markiert ist, macht es durchaus Sinn, dafür einen eigenen Tunnel mit entprechendem Setting aufzubauen.

Die neuste Version des Scripts hat drei weitere Konfig-Variablen (und für mich den Vorteil, dass ich nur ein Script pflegen muss).
Mit der Änderung der Einstellung von
TRANSMISSION_MONITORING=True
kann das Script alternativ auch zur Überwachung einer Transmission-VM (auf der ebenfalls torrentcycle.py läuft) genutzt werden.
In diesem Fall sind die Variablen
PATH_TRANSMISSION="/usr/bin/transmission-daemon"
PATH_TORRENTCYCLE="/home/dede/bin/torrentcycle.py"

ggf. an die eigenen Bedürfnisse anzupassen.
Bei TRANSMISSION_MONITORING=True werden zusätzlich zur Tunnel-Aufrechterhaltungs-Überwachung die Dienste
    transmission-daemon  und
    torrentcycle.py
überwacht bzw. am Laufen gehalten.

Wer auch meinen Bandbreitenmonitor nutzt, kann mich gerne anschreiben, um eine Version 2.02 davon zu bekommen, die optional den Status von zwei Tunnel-VMs anzeigt.
Nur per Mail deswegen, weil das alles sehr speziell auf meine Bedürfnisse (und Rechner-Infrastruktur) hin ausgerichtet ist und es mir viel zu aufwendig wäre, das hier halbwegs allgemein verständlich zu dokumentieren.
Sieht dann z.B. so aus, wenn alles gut ist:
Screenshot bwm2

Wäre der Zeitpunkt der letzten erfolgreichen Tunnel-Überprüfung auf "btv" (meiner BitTorrent-VM) älter als 65 Sekunden, sähe es etwa so aus:
Screenshot bwm2 mit Tunnel-Problem

Und nun kann man sich auch denken, wozu die drei "nur zur Info"-Attribute in .tunnel_watchdog.conf gut sind. ;-)