OpenVPN Server mit wechselnder IP Adresse

Hab vor kurzem eine OpenVPN Verbindung zu einem Server mit wechselnder IP Adresse eingerichtet.
„Eh alles ganz einfach“ möchte man vielleicht meinen.
„Wozu gibt es Services wie DynDNS, NoIP u.ä.“.

Tja.

Geben tuts die schon. Allerdings sind die „free“ Zugänge alles andere als zuverlässig.
Und noch dazu wird man mit unnötigen „Login Notifications“ belästigt.
(Meisst muss man sich mindestens 1x pro Monat einloggen, sonst wird der Hostname gelöscht)

Die Bezahl-Zugänge sind vermutlich zuverlässiger, allerdings :
Wer will schon ein paar Euro/Monat nur dafür zahlen, damit zwischen 2 Standorten eine Verbindung aufgebaut werden kann ?!?
(Wenn es ein TopLevelDomain-DynDNS ist, auf welchem man Websites hostet, dann siehts nat. anders aus…)

Drum hab ich mir gedacht, da muss man ja auch selber was stricken können. Kann man…

Als erstes benötigt man dafür natürlich einen Webspace, der sehr zuverlässig funktioniert.
Da drauf kommen 2 php Scripts :
eintragen.php

<?php
 $ip=$_SERVER['REMOTE_ADDR'];
 $f=fopen("/tmp/ipvonwoswoasiwem.txt","w") or die("Unable to open file!");
 fwrite($f,$ip."\n");
 fclose($f);
?>

auslesen.php

<?php
 $f=fopen("/tmp/ipvonwoswoasiwem.txt","r") or die("Unable to open file!");
 $ip=fread($f,50);
 echo $ip;
 fclose($f);
?>

Damit ist schon mal die Möglichkeit geschaffen, dass der VPN-Server seine IP „bekannt“ machen kann, und der Client kann sie abholen.

Der Server muss, sobald er feststellt, dass sich seine IP geändert hat nur noch z.B. ein wget machen, das könnte etwa so aussehen :

wget -O- http://example.com/optionalesverzeichnisdamitsniemandsoleichtmanipulierenkann/eintragen.php

Damit der Server nicht unnötigerweise z.B. jede Minute bei einem exterenen Dienstleister (z.B. whatsmyip.com) nachfragen muss, kann man dazu auch ganz einfach abfragen, ob noch irgendein VPN Client eingewählt ist. (geht viel schneller, und verursacht keinen extra Internet-Traffic).

Soweit die Server-Seite. (der OpenVPN Server muss halt dort noch eingerichtet werden…)

Jetzt gehts weiter mit der Client Seite. Da wirds richtig „tricky“.

Das Problematische daran ist, dass es die OpenVPN Binary IMMER als „Service“ läuft. D.h. egal, ob Server oder Client, einmal gestartet, verbindet er sich mit der angegebenen Adresse (IP oder Hostname). Bricht die Verbindung ab, versucht er die gleiche Verbindung wieder aufzubauen. Ändert sich die öffentliche IP auf der Client-Seite, ist das überhaupt kein Problem; die Verbindung steht ca. 1-2 Sekunden nach der Internet Verbindung wieder. Ändert sich allerdings die IP auf der Server-Seite, dann wirds problematisch. Wie soll man das feststellen, ohne DynDNS zu verwenden ? Es gibt zwar „Hooks“, die etwas triggern können, allerdings einen „Error-Hook“ hab ich bisher noch nicht gefunden.

Also doch wieder DynDNS. Aber anders. Bei mir ist der OpenVPN Client ein Raspberry PI, der Internet-Router läuft auf OpenWRT. Damit kann man schon was anstellen. Aber es gibt – wie immer – mehrere Möglichkeiten :

*) die /etc/hosts Datei ändern

Das ist unpraktisch, kompliziert, und (weil man die Datei nicht so einfach auf die RAMDisk bekommt) führt möglicherweise auch zu Problemen beim Booten. Da sind Einträge drin, die u.U. für einen erfolgreichen Boot vermutlich notwendig sind (sowohl beim PI, als auch beim Router)

