HowTo IC-VPN Setup

Freifunker · 4. August 2015 um 18:21

Ich versuche das jetzt mal für mich aufzudröseln und ich glaube ich weiß auch wo der Haken liegt, aber mir fehlt das Wissen wie ich das gerade gebogen bekomme.

Ich habe ja bislang nur ein „Gateway“ was im IC-VPN angebunden ist. Insgesamt haben wir aber 3 Gateways. Alle samt mit Schweden Tunnel. Traffic von den Knoten schlägt auf den Gateways auf und wird 0x1 getaggt und landet in der Routing Table 42. In allen Tables habe ich manuell folgendes gemacht:

ip route add 10.0.0.0/8 via 10.134.10.1 dev br-ffue table 42
ip route add 172.20.0.0/16 via 10.134.10.1 dev br-ffue table 42
ip route add 172.22.0.0/15 via 10.134.10.1 dev br-ffue table 42

Sprich Anfragen an die Adressenbereiche die im IC-VPN vorhanden sind rüber zum Gateway weiter schieben.

Auf dem Gateway mit 10.134.10.1 läuft der Bird und schmeißt seine Routen ebenfalls in die dortige Table 42. Ausgehend scheints zu funktionieren und die Antworten kommen auch zurück. Warum auch immer.

Wenn jetzt aber ein Paket aus dem IC-VPN zu einem meiner Gateways direkt will, kommt es da an, aber wird über das Default GW beantwortet. Ist ja auch logisch, weil die default Routing Tabelle ja gar keine Routen zu zu den Netzen im IC-VPN kennt.

default via 31.214.242.1 dev eth0
10.7.0.81 dev tun0 proto kernel scope link src 10.7.0.82
10.134.0.0/16 dev br-ffue proto kernel scope link src 10.134.10.1
10.207.0.0/16 dev icvpn proto kernel scope link src 10.207.0.18
31.214.242.0/24 dev eth0 proto kernel scope link src 31.214.242.185

Die Routen welche mir Bird in die Table 42 schreibt müssten also auch nochmal in der normalen Routing Tabelle eingetragen werden. Kann ich Bird dazu veranlassen?

root@uegw1:/home/marc-andre# iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 600K packets, 44M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 372K packets, 30M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 814K packets, 56M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 604K packets, 40M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 261K   20M MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0

Meine Mutter hat gemangelt. Ich nicht. Nein Spaß bei Seite. Die Config ist so von Münster mal abgekupfert worden. Mit der Aussage das dann DNS Anfragen auch über das VPN raus laufen. Und das tun sie auch.

Done…Aber scheinst kein Ping mehr laufen zu haben.

CHRlS · 4. August 2015 um 18:30

Nein, das brauchst Du nicht…und mach mal überall bird drauf, um die Routen vom icvpn Gateway einfach zu übernehmen…

Stimmt Dein Satz „ip rule“ den Du drin hast?

Auf die Schnelle so ähnlich wie:

ip -6 rule add iif icvpn pref 10 table 42
ip -6 rule add iif br-ffue pref 10 table 42
ip rule add iif icvpn pref 10 table 42
ip rule add iif br-ffue pref 10 table 42

ip -6 rule add from fc00::/7 pref 10 table 42
ip -6 rule add to fc00::/7 pref 10 table 42
ip rule add from 10.0.0.0/8 pref 10 table 42
ip rule add to 10.0.0.0/8 pref 10 table 42
ip rule add from 172.20.0.0/16 pref 10 table 42
ip rule add to 172.20.0.0/16 pref 10 table 42
ip rule add from 172.22.0.0/15 pref 10 table 42
ip rule add to 172.22.0.0/15 pref 10 table 42

Das leitet alle Table Anfragen von und aus den Netzen und relevanten Interfaces dann auf die Table 42 um…

Freifunker · 4. August 2015 um 18:47

Bin mir jetzt nicht sicher was du meinst:

root@uegw1:/home/marc-andre# ip rule show
0:    from all lookup local 
32764:    from all iif icvpn lookup 42 
32765:    from all fwmark 0x1 lookup 42 
32765:    from all fwmark 0x1 unreachable
32766:    from all lookup main 
32767:    from all lookup default 
root@uegw1:/home/marc-andre#

Mir raucht aber gerade echt der Kopf, weil ich so langsam nicht mehr durchblicke wie was wohin geroutet wird und aus welchen Grund, oder auch nicht.

