-
-
Notifications
You must be signed in to change notification settings - Fork 39
Test Checkliste für Gateways
Voraussetzung für den Test ist eine isolierte Umgebung! D.h. es wird z.B. ein Router benötigt, der sich lediglich mit dem zu testenden Gateway verbindet. Darüber hinaus sind die verschiedenen Dienste nacheinander zu testen
ps ax | grep fastd läuft der Prozess
16113 ? S 580:47 /usr/bin/fastd --syslog-level info --config /etc/fastd/ffm-mesh-vpn/fastd.conf
cat /var/log/syslog | grep fastd startet der Server, wurden die Peers importiert und verbinden sich die Clients
Nov 5 10:58:50 v22014072295919498 fastd[28502]: fastd v14 starting
Nov 5 10:58:50 v22014072295919498 fastd[28502]: successfully bound to any:10000
Nov 5 10:58:50 v22014072295919498 fastd[28502]: initializing tun/tap device...
Nov 5 10:58:50 v22014072295919498 fastd[28502]: tun/tap device initialized.
Nov 5 10:58:50 v22014072295919498 fastd[28502]: dropped capabilities
Nov 5 10:58:50 v22014072295919498 fastd[28502]: found own key as `gw01', ignoring peer
Nov 5 10:58:50 v22014072295919498 fastd[28502]: adding peer <xyz> (group `default')
Nov 5 10:58:50 v22014072295919498 fastd[28502]: adding peer <ujhs> (group `default')
Nov 5 10:58:50 v22014072295919498 fastd[28502]: adding peer <lisdf> (group `default')
Nov 5 10:58:50 v22014072295919498 fastd[28502]: adding peer <sdfasd> (group `default')
Nov 5 10:58:50 v22014072295919498 fastd[28502]: adding peer <jrtz> (group `default')
Nov 5 10:58:50 v22014072295919498 fastd[28502]: adding peer <utzr> (group `default')
Nov 5 10:58:50 v22014072295919498 fastd[28502]: adding peer <frnk-test> (group `default')
.... (Beispiel für Peer Gateway gw04)
Nov 5 10:58:50 v22014072295919498 fastd[28502]: resetting socket for peer <gw04>
Nov 5 10:58:50 v22014072295919498 fastd[28502]: sending handshake to <gw04>[213.166.225.3:10000]...
Nov 5 10:58:50 v22014072295919498 fastd[28502]: received handshake response from <gw04>[213.166.225.3:10000] using fastd v14
Nov 5 10:58:50 v22014072295919498 fastd[28502]: finishing handshake with <gw04>[213.166.225.3:10000]...
Nov 5 10:58:50 v22014072295919498 fastd[28502]: 213.166.225.3:10000 authorized as <gw04>
Nov 5 10:58:50 v22014072295919498 fastd[28502]: connection with <gw04> established.
Nov 5 10:58:50 v22014072295919498 fastd[28502]: new session with <gw04> established using method `salsa2012+gmac'.
lsmod | grep batman prüfen, ob das Kernelmodul geladen ist
batman_adv 99838 0
batctl if prüfen, ob das richtige Interface benutzt wird (hier die Bridge br-ffm)
ffm-mesh-vpn: active
batctl gw prüfen, ob batman sich selbst als Server announced
server (announced bw: 96MBit/96MBit)
batctl gwl listet alle anderen batman-Gateways in Reichweite (3 Stück)
Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffm-mesh-vpn/10:80:00:11:66:66 (bat0)]
10:80:00:13:66:66 (255) 10:80:00:13:66:66 [ffm-mesh-vpn]: 41 - 2048KBit/512KBit
10:80:00:14:66:66 (255) 10:80:00:14:66:66 [ffm-mesh-vpn]: 215 - 96MBit/96MBit
batctl o listet alle ans batman-mesh-Netzwerk angeschlossenen Knoten auf
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffm-mesh-vpn/10:80:00:11:66:66 (bat0)]
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...
ea:98:f6:2a:d5:00 0.616s (159) ea:e2:27:58:8f:0e [ffm-mesh-vpn]: c2:4a:00:4b:5e:d6 (123)
....
ip nei sh dev br-ffm listet alle im batman-Netz verbundenen Router auf
fdef:ffc0:4fff:0:c64a:ff:fe05:75c1 lladdr c0:4a:00:05:7a:cc REACHABLE
fe80::eade:27ff:fe58:ad18 lladdr e8:de:47:58:3a:78 REACHABLE
fe80::c66e:1fff:fe3b:3c5a lladdr c4:6e:1f:3b:6c:5a STALE
fe80::12fe:edff:fec4:500a lladdr 10:ff:e1:c4:57:0f REACHABLE
ssh -6 -l root <<IP-Adresse>> Kann man sich zu einem Router verbinden?
ifconfig sind alle Interfaces online? Für ffmuc sind dies: bat0, br-ffm, ffm-mesh-vpn, icvpn und tun0
###DHCP-Server ps ax | grep dhcpd läuft der dhcp-Prozess? 2512 ? Ss 0:21 /usr/sbin/dhcpd -q -cf /etc/dhcp/dhcpd.conf -pf /var/run/dhcpd.pid br-ffm
cat /var/log/syslog | grep DHCPACK bekommen Clients ipv4-Adressen zugeteilt?
Nov 5 11:15:50 v22014072295919498 dhcpd: DHCPACK to 10.80.50.237 (74:e5:01:c7:21:c6) via br-ffm
Nov 5 11:16:08 v22014072295919498 dhcpd: DHCPACK on 10.80.50.114 to c0:4a:00:6c:f4:6a via br-ffm
###radvd ps ax | grep radvd läuft der radvd-Prozess? 2208 ? S 0:00 /usr/sbin/radvd -u radvd -p /var/run/radvd/radvd.pid
###DNS-Proxy ps ax | grep dnsmasq läuft das dnsmasquerading? 3401 ? S 2:22 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
###Uplink-Tunnel ps ax | grep openvpn läuft der openvpn-Prozess? 3223 ? Ss 61:45 /usr/sbin/openvpn --writepid /var/run/openvpn.mullvad.pid --daemon ovpn-mullvad --status /var/run/openvpn.mullvad.status 10 --cd /etc/openvpn --config /etc/openvpn/mullvad.conf
ping -I tun0 www.google.de lassen sich Ziele über den Uplink-Tunnel pingen?
PING www.google.de (173.194.32.255) from 10.8.0.86 tun0: 56(84) bytes of data.
64 bytes from ber01s09-in-f31.1e100.net (173.194.32.255): icmp_req=1 ttl=53 time=73.4 ms
traceroute -i tun0 www.google.de Traffic via Tunnel möglich?
traceroute to www.google.de (173.194.32.255), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 37.868 ms 37.504 ms 37.375 ms
2 mlm-sg-vrrp-vlan410.31173.se (193.138.219.225) 37.661 ms 37.649 ms 37.230 ms
3 mlm-sg-cr1-te-4-1.31173.se (193.138.216.173) 37.163 ms 37.117 ms 37.036 ms
.....
ifconfig tun0 Die Werte für RX- und TX-Bytes müssen mit der Zeit raufzählen
tcpdump -i tun0 fließen Datenpakete am Interface?
###Firewall iptables-save sind die beiden ffmuc-Regeln *nat und *mangle vorhanden? # Generated by iptables-save v1.4.14 on Wed Nov 5 11:21:21 2014 *nat :PREROUTING ACCEPT [4303626:289741337] :INPUT ACCEPT [3390449:225356531] :OUTPUT ACCEPT [434777:28644970] :POSTROUTING ACCEPT [434742:28648377] -A POSTROUTING -o tun0 -j MASQUERADE COMMIT # Completed on Wed Nov 5 11:21:21 2014 # Generated by iptables-save v1.4.14 on Wed Nov 5 11:21:21 2014 *mangle :PREROUTING ACCEPT [643008099:203250564721] :INPUT ACCEPT [560266067:136996249597] :FORWARD ACCEPT [82467621:66238435260] :OUTPUT ACCEPT [1035716602:190588958186] :POSTROUTING ACCEPT [1118182992:256827282020] -A PREROUTING -i br-ffm -j MARK --set-xmark 0x1/0xffffffff COMMIT # Completed on Wed Nov 5 11:21:22 2014 # Generated by iptables-save v1.4.14 on Wed Nov 5 11:21:22 2014 *filter :INPUT ACCEPT [45385548:7921798455] :FORWARD ACCEPT [3729654:2727788968] :OUTPUT ACCEPT [72130244:10644955392] COMMIT # Completed on Wed Nov 5 11:21:22 2014
###IP-Routen ip route show sind die Routen richtig gesetzt? default via 37.120.168.1 dev eth0 10.8.1.13 dev tun0 proto kernel scope link src 10.8.1.14 10.80.0.0/16 dev br-ffm proto kernel scope link src 10.80.0.11 10.207.0.0/16 dev icvpn proto kernel scope link src 10.207.0.80 37.120.168.0/22 dev eth0 proto kernel scope link src 37.120.168.150
ifconfig icvpn Interface icvpn online?
ping -I icvpn 10.207.0.5 lassen sich IC-VPN Ziele (hier Berlin1) pingen?
tcpdump -i icvpn fließen Datenpakete am Interface?
ps ax | grep quagga läuft BGP? (Prozesse: zebra, bgpd, watchquagga)
26179 ? Ss 0:12 /usr/lib/quagga/zebra --daemon -A 127.0.0.1
26183 ? Ss 2:23 /usr/lib/quagga/bgpd --daemon -A 127.0.0.1
26188 ? Ss 0:07 /usr/lib/quagga/watchquagga --daemon zebra bgpd
ping 10.80.0.11 VPN GW01 erreichbar
ping 10.80.0.12 VPN GW02 erreichbar
ping 10.80.0.13 VPN GW03 erreichbar
ping 10.80.0.14 VPN GW04 erreichbar
ping 10.80.0.15 SRV01 erreichbar
Zum weiteren Testen flasht man einen Freifunk-Router mit einer Spezial-Firmware, der sich ausschließlich zum zu testenden Gateway verbindet. Die hierzu notwendig Firmware liegt in einem separaten Verzeichnis auf dem Firmware-Server. Es ist dafür zu sorgen, dass keine anderen Verbindungen aufgebaut werden können - z.B. darf der Test-Router nicht mit anderen meshen!
Als nächsten Schritt verbindet man einen Client entweder per Kabel an den LAN-Port oder per WLAN an den Router. Der Client sollte jetzt eine IP-Adresse aus dem Bereich des DHCP-Servers bekommen, der auf dem zu testenden Gateway läuft. Der Client müsste jetzt im internet sein.