Freifunk Neuling ersucht Hilfe für IC-VPN Anbindung des Gateways

Technik
1

Für Freifunk Hameln ist die Einrichtung unseres ersten Gateways nun so gut wie fertig, die passende GLUON Firmware läuft auch schon.
Dazu habe ich mich zum größten Teil an dieser Anleitung vom FFLippeorientiert, außerdem noch dem Wiki Eintrag zu Tinc, ICVPN(bird) und DNS(bind9)

Was funktioniert:

  • Clients bekommen Adressen (DHCP)
  • Clients können Namen auflösen (DNS), aber nur lokale(website.ffhm) und externe( google.de) keine der anderen Communitys( start.ffpb).
  • Clients kommen ins Internet( momentan noch direkt über Gateway, Exit-VPN kommt noch ganz zum Schluss)

Was nicht funktioniert:

  • Anbindung zum ICVPN bzw. Verbindung zu anderen Communities.

Ich vermute, dass bei mir mit den iptables irgendwo noch etwas nicht stimmt.
Diese ganzen Regelungen und routen die man da machen soll habe ich ehrlich gesagt noch nicht so ganz verstanden.

/var/log/syslog ist voll mit Fehlern wie

ffhm-gw01 bird: BGP: Unexpected connect from unknown address 10.207.0.17 (port 34231)
ffhm-gw01 bird: bird: darmstadt4: Invalid NEXT_HOP attribute in route 172.23.234.16/28
ffhm-gw01 bird: KRT: Received route 0.0.0.0/0 with strange next-hop 51.254.115.77

Ich hoffe Ihr könnt mir da villeicht weiterhelfen.
Hier noch ein paar Ausgaben von Befehlen, die vllt. relevant sein könnten.
Gebe euch sehr gerne noch mehr Info bei bedarf.

root@ffhm-gw01:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         51.254.112.1    0.0.0.0         UG    0      0        0 eth0
10.11.96.0      0.0.0.0         255.255.240.0   U     0      0        0 br-ffhm
10.207.0.0      0.0.0.0         255.255.0.0     U     0      0        0 icvpn
51.254.112.1    0.0.0.0         255.255.255.255 UH    0      0        0 eth0

root@ffhm-gw01:~# ip rule show
0:      from all lookup local
32765:  from all fwmark 0x1 lookup ffhm
32766:  from all lookup main
32767:  from all lookup default

root@ffhm-gw01:~# ifconfig
bat0      Link encap:Ethernet  HWaddr 66:b7:a7:62:83:f9
          inet6 addr: fe80::64b7:a7ff:fe62:83f9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1124 (1.1 KB)  TX bytes:3914 (3.9 KB)

br-ffhm   Link encap:Ethernet  HWaddr 66:b7:a7:62:83:f9
          inet addr:10.11.96.1  Bcast:10.11.111.255  Mask:255.255.240.0
          inet6 addr: fe80::3038:86ff:fec4:d94c/64 Scope:Link
          inet6 addr: fdc7:4c8d:b889:a272::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:704 (704.0 B)  TX bytes:3922 (3.9 KB)

eth0      Link encap:Ethernet  HWaddr fa:16:3e:4d:fc:4d
          inet addr:51.254.115.77  Bcast:51.254.115.77  Mask:255.255.255.255
          inet6 addr: fe80::f816:3eff:fe4d:fc4d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1689892 errors:0 dropped:0 overruns:0 frame:0
          TX packets:357893 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:213804179 (213.8 MB)  TX bytes:46776293 (46.7 MB)

ffhm-mesh Link encap:Ethernet  HWaddr 72:ca:ff:ee:ba:be
          inet6 addr: fe80::70ca:ffff:feee:babe/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1406  Metric:1
          RX packets:449 errors:0 dropped:0 overruns:0 frame:0
          TX packets:481 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:18580 (18.5 KB)  TX bytes:23365 (23.3 KB)

