[Berlin-wireless] Hilfe benötigt: Probleme mit VPN und olsr
Lutz Willek
lutz.willek
Sa Jan 18 10:05:28 CET 2014
Moin,
ich habe auf die Mail unten leider keine Antwort bekommen daher "uppe"
ich das mal :)
Kurz gefasst: Bei gleichzeitig bbb_vpn und vpn03 auf einem Router steigt
reproduzierbar vpn03 nach maximal einem Tag wegen fehlenden Routen zum
vpn-Server aus. Ich finde nicht wer oder was die Routen setzt/entfernt.
Wo kann ich suchen? Wenn jemand nachsehen will, der Router ist
"schwartzkopff", 104.0.6.36.
Außerdem habe ich das Gefühl, dass olsrd nicht so funktioniert wie es
soll, siehe http://104.0.6.36/cgi-bin/luci/freifunk/olsr/neighbors
lg Lutz
Am 01.01.2014 16:40, schrieb Lutz Willek:
> 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/20140118/4e4d6d06/attachment.bin>
Mehr Informationen über die Mailingliste Berlin