*) die /etc/dnsmasq.conf ändern

Das ist auch nicht viel besser. u.U. hat man da drin z.B. Werbeblocker u.a. drinnen.

*) DAS IST ES :

Es gibt in der /etc/dnsmasq.conf einmal die Möglichkeit, zusätzliche Config-Dateien einzubinden (mit conf-file=…) und dann aber noch die Option eine „künstliche“ hosts Datei zu verwenden. Der Eintrag dazu lautet :

addn-hosts=/tmp/dynhosts

Den einfach ganz am Ende einfügen; dann erhält man das gewünschte Ergebnis; dnsmasq kann AUCH OHNE diese Datei (z.B. beim Booten) hochfahren; die Datei kann man nach belieben unendlich oft wiederbeschreiben (weil sie in der RamDisk liegt).

Ein „Problemchen“ bleibt noch : im Gegensatz zur „echten“ hosts Datei werden die Änderungen nicht „on-the-fly“ übernommen. Aber auch dafür gibt es eine ganz simple Lösung : man sendet ein „kill -1“ (=sighup), dann lädt dnsmasq seine Config neu, ohne irgendeine sonstige Unterbrechung. Das Kommando dazu lautet :

kill -1 $(cat /var/run/dnsmasq/dnsmasq.pid)

Bzw. das komplette Script namens dyndns.sh :