Eigentlich wollte ich erst mal nur ein Gateway am IC-VPN teil haben lassen, nämlich meinen. Die anderen Gateways gehören unserem Verein und der sagt da wird kein IC-VPN drauf gemacht. Aber Traffic zu meinen Gateway Routen das kann ich ja ohne das ich Bird auf diesen installieren muss.

CHRlS · 4. August 2015 um 18:52

Wenn Du auf die anderen Server bird installierst, dann bekommen die von Deinem icvpn Gateway lediglich alle Routen mit Gateway auf Dein icvpn Gateway…wenn ihr das nicht ausbauen wollt, kannste das natürlich dann auch direkt sein lassen, auch wenn dynamisch geroutet immer „sauberer“ ist

…füg mal die oben gezeigten IP Rules ein auf dem icvpn Gateway, dann lüppt das…

wusel · 4. August 2015 um 19:00

[quote=„Freifunker, post:21, topic:6672“]
Sprich Anfragen an die Adressenbereiche die im IC-VPN vorhanden sind rüber zum Gateway weiter schieben.[/quote]

Sofern 10.134.10.1 die anderen GWs direkt erreichen kann (was bei br-ffue gegeben sein sollte), sollte das tun.

[quote=„Freifunker, post:21, topic:6672“]
Wenn jetzt aber ein Paket aus dem IC-VPN zu einem meiner Gateways direkt will, kommt es da an, aber wird über das Default GW beantwortet. Ist ja auch logisch, weil die default Routing Tabelle ja gar keine Routen zu zu den Netzen im IC-VPN kennt.[/quote]

Naja, das verstehe ich nicht wirklich, was da passiert. Mangels Verweis auf Tabelle 42 (per ip rule iif oder iptables-Markierung) greift nur die Tabelle main. Demnach liegt 10.134.10.1 auf br-ffue und 10.134.0.0/16 dahinter. Das klappt über’s ICVPN auch, wenn ich mit ICVPN-Adresse ankomme:

root@gw05:~# traceroute -s 10.207.0.138 -m 5 10.134.10.1
traceroute to 10.134.10.1 (10.134.10.1), 5 hops max, 60 byte packets
 1  10.134.10.1 (10.134.10.1)  19.787 ms  20.200 ms  20.239 ms

Es klappt aber verwirrenderweise nicht, wenn ich mit einer FF-10er komme:

root@gw05:~# traceroute -s 10.169.1.1 -m 5 10.134.10.1
traceroute to 10.134.10.1 (10.134.10.1), 5 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Ratter. Ratter. Oh. Nee, klar: 10.207.0.0/16 dev icvpn proto kernel scope link src 10.207.0.18, deshalb tut’s da. Sprich: das ICMP REPLY an 10.169.1.1 oder 10.255.255.1 wird via eth0 rausgeschickt, klar. Dennoch verstehe ich nicht, warum es raus… ah, klar: Du kommst via br-ffue, das wird markiert, auf Tabelle 42 geschoben und damit geht’s raus. Die Antwortpakete gehen an 10.134.irgendwas und via Tabelle main nach br-ffue.

[quote=„Freifunker, post:21, topic:6672“]
Die Routen welche mir Bird in die Table 42 schreibt müssten also auch nochmal in der normalen Routing Tabelle eingetragen werden. Kann ich Bird dazu veranlassen?[/quote]

Naja, strictly speaking müßte das nicht sein (indem Du dafür sorgst, daß per ip rule alles, was nicht eth0 ist, über Tabelle 42 läuft) aber:

# don't use kernel's routes for bird, but export bird's 
# routes to kernel table 42. 
#
# We do not import any routes here, therefore we can be sure
# that no funny routes jump into our waggon.
protocol kernel {
  scan time 20;    # Scan kernel routing table every 20 seconds
  kernel table 42; # routing table for mesh networks
  import none;     # Import no routes
  export all;      # Export all routes
};

# export to kernel main table for local services
protocol kernel {
  table kernel_main;
  scan time 20;
  import none;
  export all;
  persist;
};

Frage ist nur, ob Du das so in Deine bird.conf übernehmen kannst. Sprich: welche internen Tabellen nutzt die …

[quote=„Freifunker, post:21, topic:6672“]
Done…Aber scheinst kein Ping mehr laufen zu haben.[/quote]