icvpn     Link encap:Ethernet  HWaddr b2:45:ea:b4:cb:2d
          inet addr:10.207.0.31  Bcast:10.207.255.255  Mask:255.255.0.0
          inet6 addr: fec0::a:cf:0:1f/96 Scope:Site
          inet6 addr: fe80::b045:eaff:feb4:cb2d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1664579 errors:0 dropped:48 overruns:0 frame:0
          TX packets:82881 errors:0 dropped:1011 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:102447294 (102.4 MB)  TX bytes:10204061 (10.2 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:10159 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10159 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1161166 (1.1 MB)  TX bytes:1161166 (1.1 MB)

root@ffhm-gw01:~# ip route show
default via 51.254.112.1 dev eth0
10.11.96.0/20 dev br-ffhm  proto kernel  scope link  src 10.11.96.1
10.207.0.0/16 dev icvpn  proto kernel  scope link  src 10.207.0.31
51.254.112.1 dev eth0  scope link

root@ffhm-gw01:~# ip route show table ffhm(42) | less
10.0.1.0/24 via 10.207.0.79 dev icvpn  proto bird  src 10.11.96.1
10.2.0.0/16 via 10.207.0.22 dev icvpn  proto bird  src 10.11.96.1
10.5.0.0/16 via 10.207.0.114 dev icvpn  proto bird  src 10.11.96.1
10.8.0.0/16 via 10.207.0.36 dev icvpn  proto bird  src 10.11.96.1
10.11.0.0/18 via 10.207.0.17 dev icvpn  proto bird  src 10.11.96.1
10.11.96.0/20 dev br-ffhm  scope link  src 10.11.96.1
... noch mehr proto bird Einträge
2

Ist die Frage noch aktuell?

3

Aber unbedingt!

Ich wäre extrem dankbar für jede Hilfe. Ich komm hier einfach nicht weiter.
Wie meine configs generell aussehen kann man an den oben gelisteten Links einsehen.
Für genaueres einfach nachfragen.

4

Zum einen schlage ich vor, daß Du auch in dem anderen Thread mitliest — und an der Stelle auch über die Verwendung von Verwaltungsscripten (puppet, ansible scheinen hier beliebt zu sein; ich bevorzuge puppet, da auch beruflich damit befaßt) nachdenkst.

Zum anderen:

root@gw05:~# ping -q -c 5 10.207.0.31
PING 10.207.0.31 (10.207.0.31) 56(84) bytes of data.

--- 10.207.0.31 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 18.483/19.050/19.998/0.530 ms

Deine ICVPN-Verbindung funktioniert, und nachdem ich einen lokalen Bug gefixt habe (Änderungen in von git gezogenen Verzeichnissen zu machen, ist keine gute Idee :-(), steht auch die BGP-Session:

root@gw05:~# birdc show proto | grep ffhmgw01
ffhmgw01 BGP      mesh     up     15:31:58    Established   
root@gw05:~# birdc show route protocol ffhmgw01 | wc -l
198

Auch auf den Gütersloher Systemen scheint BGP mindestens seit heute Mittag zu tun:

root@bgp1:~# birdc show proto | grep ffhmgw01
ffhmgw01 BGP      icvpn_ffgt up     11:39:00    Established

Allerdings klappt das Routing zurück von Euch wohl nicht; was sagt denn Deine Routingtabelle, wo 10.255.0.0/16 hingehen soll?

root@gw01:~# tcptraceroute -s 10.255.0.11 10.11.96.1
traceroute to 10.11.96.1 (10.11.96.1), 30 hops max, 60 byte packets
 1  bgp3-gw01.ospf.ffgt (10.255.145.18)  0.235 ms  0.221 ms  0.232 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  *^C

Und was sagt »ip rule show«? EDIT: gefindet oben; dann stattdessen bitte »iptables -L -n -v -t mangle« (und »iptables -L -n -t nat«, just in case). EDIT2: ggf. mal ein »ip rule add iif icvpn lookup ffhm« machen, das sorgt dafür, daß alles, was über das Interface icvpn reinkommt, über Table ffhm geroutet wird (ohne Markierung der Pakete). Analog macht das imho auch für br-ffhm Sinn …

5

Mangle

 root@ffhm-gw01:~# iptables -L -n -v -t mangle
 Chain PREROUTING (policy ACCEPT 19M packets, 2652M bytes)
 pkts bytes target     prot opt in     out     source               destination
 109K 7925K MARK       all  --  *      *       10.11.96.0/20        0.0.0.0/0            MARK set 0x1

Chain INPUT (policy ACCEPT 19M packets, 2400M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 223K packets, 251M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 19M packets, 2245M bytes)
 pkts bytes target     prot opt in     out     source               destination
 4292 4061K MARK       all  --  *      *       10.11.96.0/20        0.0.0.0/0            MARK set 0x1

Chain POSTROUTING (policy ACCEPT 19M packets, 2496M bytes)
 pkts bytes target     prot opt in     out     source               destination

Nat

root@ffhm-gw01:~# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

Und ip rule add iif icvpn lookup ffhm ist auch drin.

Hab’s nicht getestet, muss gerade leider los.
Update später oder morgen nochmal, ob es nun vllt schon geht.

6

Also, zu den 10er Adressen noch nicht:

Kreis GT:

root@bgp2:~# traceroute -s 10.255.144.2 10.11.97.1 
traceroute to 10.11.97.1 (10.11.97.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *^C

Müritz:

root@gw05:~# traceroute -s 10.169.1.1 10.11.97.1
traceroute to 10.11.97.1 (10.11.97.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *^C

Aber das Transitnetz routest Du immerhin richtig:

root@bgp2:~# traceroute -s 10.207.0.133 10.11.97.1 
traceroute to 10.11.97.1 (10.11.97.1), 30 hops max, 60 byte packets
 1  ffhmgw01.icvpn (10.207.0.31)  9.641 ms  9.700 ms  9.726 ms
 2  10.11.96.1 (10.11.96.1)  3009.150 ms !H  3009.853 ms !H  3009.860 ms !H

root@gw05:~# traceroute -s 10.207.0.138 10.11.97.1
traceroute to 10.11.97.1 (10.11.97.1), 30 hops max, 60 byte packets
 1  ffhmgw01.icvpn (10.207.0.31)  19.592 ms  20.012 ms  20.046 ms
 2  10.11.96.1 (10.11.96.1)  3018.819 ms !H  3019.068 ms !H  3019.095 ms !H

Klingt aber so, also ob die primäre Routingtabelle verwendet wird:

Mach’ mal spaßeshalber ein »ip route add 10.169.1.1 via 10.207.0.138« (also in der main-Table), dann sollte, wenn’s noch darüber geroutet wird, der ping, den ich z. Zt. vom Müritzer GW laufen lasse, beantwortet werden. Dann wäre »ip rule show« nochmal angezeigt, aber eigentlich sollte die iif-Regel nun auf 32764 liegen …

… hmm, und MASQUERADE würde ich auch nur für src=10.11.96.0/20 statt 0.0.0.0/0 machen, schon, damit man nicht Euch als Default-GW nutzen kann, was aktuell der Fall ist:

root@gw05:~# ip route add 137.39.1.3 via 10.207.0.31
root@gw05:~# traceroute -s 10.207.0.138 137.39.1.3
traceroute to 137.39.1.3 (137.39.1.3), 30 hops max, 60 byte packets
 1  ffhmgw01.icvpn (10.207.0.31)  19.732 ms  20.099 ms  20.109 ms
 2  51.254.112.1 (51.254.112.1)  20.150 ms  20.160 ms  20.170 ms
 3  222.ip-92-222-54.eu (92.222.54.222)  20.181 ms  20.178 ms  20.206 ms
18  ns.UU.NET (137.39.1.3)  121.945 ms  123.522 ms  123.367 ms
7

IP rules

root@ffhm-gw01:~# ip rule show
0:      from all lookup local
32763:  from all fwmark 0x1 lookup ffhm
32764:  from all iif icvpn lookup ffhm
32765:  from all fwmark 0x1 lookup ffhm
32766:  from all lookup main
32767:  from all lookup default

Masquerade nun richtig?

root@ffhm-gw01:~# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.11.96.0/20        0.0.0.0/0

Hier noch die manuelle route drin, ping schlägt leider fehl

root@ffhm-gw01:~# ip route show
default via 51.254.112.1 dev eth0
10.11.96.0/20 dev br-ffhm  proto kernel  scope link  src 10.11.96.1
10.169.1.1 via 10.207.0.138 dev icvpn
10.207.0.0/16 dev icvpn  proto kernel  scope link  src 10.207.0.31
51.254.112.1 dev eth0  scope link
root@ffhm-gw01:~# ping 10.169.1.1
PING 10.169.1.1 (10.169.1.1) 56(84) bytes of data.
^C
--- 10.169.1.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9070ms

Ist das den eigentlich richtig, dass bird die ganzen routen auf table ffhm(42) schmeißt?
Das hatte ich irgendwo gelesen und selbst in der config geändert.

Auszug aus bird.conf, identisch bei bird6.conf

...
protocol kernel k_mast {
    kernel table 42; <--
    scan time 10;
    import none;
    export filter {
        krt_prefsrc = ownip;
        accept;
    };
};
...

Auch wenn ich das wieder rückgängig mache scheint sich da nicht viel mehr zu tun.