#!/bin/sh
dyn=/tmp/dynhosts
soll=$(wget -O- -T 5 http://example.com//optionalesverzeichnisdamitsniemandsoleichtmanipulierenkann/auslesen.php 2>/dev/null)
if test "$soll" == ""
then
 soll=$(wget -O- -T 5 http://example_redundant.com//optionalesverzeichnisdamitsniemandsoleichtmanipulierenkann/auslesen.php 2>/dev/null)
fi
if test "$soll" != ""
then
 ist=$(cat $dyn 2>/dev/null | cut -d" " -f1)
 if test "$soll" != "$ist"
 then
  echo "Ziel IP alt = $ist, update auf $soll" >> /tmp/meineigenesdyndns.log
  echo "$soll zielserver" > $dyn
  kill -1 $(cat /var/run/dnsmasq/dnsmasq.pid)
 fi
fi

Ich hab auch gleich noch einen 2. Webspace (der die gleiche Information bereithält) eingebaut, somit ergibt sich sogar eine gewisse Redundanz, falls mal was nicht geht.

Wenn man das script (auf seinem Hauptrouter) aufruft, und dann z.B. ein „ping zielserver“ eingibt, dann sollte (zumindest versucht) werden, die entsprechende Gegenstelle anzupingen.

Aufgerufen wird das Script (bei mir) 1x pro Stunde, und, sobald mein „dauerping“ Script feststellt, dass zwar das Internet geht, aber die VPN Verbindung nicht.

Somit gibt es kaum extra Internetverkehr, aber die Verbindung sollte trotzdem in <1min wieder da sein, falls sich die Server-IP geändert hat.

Damit kann die „Domain“ auch problemlos in einer OpenVPN Konfigurationsdatei verwendet werden…. (Sogar auf einem Raspberry PI „hinter“ dem Router)

Update :
Was mir noch so aufgefallen ist : wenn statt zielserver ein Name mit Punkt verwendet werden soll, dann gibts zumindest mit .local Probleme.
D.h. zielserver.local -> geht nicht
zielserver.lo -> geht

WLAN Tunings

So manch einer fragt sich sicher :“Warum ist die Banane krumm ?!?“.
Aber darum geht es hier nicht. 🙂
Es soll allerdings die Frage beantwortet werden : „Warum ist mein WLAN so langsam…. ?!?“

Tja, dafuer gibt es viele Gruende….

1. Ein Kabel ist ein kabel.
Wenn es geht, ist natuerlich immer ein Kabel vorzuziehen. Aber in der heutigen Zeit sitzt ja keiner mehr
vor einem PC. Und ein Haendy oder ein Tablet hat halt kaum einen LAN Anschluss; fuer Laptops ist es auch eher unpraktisch.
2. Interferrenzen
Mein Nachbar betreibt ein WLAN auf Kanal 1.
Um keine gegenseitgen Stoerungen zu verursachen, verwende ich, schlau, wie ich bin -> Kanal 2.
-> Super Idee !!!
Nur: leider komplett falsch !
WLAN Kanaele sind mind. 20MHz breit, die einzelnen Kanaele sind aber nur 5MHz auseinander !!!
(Kanal = jeweils die Mitten-Frequenz, +- 10 MHz werden benötigt, beim nächsten AP ist natürlich das gleiche notwendig)
-> Um das WLAN Spektrum im 2,4 GHz Spektrum bestmoeglich auszunutzen, duerfen NUR FOLGENDE KANAELE benutzt werden :
1,5,9,13(*)
Allerdings kommt es noch viiiiel schlimmer :
Soll z.B. ein „300MHz“ WLAN Router verwendet werden, dann benoetigt man (weil man 40 MHz Bandbreite braucht)
natuerlich UNBEDINGT 2 solcher Kanaele.
D.h. es darf dann nur mehr :
1 und 9
verwendet werden !!!!
Hat man einen Nachbarn, der z.B. auf Kanal 6,7 oder 8 sendet, dann hat man verloren. -> max die Haelfte moeglich, weil keine 40 MHz durchgehend vorhanden sind !!!

3. Klingt alles voll super. Ich habe mehrere Accesspoints auf Kanal 1,6,11 laufen. Ist das falsch ?
Falsch ist es nicht.
Aber es nutzt halt nicht alle in Europa verfuegbaren Kanaele aus.
(In Amerika ist nur 1-11 erlaubt, in Europa 1-13)
Das bringt aber unweigerlich das Problem zum Vorschein, dass es in Amerika nur 1(!) Kanal im 2,4 GHz Bereich gibt,
der 40MHz Bandbreite bringt.

Das Schema „1-6-11“ war allerdings frueher auch in Europa ueblich.
Der Grund dafuer ist – ganz einfach – die höhere damals noetige Bandbreie im „alten“ 802.11b (=“11MBit WLAN“).
Die war naemlich 22MHz statt 20MHz.
Dabei galt allerdings das gleiche : Kanal 12,13 war damals nutzlos.

Sind Geraete im Einsatz, die nur fuer den amerikanischen Markt bestimmt sind, dann ist das Kanalschema
„1-6-11“ keine schlechte Option; die Nachbarn wirds aber sicher nicht freuen !!
-> besser auf 1-5-9(-13) bzw. noch besser : NUR 1 oder 9 einstellen !!!

Raspberry PI Basics

Muss man einen Raspberry PI neu aufsetzen, dann stellen sich sofort immer wieder ein paar grundlegende Fragen.
z.B.: „Brauch ich Monitor, Maus, etc. dafuer ?“

Antwort :
Nein. Braucht man nicht. Zumindest nicht ab Raspbian Jessie. (Bei Wheezy gehts braucht man Tastatur&Bildschirm !!) Es ist allerdings ein DHCP Server („Router“) notwendig, mit dem
man moeglichst einfach die IP des PIs herausfinden kann.

-> z.B. mit Win32DiskImager ein frisches Image auf die SD/microSD Karte schreiben, den PI mit
der Karte ans LAN+Strom anschliessen, und etwas warten.

Dann kann man sich per SSH (mit der IP, die man aus dem Router herausfinden muss) einloggen.
Username : pi
Passwort : raspberry

Als erstes mit „passwd“ gleich mal ein Passwort fuer den „pi“-User setzen.
Mit „sudo -i“ wechselt man zum Root-User. Beim ersten Mal wird gleich „rapsi-config“ aufgerufen.
Damit kann man so grundlegende Dinge machen, wie z.B. Dateisystem vergroessern, Hostname setzen, etc…
(Zumindest dann,) wenn das Dateisystem vergroesser werden soll, ist ein erstmaliger Reboot notwendig.

Um was vernuenftiges machen zu koennen, emfiehlt nach dem ersten reboot folgendes :

apt-get update
apt-get upgrade -y
apt-get install vim screen tightvncserver mc -y

Ist man sich nicht sicher, ob man vom DHCP jedes mal die gleiche IP bekommen wird (nachdem die lease-time abgelaufen ist),
dann sollte auf jeden Fall eine fixe IP eingestellt werden. (Ausserhalb des DHCP IP Ranges, ebenfalls im Router nachzuschaun) :
vi /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
#pre-up iptables-restore > /etc/resolv.conf
echo „nameserver 8.8.4.4“ >> /etc/resolv.conf
Das mit den Name-Servern ist aber leider nicht Reboot-Resisdent.
-> Am besten in die /etc/rc.local vor dem „exit 0“ einbauen.

Damit werden die am haeufigsten beschriebenen Verzeichnisse in eine RAMDisk gelegt :
echo „tmpfs /tmp tmpfs defaults,noatime,nosuid,size=100m 0 0“ >> /etc/fstab
echo „tmpfs /var/tmp tmpfs defaults,noatime,nosuid,size=30m 0 0“ >> /etc/fstab
echo „tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=100m 0 0“ >> /etc/fstab
echo „tmpfs /var/run tmpfs defaults,noatime,nosuid,mode=0755,size=2m 0 0“ >> /etc/fstab

Das hat nicht nur den Vorteil, dass die SD Karte kaum mehr verschleissen wird; ausserdem wird der PI
dadurch recht unempfindlich gegen Stromausfaelle, da ja kaum mehr Dateien schreibend geoeffnet sind.
(zumindes nicht auf der Karte). Log-Files sind halt dann weg… (!auch bei einem ordnungsgemaessen reboot!)

Anm.: hat man das gemacht, kommt es bei einigen Diensten zu Problemen.
z.B. apache startet nach einem reboot nicht mehr (obwohl man es ordnungsgemaess installiert hat, und es vor
dem Reboot auch problemlos funktioniert hat).
Der Grund dafuer ist ganz einfach :
Das Verzeichnis /var/log/apache2 wird bei der installation angelegt, aber NICHT bei einem Reboot.
Abhilfe :
vi /etc/init.d/apache2
/start)
und direkt danach :
mkdir -p /var/log/apache2

Dann kann man – ganz einfach – mit :
„service apache2 start“

testen, ob es wieder klappt.

Update !!!!!!

Beim Raspbian Jessie sind per default schon einige Verzeichnisse als RAMDisk gemountet.
Da darf nur mehr /var/log und /tmp in die fstab eingetragen werden !!!
Das ist natuerlich z.B. bei einem Upgrade unbedingt zu beachten !!

Random Number Generator

modprobe bcm2708-rng
echo „bcm2708-rng“ >> /etc/modules

ssh mit ROOT
Es ist zwar ein tolles Feature, dass man sich als „root“ per ssh nicht einloggen kann,
sondern erst nach dem Login z.B. via „sudo -i“ den user wechselt, allerdings hat das
(solange der PI sowieso nicht via oeffentlicher IP aus dem Inernet erreichbar ist)
und natuerlich, solange man den „pi“ – user weiterverwendet keinerlei Sicherheitsvorteile.
Das Schaltet man ab mit:

In der /etc/ssh/sshd_config

PermitRootLogin without-password
Aendern in :
PermitRootLogin yes

service ssh restart

ssh ohne DNS
Dauert es recht lange (ca. 5 Sekunden) zwischen Username und Passwort Abfrage beim Login via ssh,
dann liegt es meisst an einem DNS-Feature.
Um das abzustellen :

echo „UseDNS no“ >> /etc/ssh/sshd_config
service ssh restart

PI Nachteile :

*) Fehlende Echtzeit Uhr (da gaebe es allerdings was zum Basteln… evtl. auch mit DCF77 ?!?)
*) Fehlende SATA Anschluesse
*) LAN nur 100MBit (und intern nur via USB angeschlossen) -> hohe CPU Last !!
*) Stromversorgung via Micro-USB Netzteil (damit sind die 4 USB Anschluesse des B+ und B2 nur recht eingeschraenkt nutzbar)
*) KEIN GBitLAN/KEIN USB3 !!
*) MicroSD (geht aber trotzdem recht zuverlaessig) besser waere aber sicher ein int. 4 oder 8 GB Flash
oder alternativ : 2 Einschuebe, mit denen man ein RAID machen kann !!!
*) „Bootloader“ auf einer FAT (!!!!) Partition -> ging zumindest zu Anfangszeiten schon mal „kaputt“ !!
ist DAS im Jahre 2015 notwendig ?!?