Ack, war aus, sorry.

root@bgp1:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16      via 10.207.0.18 on icvpn [uegw1 15:13:18] * (100) [AS64525i]
root@bgp1:~# tcpdump -n -i icvpn host 10.255.255.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on icvpn, link-type EN10MB (Ethernet), capture size 65535 bytes
18:57:01.001208 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22521, seq 843, length 18
18:57:02.009317 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22521, seq 844, length 18
[…]

sigh Kein Pong. Wo geht die Antwort denn lt. tcpdump jetzt hin?

CHRlS · 4. August 2015 um 19:05

Weil keine ip rules drin sind

Freifunker · 4. August 2015 um 19:06

Gehen immer noch via eth0 raus. Ich hab jetzt deine Regeln angewandt:

ip rule add fwmark 0x1 unreachable pref 32765
ip rule add iif icvpn lookup 42 # Alternativ: iptables -t mangle … -i icvpn …
ip route add 10.134.0.0/16 dev br-ffue src 10.134.10.1 table 42

CHRlS · 4. August 2015 um 19:07

Teste doch mal was passiert wenn Du die rein nimmst:

ip -6 rule add iif icvpn pref 10 table 42
ip -6 rule add iif br-ffue pref 10 table 42
ip rule add iif icvpn pref 10 table 42
ip rule add iif br-ffue pref 10 table 42

ip -6 rule add from fc00::/7 pref 10 table 42
ip -6 rule add to fc00::/7 pref 10 table 42
ip rule add from 10.0.0.0/8 pref 10 table 42
ip rule add to 10.0.0.0/8 pref 10 table 42
ip rule add from 172.20.0.0/16 pref 10 table 42
ip rule add to 172.20.0.0/16 pref 10 table 42
ip rule add from 172.22.0.0/15 pref 10 table 42
ip rule add to 172.22.0.0/15 pref 10 table 42

wusel · 4. August 2015 um 19:12

[quote=„Freifunker, post:23, topic:6672“]
Eigentlich wollte ich erst mal nur ein Gateway am IC-VPN teil haben lassen, nämlich meinen.[/quote]

So hatten wir auch mal angefangen, bird.conf für ICVPN hingeschustert, daß es tut, dann statische Routen; aber da wir initial schon >1 GW hatten und beide am ICVPN teilnahmen, war das immer … suboptimal. Derzeit daher der Umbau auf bgp*, die Außenkommunikation machen und gw*, die per OSPF (streßfreiere Alternative wäre ggf. OLSR ;)) mit den bgp* verbunden sind.

18 bytes from 10.134.10.1: icmp_seq=1510 ttl=63
18 bytes from 10.134.10.1: icmp_seq=1511 ttl=63
18 bytes from 10.134.10.1: icmp_seq=1512 ttl=63
18 bytes from 10.134.10.1: icmp_seq=1513 ttl=63
18 bytes from 10.134.10.1: icmp_seq=1514 ttl=63

Yeah!

root@gw05:~# traceroute -s 10.169.1.1 -m 5 10.134.10.1
traceroute to 10.134.10.1 (10.134.10.1), 5 hops max, 60 byte packets
 1  10.134.10.1 (10.134.10.1)  16.550 ms  16.888 ms  16.901 ms

Allerdings:

root@gw05:~# traceroute -s 10.169.1.1 -m 5 10.134.30.1
traceroute to 10.134.30.1 (10.134.30.1), 5 hops max, 60 byte packets
 1  10.134.10.1 (10.134.10.1)  18.645 ms  19.057 ms  19.090 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Da fehlt noch was.

ip rule add from 10.0.0.0/8 pref 10 table 42
ip rule add to 10.0.0.0/8 pref 10 table 42

Und auch die anderen, die @CHRlS nannte; als pref allerdings bei Dir eher 32764, wobei 10 auch nicht schaden dürfte.

Nachtrag: was jene Einträge machen ist, daß Traffic vom icvpn-Interface und br-ffue-Interface als auch sonstiger, irgendwie auf Deiner Kiste ankommender von 10/8 kommender bzw. nach 10/8 gehender Traffic über Tabelle 42 geroutet wird. Im Grunde kann dann die -t mangle -j MARK-Regel weg, außer für DNS via Schweden (dazu bin ich dann wohl zu unparanoid).

