VPN zentral
![]() |
Dieser Artikel oder Abschnitt bedarf einer Überarbeitung.
* IP-schemaaenderung, Passwort, "device" beim Server |
Warum
- Damit alle DSLer einen zusaetzlichen (virtuellen Funk-)Nachbarn bekommen, wird
- ein VPN Router im Internet (=M18) aufgestellt.
- Strecken ueber viele Hops werden dann durch den Tunnel geleitet.
- der Ausdruck VPN - Virtuelles Privates Netzwerk - ist natuerlich etwas irrefuerend, weil der Tunnel nur ein bisschen "Privat" ist - ist schliesslich ein offenes Netzwerk
Veranschaulichung
Wie
- die Software der Wahl ist vtun
- unten beschriebene Funktion wird in die Firmware eingebaut und kann per "Mausklick" angeschaltet werden
Authenifizierung, Verschluesselung, Kompression
- es wird ein unauthentifizierter, unverschluesselter und unkomprimierter Tunnel gegraben
Argumente pro offener Tunnel
- das Netz ist sowieso unverschluesselt - wozu also Teilstrecken verschluesseln?
- wer am Netz teilnehmen moechte, kann das ohne aufwendigen Schluessel/Zertifikats-Austausch
- Prozessor-Kraft sparen
- echte Daten werden sowieso innerhalb des eingesetzten Protokolls Ende-zu-Ende verschluesselt, wozu also doppelt verschluesseln?
- keine falsche Sicherheit vortaeuschen, sicher ist nur Ende-zu-Ende Verschluesselung. Der eigene Nachbar hat ein viel groesseres Interesse am eigenen Surfverhalten, als mein Provider.
Argumente contra offener Tunnel
- wenn die technik das hergibt, tut es nicht weh das zu benutzen - keine faulheit
- datenpackete im internet werden von div. stellen geloggt, also sollen die verschlüsselte sachen loggen
- geloggt werden nur Verbindungsdaten und keine Rohdaten. Is spielt also dafuer keine Rolle ob die Daten verschluesselt sind. fries43 13:22, 1. Okt 2006 (CEST)
- das netz ist nicht mehr für sich genommen, man kann dran beteiligt sein (inet) ohne daran beteiligt zu sein
- das ist gewollte. Freifunk hat irrefuehrenderweise "funk" im Wort. Es geht aber um eine freie Infrastruktur. fries43 13:22, 1. Okt 2006 (CEST)
- argument, dass das netz ja frei sei, und deshalb auf verschlüsselung verzichtet werden kann, ist irreführend. imo ist es etwas anderes, ob der "Abhöhrer" sich in die nähe des WLANs gebegen muss, oder einfach beim provider loggen kann.
Teilnehmer
- ca. 10 Teilnehmer
- Linksys in der M18 als Server und alle DSLer als Clients
Datenverkehr
- alle Teilnehmer sprechen OLSR ueber den Tunnel
- jeder Client verursacht <2.5kb/s konstanten upload (nur OLSR, keine Nutzdaten) (140 Netzknoten)
- entspricht 200mb/Tag bzw. 6gig/monat
- bei 7 Clients fallen ca. 40 Kilobyte/Sekunde eingehend und nochmal genausoviel ausgehender Verkehr auf dem Server an
- Betrachtet wird nun der Serverupload, downstream ist nochmal genausoviel:
- das entspricht 1,65 GB/Tag bzw. 50 GB/Monat
- eine Anpassung des OLSR-Dienstes an die VPN-Traffic-Problematik erfolgt.
- das starke Trafficaufkommen haengt mit dem Fisheye-Routing zusammen,bei dem direkte Nachbarn haeufiger Daten austauschen als weiter entfernte.
Installation auf dem Router
- Installation mit: ipkg update; ipkg install vtund
- KonfigDatei ist dann /etc/vtund.conf
Konfiguration (Server)
- wird von diesem Skript erledigt
- Server steht in der M18 und ist ein normaler Linksys mit oeffentlicher IP-Adresse (http://141.54.160.25:8080)
- Freifunk-Server-IP ist die 10.63.254.254..253..252..251... auf dem VPN-Interface
- Aufruf mit: vtund -s , Konfigdatei /etc/vtund.conf (im Beispiel mit nur 2 Clients)
default { proto tcp; type ether; compress no; encrypt no; keepalive no; multi yes; stat no; } m18---rembrandtweg { passwd bla; device tap0; speed 0; up { program "ip addr add dev %% 10.63.254.254/16 brd 10.255.255.255; ip link set %% mtu 1500 up"; }; } m18---jakob2a { passwd bla; device tap1; speed 0; up { program "ip addr add dev %% 10.63.254.253/16 brd 10.255.255.255; ip link set %% mtu 1500 up"; }; }
- Konfigdatei /etc/local.olsrd.conf fuer das Interface tun0, die anderen werden entsprechend angehangen
Interface "tap0" "tap1" "tap2" "tap3" "tap4" "tap5" "tap6" "tap7" "tap8" { HelloInterval 5.0 HelloValidityTime 90.0 TcInterval 3.0 TcValidityTime 270.0 MidInterval 15.0 MidValidityTime 270.0 HnaInterval 15.0 HnaValidityTime 90.0 Ip4Broadcast 10.255.255.255 LinkQualityMult default 0.1 }
Konfiguration (Client)
- Client ist jeder UpLink ins Internet bzw. ein belieber PC mit Internetzugang
- Lokales Interface mit IP-Adresse belegen (Knotennummer vorher registrieren! -> "Router")
- In diesem Beispiel ist die KNOTENNUMMER die 244 - entsprechend ersetzen!
ip addr add dev eth0 104.63.244.1/28 broadcast 104.63.244.15 label eth0:0
- Programm vtun installieren
- Konfigdatei /etc/vtund.conf anpassen
- Aufruf mit: vtund verbindungsname 87.118.106.19
- Test: laesst sich die Gegenstelle pingen? (10.63.244.254)
- Test: was sagt ein tail -f /var/log/daemon.log ?
verbindungsname { passwd bla; type ether; persist yes; up { program "ip addr add dev %% 10.63.244.253/30 brd 10.63.244.255; ip link set %% mtu 1450 up"; }; }
- Programm olsrd von olsr.org muss installiert sein
- Konfigdatei /etc/local.olsrd.conf anpassen:
- dann olsrd starten
- nach wenigen Sekunden sollten sich routen aufbauen: ip route
DebugLevel 0 IpVersion 4 AllowNoInt yes Pollrate 0.1 TcRedundancy 2 MprCoverage 7 LinkQualityFishEye 1 LinkQualityWinSize 100 LinkQualityDijkstraLimit 0 5.0 LinkQualityLevel 2 UseHysteresis no Hna4 { 104.63.244.0 255.255.255.240 } IpcConnect { MaxConnections 1 Host 127.0.0.1 Net 104.63.244.0 255.255.255.240 } Interface "eth0" { HelloInterval 5.0 HelloValidityTime 90.0 TcInterval 3.0 TcValidityTime 270.0 MidInterval 15.0 MidValidityTime 270.0 HnaInterval 15.0 HnaValidityTime 90.0 } Interface "tap0" { HelloInterval 5.0 HelloValidityTime 90.0 TcInterval 3.0 TcValidityTime 270.0 MidInterval 15.0 MidValidityTime 270.0 HnaInterval 15.0 HnaValidityTime 90.0 Ip4Broadcast 10.63.244.254 }
Skript bzw. fertiges Programm
- nach /etc/init.d/S52.weimarnetz.vpn_starten kopieren...
#!/bin/sh # /etc/init.d/S52.weimarnetz.vpn $VER 0.2 - 2006okt1 - Bastian Bittorf # Verbinden von funkmaessig getrennten Wireless-Mesh-Wolken ueber ein VPN: # Dies ist ein speziell angepasstes Skript zum erstellen einer vtund-Konfiguration # und zum erstellen einer OLSR-Konfiguration mit passenden Interfacenamen. # Das Skript ist exakt das selbe auf Client und Server, es ist also kein manueller # Eingriff noetig. Es wird eine SternTopologie erzeugt mit einem Server mit # oeffentlicher IP-Adresse und den Clients hinter NAT-Gateways. # Es werden unauthentifizierten, unkomprimierte und unverschluesselte Tunnel erzeugt. # Variablendefinitionen THIS="$(nvram get wifi_ipaddr|cut -d'.' -f3)" OLSR="/etc/local.olsrd.conf"; VTUN="/etc/vtund.conf" VPN="10.63.254"; SRV="214"; CNT="-1"; SRVPUBLIC="141.54.160.25"; BC="10.255.255.255"; MTU=1500 # Liste aller teilnehmenden Clients (Netzknotennummern) LST="41 82 42 37 62 54 135 87 1" # Funktion um Netzknotennummer einem Ort zuzuweisen,fuer lesbare Konfig get_name() { case $1 in 135) echo "m18---schwansee69";; 42) echo "m18---frauentor3";; 41) echo "m18---rembrandtweg";; 82) echo "m18---jakob2a";; 37) echo "m18---wbode13";; 62) echo "m18---trierer65";; 54) echo "m18---kunstturm";; 87) echo "m18---weimarwest";; 1) echo "m18---liszt18a";; esac } # Funktion zum schreiben der OLSR-Konfigdaten write_olsr() { echo -e "\n{\nHelloInterval 5.0\nHelloValidityTime 90.0\nTcInterval 3.0\nTcValidityTime 270.0" echo -e "MidInterval 15.0\nMidValidityTime 270.0\nHnaInterval 15.0\nHnaValidityTime 90.0"; } # sicherheitshalber evtl. laufende Instanzen und/oder vorhandene Dateien loeschen test -e $OLSR && rm $OLSR; test -e $OLSR && rm $CFG killall vtund; killall -9 vtund # laeuft das skript auf dem Server oder auf einem Client? if [ "$THIS" = "$SRV" ] then echo >$VTUN "default { proto tcp; type ether; compress no; encrypt no; keepalive no; multi yes; stat no; }" for CLIENT in $LST;do let CNT+=1;OKTETT=$(( 254 - CNT )) echo >>$VTUN "$(get_name $CLIENT) { passwd bla; device tap$CNT; speed 0;" echo >>$VTUN " up { program \"ip addr add dev %% $VPN.$OKTETT/16 brd $BC; ip link set %% mtu $MTU up\"; }; }" IFLIST=$IFLIST" \"tap$CNT\"" done echo >>$OLSR -e "Interface$IFLIST$(write_olsr)\n\nIp4Broadcast $BC\nLinkQualityMult default 0.1\n}" vtund -s else # ok,skript laeuft auf einem Client, also passende Konfigs erzeugen CNT=0;for IP in $LST;do if [ "$IP" = "$THIS" ];then NUMMER=$CNT;fi;let CNT+=1;done echo >$VTUN "$(get_name $THIS) { passwd bla; type ether; persist yes;" echo >>$VTUN " up { program \"ip addr add dev %% $VPN.$THIS/16 brd $BC; ip link set %% mtu $MTU up\"; }; }" echo >>$OLSR -e "Interface \"tap0\"$(write_olsr)\n\nIp4Broadcast $BC\n}" vtund $(get_name $THIS) $SRVPUBLIC fi # komischerweise muss der tunnel geNATet werden, wird noch beobachtet... iptables -t nat -D POSTROUTING -o tap+ -j MASQUERADE iptables -t nat -I POSTROUTING -o tap+ -j MASQUERADE
Zukunft
Client-Konfiguration
- /etc/vtund.conf
kunstturm {passwd ff;type ether;persist yes;up{program "ip addr add dev %% 10.63.254.82/16 brd 10.255.255.255;ip link set %% mtu 1500 up";};}
- Kommentar: verbindungsname ("kunstturm") = hostname
- /etc/local.olsrd.conf
Interface "tap0" { HelloInterval 5.0 HelloValidityTime 90.0 TcInterval 3.0 TcValidityTime 270.0 MidInterval 15.0 MidValidityTime 270.0 HnaInterval 15.0 HnaValidityTime 90.0 Ip4Broadcast 10.255.255.255 }
Server-Konfiguration
- /etc/vtund.conf
kunstturm { passwd ff;up{program "ip addr add dev %% 10.63.254.245/16 brd 10.255.255.255; ip link set %% mtu 1500 up";};}
- /etc/local.olsrd.conf
Interface "tap0" "tap1" "tap2" "tap3" "tap4" "tap5" "tap6" "tap7" "tap8" "tap9" "tap10" "tap11" "tap12" "tap13" "tap14" "tap15" "tap16" "tap17" { HelloInterval 5.0 HelloValidityTime 90.0 TcInterval 3.0 TcValidityTime 270.0 MidInterval 15.0 MidValidityTime 270.0 HnaInterval 15.0 HnaValidityTime 90.0 Ip4Broadcast 10.255.255.255 LinkQualityMult default 0.1 }