Am Raspberry PI eine USB Webcam betreiben

Dafuer gibt es unzaehlige Anleitungen im Internet. Die meissten davon funktionieren
aber nicht, oder nicht ordentlich.

Grundsaetzlich gibt es 2 vielversprechende Programme dafuer :

motion -> braucht aber recht viel CPU (kann theoretisch auch mehr; z.B. aufzeichnen, sobald sich was bewegt…)
mjpegstreamer -> besser aber nur mit Tricks optimal :

Wenn man den einfach so kompiliert, dann funktioniert die „mjpeg“ Option nicht.
Die Webcam geht nur mit dem „-y“ Parameter; sie liefert dann „raw“ – Bilder
an die CPU und die CPU muss daraus den Mpeg Stream erzeugen.
Beim PI2 mit seinen 4 Kernen ist das zwar nicht schlimm, aber schoen ist es auch nicht.
(1 Kern zu 100% ausgelastet)
Beim PI1 ist das natuerlich voelliger Non-Sense. In diesem Fall waere der PI natuerlich fuer andere Einsatzzwecke
kaum mehr zu gebrauchen.

Nach einiger Recherche hab ich dafuer aber einen Patch gefunden unter :
https://www.raspberrypi.org/forums/viewtopic.php?t=97983

Damit klappts dann auch ohne „-y“; die Kamera liefert dann direkt komprimierte Bilder zur CPU.
-> CPU Last = 1% beim PI1; 0,3% beim PI2