Freifunker · 4. August 2015 um 19:16

So. Hab das jetzt mit rein genommen. Allerdings nur die Rules für IPv4, weil IPv6 route ich nicht via Table 42.

root@uegw1:/home/marc-andre# ip rule show
0: from all lookup local
10: from all iif icvpn lookup 42
10: from all to 10.0.0.0/8 lookup 42
10: from 172.20.0.0/16 lookup 42
10: from all to 172.20.0.0/16 lookup 42
10: from 172.22.0.0/15 lookup 42
10: from all to 172.22.0.0/15 lookup 42
10: from all iif icvpn lookup 42
10: from all to 10.0.0.0/8 lookup 42
10: from 172.20.0.0/16 lookup 42
10: from all to 172.20.0.0/16 lookup 42
10: from 172.22.0.0/15 lookup 42
10: from all to 172.22.0.0/15 lookup 42
10: from all iif icvpn lookup 42
10: from all iif br-ffue lookup 42
10: from 10.0.0.0/8 lookup 42
10: from all to 10.0.0.0/8 lookup 42
10: from 172.20.0.0/16 lookup 42
10: from all to 172.20.0.0/16 lookup 42
10: from 172.22.0.0/15 lookup 42
10: from all to 172.22.0.0/15 lookup 42
32764: from all iif icvpn lookup 42
32765: from all fwmark 0x1 lookup 42
32765: from all fwmark 0x1 unreachable
32766: from all lookup main
32767: from all lookup default

So wie es aussieht wird jetzt der Ping von @wusel beantwortet. Werden denn auch Antworten von 10.134.20.1 sowie 10.134.30.1 und meinen derzeitigen Host 10.134.22.223 empfangen?

Das selbe IPv6 ULA bitte mal Testen:

Mein Host: fd83:e002:c8a1:0:225:22ff:fedd:de87
GW1: fd83:e002:c8a1::1
GW2: fd83:e002:c8a1::2
GW3: fd83:e002:c8a1::3

wusel · 4. August 2015 um 19:22

root@gw01:~# traceroute -s 10.255.255.1 -m 5 10.134.22.223
traceroute to 10.134.22.223 (10.134.22.223), 5 hops max, 60 byte packets
 1  100.64.2.0 (100.64.2.0)  16.239 ms  16.227 ms  16.208 ms
 2  10.134.10.1 (10.134.10.1)  255.036 ms  255.702 ms  255.707 ms
 3  10.134.22.223 (10.134.22.223)  279.806 ms  279.795 ms  281.748 ms

Allerdings: 20.1/30.1 tun noch nicht.

root@gw01:~# traceroute -s 10.255.255.1 -m 5 10.134.20.1
traceroute to 10.134.20.1 (10.134.20.1), 5 hops max, 60 byte packets
 1  100.64.2.0 (100.64.2.0)  15.670 ms  15.629 ms  15.621 ms
 2  10.134.10.1 (10.134.10.1)  22.507 ms  22.498 ms  22.483 ms
 3  * * *
 4  * * *
 5  * * *

10.255.255.1 pingt 10.134.30.1, kannst ja mal gucken, ob das auf br-ffue rausgeht und dann auch 10.134.30.1, wo die Antwort hingeht … Evtl. da gleiches Problem, sprich fehlender Verweis von entweder iif br-ffue und/oder from 10.0.0.0/8 nach Tabelle 42 …

Freifunker · 4. August 2015 um 19:31

Ok. Auf den anderen beiden gateways auch:

ip rule add iif br-ffue pref 10 table 42
ip rule add from 10.0.0.0/8 pref 10 table 42
ip rule add to 10.0.0.0/8 pref 10 table 42
ip rule add from 172.20.0.0/16 pref 10 table 42
ip rule add to 172.20.0.0/16 pref 10 table 42
ip rule add from 172.22.0.0/15 pref 10 table 42
ip rule add to 172.22.0.0/15 pref 10 table 42

Durchgeführt.

wusel · 4. August 2015 um 20:38

18 bytes from 10.134.30.1: icmp_seq=4357 ttl=62
18 bytes from 10.134.20.1: icmp_seq=1 ttl=62

Bei v6, unter Vorbehalt, jeweils von 2001:bf7:1310::4:

