[Berlin-wireless] Hilfe benötigt: Probleme mit VPN und olsr
Lutz Willek
lutz.willek
Mi Jan 1 16:40:11 CET 2014
Hallo zusammen,
und allen ein schönes neues Jahr. Ich hatte die Tage etwas Zeit mich mit
wieder Freifunk zu beschäftigen, beschlossen das seit Oktober laufende
Setup freifunk+vpn03 auf freifunk+vpn03+bbb_vpn zu erweitern. Das klappt
nicht so recht, ich habe jetzt Probleme mit dem Router, komme alleine
nicht weiter und brauche Hilfe.
Längere Vorrede: Das habe ich gemacht:
Den bisherigen Spielrouter eingemottet, also keine doppelten IP's,
Zertifikate o.ä. Probleme.
Neuen Router besorgt:
> root at schwartzkopff:~# cat /tmp/sysinfo/board_name
> tl-wr1043nd
Freifunk nach Anleitung (http://wiki.freifunk.net/Vpn03) eingerichtet:
> ATTITUDE ADJUSTMENT (berlin-2, r39154)
> timestamp: 2013-12-24_00-06 url: http://firmware.berlin.freifunk.net/attitude_adjustment/12.09/ar71xx host: firmware
Das VPN für vpn03 mit der "RAM-Disk-Startscript", Methode eingerichtet.
Läuft. (Vorheriger Zustand mit neuem Router wieder erreicht)
Danach eine statische Route für das 2. (bbb) vpn eingerichtet:
> root at schwartzkopff:~# grep -A4 route /etc/config/network
> config route
> option interface 'wan'
> option target '77.87.48.7'
> option netmask '255.255.255.255'
> option gateway '192.168.2.1'
Unter http://bbb-vpn.berlin.freifunk.net einen Key erstellen lassen, das
tar per Mail bekommen, unter /etc/ tar-Archiv nach /etc/openvpn entpackt
und leicht angepasst (kein ipv6):
> root at schwartzkopff:~# ls /etc/openvpn/*conf
> /etc/openvpn/freifunk-bbb-via-ipv4.conf /etc/openvpn/freifunk_lutz-mitte-udp.conf
Ein Interface tap0 konfiguriert:
> root at schwartzkopff:~# grep -A1 tap /etc/config/network
> config interface 'tap0'
> option proto 'none'
> option ifname 'tap0'
>
Das tap0 in die Firewallzone "freifunk" gelegt (iptables ok) und den
Router neu gestartet. Oh Wunder: Alles tut! Toll.
Problem 1:
Nach einer gewissen Zeit steigt (max. 1 Tag) steigt vpn03 komplett aus,
es funktioniert nicht mehr und kommt auch nicht mehr von selbst wieder:
> Jan 1 14:56:08 schwartzkopff daemon.notice openvpn[18997]: [UNDEF] Inactivity timeout (--ping-restart), restarting
> Jan 1 14:56:08 schwartzkopff daemon.notice openvpn[18997]: SIGUSR1[soft,ping-restart] received, process restarting
> Jan 1 14:56:10 schwartzkopff daemon.warn openvpn[18997]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
> Jan 1 14:56:10 schwartzkopff daemon.notice openvpn[18997]: UDPv4 link local: [undef]
> Jan 1 14:56:10 schwartzkopff daemon.notice openvpn[18997]: UDPv4 link remote: [AF_INET]77.87.48.10:1194
> Jan 1 14:56:10 schwartzkopff daemon.err openvpn[18997]: write UDPv4: Operation not permitted (code=1)
> Jan 1 14:56:13 schwartzkopff daemon.err openvpn[18997]: write UDPv4: Operation not permitted (code=1)
> Jan 1 14:56:17 schwartzkopff daemon.err openvpn[18997]: write UDPv4: Operation not permitted (code=1)
> Jan 1 14:56:26 schwartzkopff daemon.err openvpn[18997]: write UDPv4: Operation not permitted (code=1)
> Jan 1 14:56:43 schwartzkopff daemon.err openvpn[18997]: write UDPv4: Operation not permitted (code=1)
> Jan 1 14:57:10 schwartzkopff daemon.notice openvpn[18997]: [UNDEF] Inactivity timeout (--ping-restart), restarting
> Jan 1 [...]
Die Logeinträge gehen dann immer so weiter.
Das zweite (bbb-VPN) funktioniert zu dem Zeitpunkt stabil:
> root at schwartzkopff:~# ping -c4 104.0.6.1
> PING 104.0.6.1 (104.0.6.1): 56 data bytes
> 64 bytes from 104.0.6.1: seq=0 ttl=64 time=19.680 ms
> 64 bytes from 104.0.6.1: seq=1 ttl=64 time=19.517 ms
> 64 bytes from 104.0.6.1: seq=2 ttl=64 time=21.463 ms
> 64 bytes from 104.0.6.1: seq=3 ttl=64 time=19.543 ms
>
> --- 104.0.6.1 ping statistics ---
> 4 packets transmitted, 4 packets received, 0% packet loss
> round-trip min/avg/max = 19.517/20.050/21.463 ms
Die wichtigen Routen sehen zu dem Zeitpunkt so aus:
> root at schwartzkopff:~# ip r |grep -v 'via 104.0.6.1 dev tap0'
> 0.0.0.0/1 via 172.31.240.1 dev vpn03
> default via 192.168.2.1 dev eth0.2 proto static
> 77.87.48.7 via 192.168.2.1 dev eth0.2 proto static
> 104.0.0.0/8 dev wlan0-1 proto kernel scope link src 104.68.0.30
> 104.0.6.0/24 dev tap0 proto kernel scope link src 104.0.6.36
> 104.68.0.128/28 dev wlan0 proto kernel scope link src 104.68.0.129
> 128.0.0.0/1 via 172.31.240.1 dev vpn03
> 172.31.240.0/20 dev vpn03 proto kernel scope link src 172.31.240.46
> 192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
> 192.168.2.0/24 dev eth0.2 proto kernel scope link src 192.168.2.55
(Einige Routen sind hier wegen der besseren Übersicht ausgeblendet)
> root at schwartzkopff:~# ip r |grep 'via 104.0.6.1' |wc -l
> 347
Der VPN-Deamon selbst läuft für beide konfigurierten VPN:
> 18991 root 1896 S /tmp/vpn03/sbin/openvpn --cd /etc/openvpn --config /
> 18997 root 1980 S /tmp/vpn03/sbin/openvpn --cd /etc/openvpn --config /
lässt sich aber nicht stoppen, also das folgende funktioniert nicht:
> root at schwartzkopff:~# /etc/init.d/vpn03 stop
Das hier schon: :)
> root at schwartzkopff:~# killall openvpn
Starte ich (/etc/init.d/vpn03 start) das VPN nachdem ich es von Hand
gekillt habe, dann funktioniert alles wieder wie es soll.
Die Routen sehen dann so aus:
> root at schwartzkopff:~# ip r |grep -v 'via 104.0.6.1'
> 0.0.0.0/1 via 172.31.240.1 dev vpn03
> default via 192.168.2.1 dev eth0.2 proto static
> 77.87.48.7 via 192.168.2.1 dev eth0.2 proto static
> 77.87.48.10 via 192.168.2.1 dev eth0.2
> 104.0.0.0/8 dev wlan0-1 proto kernel scope link src 104.68.0.30
> 104.0.6.0/24 dev tap0 proto kernel scope link src 104.0.6.36
> 104.68.0.128/28 dev wlan0 proto kernel scope link src 104.68.0.129
> 128.0.0.0/1 via 172.31.240.1 dev vpn03
> 172.31.240.0/20 dev vpn03 proto kernel scope link src 172.31.240.46
> 192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
> 192.168.2.0/24 dev eth0.2 proto kernel scope link src 192.168.2.55
> root at schwartzkopff:~#
Man beachte hier die neu hinzugekommene Route zur IP 77.87.48.10, das
ist der vpn03.berlin.freifunk.net: Klar, dass vpn03 jetzt funktioniert,
jetzt ist ja auch eine vernünftige Route da.
Meine Vermutung: Bei der täglichen Zwangstrennung kakkt das VPN kurz ab,
beim Versuch des Neustarts wird die Route aus irgend einem Grund nicht
gesetzt. Keine Ahnung ob das wirklich so stimmt, wahrscheinlich schon.
Was mir nicht klar ist, und da brauche ich Eure Hilfe, wer oder was
diese Route genau setzt wenn ich das VPN starte: Es wäre super nett wenn
mir das jemand erklären könnte. Dann komme ich auch sicher dahinter,
warum die Route nicht mehr korrekt gesetzt wird, wenn das VPN
zwischendurch wegbricht.
Mein zweites Problem:
...ist das meiner Meinung nach nicht korrekt eingerichtete olsr: Da habe
ich aber schlicht zu wenig Wissen um das wirklich zu beurteilen.
Was habe ich gemacht? Nicht viel: Nachdem das bbb-vpn funktionierte habe
ich das Interface tun0 in die olsrd Konfiguration aufgenommen:
> /etc/config/olsrd
> config Interface
> option interface 'tap0'
und den Deamon neu gestartet. Ich sehe neu hinzugekommene Routen und
kann beispielsweise die IP's hinter diesen Routen pingen, sehe mich dann
auch auf der Karte unter http://berlin.freifunk.net/network/map/
(cool!). Ich sehe unter
http://104.68.0.129/cgi-bin/luci/freifunk/olsr/neighbors den "bbb-vpn"
als Nachbar (das ist die 104.0.6.1).
Jedoch auch, dass etwas mit dieser Verbindung nicht stimmt:(?)
> Nachbar-IP Hostname Schnittstelle Lokale Interface-IP LQ NLQ ETX SNR
> 104.0.6.1 ? undefined 104.0.6.36 1.000 0.246 4.047 ?
Kann mir Bitte jemand erklären, warum da unter "ETX" nicht eine glatte
"1" steht? Optimalerweise auch, wie ich dort eine "1" konfigurieren kann?
Danke für Eure Hilfe!
lg Lutz
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : smime.p7s
Dateityp : application/pkcs7-signature
Dateigröße : 4252 bytes
Beschreibung: S/MIME Cryptographic Signature
URL : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140101/35873c2f/attachment.bin>
Mehr Informationen über die Mailingliste Berlin