Allerdings es es halt doch einiges an Aufwand, alles korrekt zusammenzusuchen, zu patchen etc.

Drum hab ich mein gepatchtes Build-Verzeichnis mal gepackt, und hier nochmal hochgeladen.
Dann gehts einfacher :

apt-get update
apt-get install libjpeg8-dev imagemagick libv4l-dev
ln -s /usr/include/linux/videodev2.h /usr/include/linux/videodev.h
mkdir -p /install
cd /install
wget http://downloads.walterschlag.net/mjpg-streamer.tgz
tar xfz mjpg-streamer.tgz
cd mjpg-streamer
make clean # Fuer den Fall, dass schon mal kompiliert wurde …
make

In der Datei „start.sh“ finden sich nun einige Beispiele, wie der Streamer zu starten ist.
Mein Start Script sieht so aus :

#!/bin/sh
cd /install/mjpg-streamer
export LD_LIBRARY_PATH=“/install/mjpg-streamer“
./mjpg_streamer -i „input_uvc.so -d /dev/video0 -r 1280×960 -f 5“ –output „output_http.so -c BENUTZERNAME:PASSWORT -w www/“ &

Und wird – ganz einfach – ueber die /etc/rc.local mitgestartet …

Seagate Goflex serielle Verbindung

So schön und toll wie embedded Linux Systeme auch immer sind, hin und wieder ist halt leider doch eine serielle Konsole notwendig.
Vorallem z.B. dann, wenn man so ein System auf ein neues kopiert.
Dann ist man froh, wenn z.B. aus China ein USB-Serial adapter mit 3,3V TTL Signalen bereit liegt :

image

image

image

In meinem Fall hab ich damit herausgefunden, dass sich der Name der Netzwerkschnittstelle geändert hat.
eth0 -> eth1
Dadurch war das Gerät natürlich nicht mehr erreichbar…