traceroute to fd83:e002:c8a1::1 (fd83:e002:c8a1::1), 5 hops max, 80 byte packets
 1  fd83:e002:c8a1::1 (fd83:e002:c8a1::1)  17.239 ms  17.132 ms  17.076 ms

traceroute to fd83:e002:c8a1::2 (fd83:e002:c8a1::2), 5 hops max, 80 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *

traceroute to fd83:e002:c8a1::3 (fd83:e002:c8a1::3), 5 hops max, 80 byte packets
 1  fd83:e002:c8a1::1 (fd83:e002:c8a1::1)  18.806 ms  18.640 ms  18.598 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

traceroute to fd83:e002:c8a1:0:225:22ff:fedd:de87 (fd83:e002:c8a1:0:225:22ff:fedd:de87), 5 hops max, 80 byte packets
 1  fd83:e002:c8a1::1 (fd83:e002:c8a1::1)  16.185 ms  16.141 ms  16.104 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Freifunker · 4. August 2015 um 21:07

Also Public IPv6 geht bei mir definitiv via SIXXS Tunnel raus weil ich 2000::/3 dorthin weg Route. Das muss auch so bleiben, weil sonst habe ich keine v6 Connectivity mehr im Freifunk Netz.

Was jetzt aber aufgefallen ist und auch schon klagen kommen, das keine vernünftige IPv4 Exit Kommunikation mehr statt findet. Sprich via IPv4 ins Internet über die Schweden Tunnel setzt auf allen Gateways der Datenverkehr aus. Was kann das jetzt beeinflussen?

ping -I tun0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 5.45.111.165 tun0: 56(84) bytes of data.

Das From gehört da definitiv nicht hin. Das ist die eth0 Adresse.

Also ist irgendwas ganz kaputt im Routing.

So Rules wieder gelöscht:

ip rule del iif br-ffue pref 10 table 42
ip rule del from 10.0.0.0/8 pref 10 table 42
ip rule del to 10.0.0.0/8 pref 10 table 42
ip rule del from 172.20.0.0/16 pref 10 table 42
ip rule del to 172.20.0.0/16 pref 10 table 42
ip rule del from 172.22.0.0/15 pref 10 table 42
ip rule del to 172.22.0.0/15 pref 10 table 42

Jetzt ist wieder hübsch:

root@ffuegw2:/home/marc-andre# ping -I tun0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 10.7.0.82 tun0: 56(84) bytes of data.
…

Also war das noch nicht die Lösung. Zumindestens nicht ohne mir mein Schweden Exit zu zerschießen.
Weis nicht obs wichtig ist, aber der Schweden VPN ist auch ein 10.x.x.x Tunnel, wie man ja sehen kann.

wusel · 4. August 2015 um 22:24

[quote=„Freifunker, post:34, topic:6672“]
Also war das noch nicht die Lösung. Zumindestens nicht ohne mir mein Schweden Exit zu zerschießen. Weis nicht obs wichtig ist, aber der Schweden VPN ist auch ein 10.x.x.x Tunnel, wie man ja sehen kann.[/quote]

Was passiert denn, wenn Du von Deinem Client hinter 10.134.10.1 traceroute to 8.8.8.8 machst? MIT den Regeln Dann sollte das Paket zu 8.8.8.8 über tun0 rausgehen, was Du im tcpdump sehen solltest. Mit welcher Zieladresse kommt das Paket von 8.8.8.8 über tun0 zurück? Es sollte 10.7.0.82 sein, was dann auf 10.134.22.223 (IP des Clients) genattet werden sollte und auf br-ffue sichtbar.

Evtl. reicht ja ip rule add iif tun0 pref 10 table 42 schon, denn ohne Regeln greift für tun0 ja main. Was, wg. br-ffue-Eintrag, reicht, Du routest ohne ICVPN ja nur zwischen br-ffue und tun0. Du mußt Dir klar machen, was Du wie routen willst/mußt, und dann geht das auch

gw01 via bgp1 mit FFRL-Exit:

root@gw01:~# traceroute -m 5  -s 10.255.255.1 ns.uu.net
traceroute to ns.uu.net (137.39.1.3), 5 hops max, 60 byte packets
 1  100.64.2.0 (100.64.2.0)  18.009 ms  18.210 ms  18.218 ms
 2  100.64.0.178 (100.64.0.178)  21.986 ms  21.990 ms  21.992 ms
 3  irb-1050.bb-a.fra3.fra.de.oneandone.net (195.20.242.193)  26.167 ms  26.170 ms  26.170 ms
 4  xe-3-1-0-276.fra20.ip4.tinet.net (213.200.65.201)  26.170 ms  26.171 ms  26.170 ms
 5  was14.ip4.gtt.net (141.136.111.165)  114.434 ms  114.448 ms  114.448 ms

Hochfahren von Mullvad-Tunnel auf bgp1:

root@bgp1:/etc/openvpn# /etc/init.d/openvpn start mullvad
 * Starting virtual private network daemon(s)..
 *   Starting VPN 'mullvad'
root@bgp1:~# ip route show | grep mullvad
10.5.0.0/16 dev mullvad  proto kernel  scope link  src 10.5.0.7 
root@bgp1:~# /sbin/iptables -t nat -I POSTROUTING -s 10.255.0.0/16 -o mullvad -j SNAT --to 10.5.0.7
root@bgp1:~# ip route add 137.39.1.3 dev mullvad table 42

gw01 via bgp1 mit Mullvad-Exit:

root@gw01:~# traceroute -m 5  -s 10.255.255.1 ns.uu.net
traceroute to ns.uu.net (137.39.1.3), 5 hops max, 60 byte packets
 1  100.64.2.0 (100.64.2.0)  15.908 ms  16.077 ms  16.076 ms
 2  10.5.0.1 (10.5.0.1)  31.063 ms  42.597 ms  57.453 ms
 3  tengige0-0-0-5.evo-hvc3.leaseweb.net (95.211.168.190)  57.479 ms  57.478 ms  57.476 ms
 4  adm-b3-link.telia.net (213.248.77.37)  57.453 ms  57.451 ms adm-b3-link.telia.net (213.248.79.21)  57.425 ms
 5  adm-bb3-link.telia.net (213.155.136.240)  57.625 ms adm-bb3-link.telia.net (62.115.136.94)  57.452 ms adm-bb3-link.telia.net (62.115.136.88)  57.605 ms

Allerdings sind meine Regeln etwas strikter (Tabelle 4 ist nur zum Test der gw01-Anbindung):

root@bgp1:~# ip rule show
0:      from all lookup local 
30991:  from all to 10.255.255.0/24 lookup 4 
30992:  from 100.64.1.1 lookup 4 
30993:  from 10.255.255.0/24 lookup 4 
30994:  from 10.64.1.0/24 lookup 4 
30998:  from 10.255.0.0/16 lookup freifunk 
30998:  from all to 10.0.0.0/8 lookup freifunk 
30999:  from 185.66.193.64 lookup freifunk 
31000:  from all iif icvpn lookup freifunk 
31001:  from all iif icvpn unreachable
32766:  from all lookup main 
32767:  from all lookup default

(10.64.1.0/24 ist ein Typo, hätte 100.64.1.0/24 sein sollen – GRE- statt OVPN-Tunnel –, tat aber auch so ;))

Freifunker · 4. August 2015 um 23:39

Ich will folgendes:

Von Freifunk Clients ins IC-VPN Routen, das funktioniert nach meiner Methode offenbar problemlos, sonst könnte ich nicht Seiten wie http://start.ffpb aufrufen.

ip route add 10.0.0.0/8 via 10.134.10.1 dev br-ffue table 42
ip route add 172.20.0.0/16 via 10.134.10.1 dev br-ffue table 42
ip route add 172.22.0.0/15 via 10.134.10.1 dev br-ffue table 42

Durch die Magie auf UEGW1 (10.134.10.1), vermutlich wegen den Tag 0x1, werden Pakete die über GW2 und GW3 kommen dort auch wieder in die Table 42 geschmissen wo Bird auch die Routen des IC-VPN abwirft. Outbound nach meiner Ansicht alles wunderbar ohne wirklich großartige Eingriffe auf GW2 und GW3.

Die Problematik liegt halt beim Inbound. Sollen Pakete aus dem IC-VPN in mein Netz rein, oder sollen die Gateways direkt auf Anfragen Antworten muss eine Rückroute her für eben die Netze die sich im IC-VPN verbergen.

Im Grunde bräuchte ich ne einfache Rule die sagt. Pakete die über das Interface ICVPN rein kommen und an br-ffue gehen müssen auch wieder über ICVPN raus beantwortet werden. Das ganze aber direkt ohne das tun0 davon irgendwie beeinflusst wird.

Freifunker · 5. August 2015 um 00:38

Mag mal jemand ein Looking Glas mit Ping und Tracert Möglichkeiten welches aus dem Freifunk Netz heraus arbeitet bauen?

Also folgendes. Sobald ich ip rule add to 10.0.0.0/8 pref 10 table 42 mache stirbt der Ping nach 8.8.8.8 von einem Client im Freifunk Netz ab. Es ist dann keine v4 Verbindung mehr über die Schweden VPN möglich. Auf dem Gateway wo der Ping raus gehen soll sehe ich via TCPDUMP jedoch das die Pings über tun0 raus gehen und auch Antworten zurück kommen. Doch die kommen nicht mehr beim Client an.

Parallel gehen aber auch Pakete mit der IP von TUN0 über ETH0 raus.

wusel · 5. August 2015 um 07:25

[quote=„Freifunker, post:37, topic:6672“]
Sobald ich ip rule add to 10.0.0.0/8 pref 10 table 42 mache stirbt der Ping nach 8.8.8.8 von einem Client im Freifunk Netz ab.[/quote]

Vollkommen blöde, aber ip rule add iif tun0 pref 9 table main könnte das kompensieren, wenn’s „nur“ am Routing liegt (hängt iif tun0 vor die anderen Regeln, damit sollte der Ablauf von vorher, tun0 wird über main geroutet, ja wieder hergestellt sein).

[quote]Auf dem Gateway wo der Ping raus gehen soll sehe ich via TCPDUMP jedoch das die Pings über tun0 raus gehen und auch Antworten zurück kommen. Doch die kommen nicht mehr beim Client an.

Parallel gehen aber auch Pakete mit der IP von TUN0 über ETH0 raus. [/quote]

Naja, wenn die Antwortpakete (Quell-/Zieladresse auf tun0 und in eth0?) nicht nach br-ffue gehen, gehen sie schein’s via main zum Default. Hast Du denn noch br-ffue-Route in Tabelle 42 und ein unreachable in den Rules vor main? IMHO nicht, tcpdump icvpn:

09:23:48.658152 ARP, Request who-has 10.134.30.1 tell 10.207.0.18, length 28
09:23:49.146900 ARP, Request who-has 10.134.35.127 tell 10.207.0.18, length 28

Das dürfte 10/8 dev icvpn sein, die in Deinem ip route show table 42 gestern stand …

Rekapitulieren wir: Dein ICVPN-Setup tut (bird). Dein Routing aber … hat noch Luft nach oben. Ergo: Lösche iptables und ip rules und fange sauber von vorne an. Kein MARK mehr, sondern ip rule iif, SNAT nur für den tun0-Exit. Drauf achten, daß Routen von außerhalb bird auch in Tabelle 42 eingerichtet werden (if up/down; openvpn up/down).
Das wäre jedenfalls mein Ansatz und ist mein Rat. Ziel sollte es sein, daß Verkehr über FF-Interfaces (br-ff*, icvpn, Exit-Tunnel) nur über Tabelle 42 geroutet wird. Je nachdem, ob der Host auch partizipieren soll (reiner Router oder auch z. B. DNS-Server) machen die bird-Routen auch in main Sinn, ggf. ist dann aber ein -o SNAT auf die/eine FF-IP notwendig.

Freifunker · 5. August 2015 um 09:58

Moin!

Wenn ich:
ip rule add iif tun0 pref 9 table main
sowie
ip rule add to 10.0.0.0/8 pref 10 table 42

mache, geht ein Ping weiterhin über tun0 sauber raus. Allerdings sperre ich mir damit wohl mein eigenes Netz aus. Sprich vom Client kann ich 10.134.10.1 sowie die anderen Gateways nicht mehr erreichen. Sprich Netzinterner Traffic scheint damit ausgeschlossen. Es ist echt zum Heulen.

CHRlS · 5. August 2015 um 10:04

Du musst alle Routen in table42 bringen und dann einfach alle Interfaces ausser eth0, sowie alle internen Netze auf die table42 umleiten…darüber hinaus benötigst Du dann lediglich die SNAT Regel die auf das Interface den VPN Tunnels festgetackert ist, sowie in der table42 die openvpn default route…wenn Du das genau so drin hast, dann wird alles laufen…