HowTo IC-VPN Setup

Technik
1

Ich will mich nun so langsam mal mit dem IC-VPN auseinander setzen. Leider sind wie immer die Dokumentationen sehr spärlich, oder ich finde nicht die richtigen oder es funktioniert mal wieder was nicht.

Gefunden habe ich GitHub - freifunk/icvpn-meta: InterCity-VPN - Metadata registry (BGP, DNS, Subnet Allocations in 10.0.0.0/8) und GitHub - freifunk/icvpn-scripts: Scripts for working with icvpn-meta.

Soweit so gut. Aber bei den Scripten haperts dann mal wieder. Alles so gemacht wie es in der Readme.md steht. Allerdings beim Ausführen dann das übliche. Irgendwas fehlt trotzdem noch:

$ ./findfree
Traceback (most recent call last):
  File "./findfree", line 6, in <module>
    import yaml
ImportError: No module named yaml

Pakete wie angegeben sind installiert.

$ sudo apt-get install python-yaml python3-pip
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
python3-pip ist schon die neueste Version.
python-yaml ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

$ sudo pip-3.2 install ipaddress
Downloading/unpacking ipaddress
  Running setup.py egg_info for package ipaddress
    
Installing collected packages: ipaddress
  Running setup.py install for ipaddress
    
Successfully installed ipaddress
Cleaning up...
2 „Gefällt mir“
2

Wie wäre es mit python3-yaml?

1 „Gefällt mir“
3

Hallo Freifunker,

haste dir schon mal http://wiki.freifunk.net/IC-VPN angesehen?

Gruß
Thomas

4

Ja, habe ich. Ich kam halt mit den Scripts nicht klar. Leider werden wohl readme.md nicht angepasst. Wäre nie alleine drauf gekommen das das Python3-yaml sein müsste.

Nen Pull Request zum icvpn-meta ist auf dem weg. Mal schauen wie das alles so klappt.
https://github.com/FreifunkUE/icvpn-meta/commit/52c42732e15ef4b9cbb6d150120bd1271eaef70a

1 „Gefällt mir“
5

Moin @Freifunker

Dein Engangement ist nicht zufällig auf „Die Geschichte mit Torfmoorholm“ zurückzuführen?

Aber gut das sich Jemand damit beschäftigt!

Ich glaube das die Dresden`ner da schon ordentlich was gemacht haben.

Gruß

6

Ja, das ist leider ein Problem, diese Hipster-„Sprachen“, die sich schneller als das Wetter ändern, nerven mich auch kollossal. Aktuell ist es wohl nicht „python“, sondern „python3“, was man braucht (s. a. Allow meta-* to override ICVPN_NETWORKS check by wusel42 · Pull Request #34 · freifunk/icvpn-scripts · GitHub); andererseits sollte man diese Art Kummer ja mittlerweile gewöhnt sein.

2 „Gefällt mir“
7

Irgendwie kann ich dir gerade nicht folgen…

Ich muss jetzt erst mal selber überhaupt alles verstehen. Hab gedacht das wäre so eine „ein Abend“ Aktion mit dem IC-VPN. Aber anscheinend ist das mal wieder alles etwas was nicht so einfach ist. Einfach und IT wäre ja auch ein Wunder. :wink:

Die empfohlenen Programm Pakete die Debian liefert scheinen wieder veraltet zu sein und ich muss schauen aus welchen Repos ich die aktuellsten her bekomme. Außerdem stehe ich mit Github irgendwie auf Kriegsfuß.

Auf jeden Fall ist meine Motivation erst mal etwas gebremst und ich werde das Wochenende erstmal genießen und mich irgendwann dann damit wieder weitermachen.

8

Moin @Freifunker.
Hintergrund mit dem „Torfmoorholm“ ist folgender:

Ich hatte eine Frage gestellt zum meshen von 2 Routern unterschiedlicher Communitys.
Dazu hatte ich ein virt. Szenario erdacht, eben mit dem Ort Torfmoorholm. Angenommene Lage bei E`förde, wo sich 2 Knoten „sehen“ können. Der eine mit der Flensburger Software und der Andere mit der Kieler.
Verbinden die sich dann?

Das war der Hintergrund.
Und darüber kam es dann zu dem Thema IC-VPN.

Gruß

Nachtrag: Habs gerade gefunden. War im IRC bei den Kielern.

9

So. Habe mich jetzt an IC-VPN – wiki.freifunk.net lang gehangelt. Was ich sagen kann ist das der TINC läuft und wohl auch mit irgendwem verbunden ist, jedenfalls sehe ich auf dem Interface ne Menge ARP Traffic und kann über das Interface auch ein Gateway einer anderen Community anpingen. Beim BIRD jedoch haperts ein wenig.

Kann es sein das mit Bird 1.5.0 die im Wiki hinterlegten Config Beispiele nicht mehr korrekt sind? Denn ich bekomme immer ein Syntax Error wenn in Bird starte.

### templates ###

# template for same city freifunk gateways
template bgp locals {
  table ibgp;
  local as ownas;
  import filter {
    preference = 99;
    accept;
  };
  export where source = RTS_BGP;
  direct;
  next hop self;
};

Da meckert er das direct; an.

10

Moin!

So, nun habe ich es es nach nochmaligen Aufsetzen fast alles zum laufen bekommen. Jedoch bekomme ich keine IPv4 Routen über BIRD. Kann mir da jemand unter die Arme greifen?

# birdc show route all
BIRD 1.5.0 ready.

# birdc show protocols
BIRD 1.5.0 ready.
name     proto    table    state  since       info
k_mast   Kernel   master   up     19:53:43    
p_maintbl Pipe     master   up     19:53:43    => ebgp
p_ibgptbl Pipe     ebgp     up     19:53:43    => ibgp
p_freitbl Pipe     ibgp     up     19:53:43    => freifunk
unreachable_default Static   freifunk up     19:53:43    
static_ffue Static   ebgp     up     19:53:43    
aachen1  BGP      ebgp     start  19:53:43    Idle          
amsterdam1 BGP      ebgp     start  19:53:43    Idle          
augsburg1 BGP      ebgp     start  19:53:43    Idle          
augsburg2 BGP      ebgp     start  19:53:43    Idle          
basel1   BGP      ebgp     start  19:53:43    Idle          
bayreuth BGP      ebgp     start  19:53:43    Idle          
berlin1  BGP      ebgp     start  19:53:43    Idle          
berlin2  BGP      ebgp     start  19:53:43    Idle          
bielefeld1 BGP      ebgp     start  19:53:43    Idle          
bielefeld6 BGP      ebgp     start  19:53:43    Idle          
braunschweig1 BGP      ebgp     start  19:53:43    Idle          
braunschweig2 BGP      ebgp     start  19:53:43    Idle          
bremen1  BGP      ebgp     start  19:53:43    Idle          
bremen2  BGP      ebgp     start  19:53:43    Idle          
bremen3  BGP      ebgp     start  19:53:43    Idle          
chemnitz1 BGP      ebgp     start  19:53:43    Idle          
darmstadt1 BGP      ebgp     start  19:53:43    Idle          
darmstadt2 BGP      ebgp     start  19:53:43    Idle          
diepholz1 BGP      ebgp     start  19:53:43    Idle          
dreilaendereck1 BGP      ebgp     start  19:53:43    Idle          
dreilaendereck2 BGP      ebgp     start  19:53:43    Idle          
dreilaendereck4 BGP      ebgp     start  19:53:43    Idle          
dresden1 BGP      ebgp     start  19:53:43    Idle          
dresden2 BGP      ebgp     start  19:53:43    Idle          
erfurt1  BGP      ebgp     start  19:53:43    Idle          
erfurt2  BGP      ebgp     start  19:53:43    Idle          
flensburg1 BGP      ebgp     start  19:53:43    Idle          
flensburg2 BGP      ebgp     start  19:53:43    Idle          
franken_ro1 BGP      ebgp     start  19:53:43    Idle          
frankfurt1 BGP      ebgp     start  19:53:43    Idle          
freiburg1 BGP      ebgp     start  19:53:43    Idle          
fulda1   BGP      ebgp     start  19:53:43    Idle          
gera_greiz1 BGP      ebgp     start  19:53:43    Idle          
goettingen1 BGP      ebgp     start  19:53:43    Idle          
graz1    BGP      ebgp     start  19:53:43    Idle          
graz2    BGP      ebgp     start  19:53:43    Idle          
guetersloh1 BGP      ebgp     start  19:53:43    Idle          
guetersloh4 BGP      ebgp     start  19:53:43    Idle          
gueterslohbgp1 BGP      ebgp     start  19:53:43    Idle          
gueterslohbgp2 BGP      ebgp     start  19:53:43    Idle          
rhwdbgp1 BGP      ebgp     start  19:53:43    Idle          
halle1   BGP      ebgp     start  19:53:43    Idle          
halle2   BGP      ebgp     start  19:53:43    Idle          
hamburg01 BGP      ebgp     start  19:53:43    Idle          
hamburg02 BGP      ebgp     start  19:53:43    Idle          
hamburg03 BGP      ebgp     start  19:53:43    Idle          
harz1    BGP      ebgp     start  19:53:43    Idle          
hennef1  BGP      ebgp     start  19:53:43    Idle          
jena1    BGP      ebgp     start  19:53:43    Idle          
jena2    BGP      ebgp     start  19:53:43    Idle          
karlsruhe1 BGP      ebgp     start  19:53:43    Idle          
karlsruhe2 BGP      ebgp     start  19:53:43    Idle          
kassel1  BGP      ebgp     start  19:53:43    Idle          
kassel3  BGP      ebgp     start  19:53:43    Idle          
koeln1   BGP      ebgp     start  19:53:43    Idle          
leichlingen0 BGP      ebgp     start  19:53:43    Idle          
leipzig1 BGP      ebgp     start  19:53:43    Idle          
leipzig2 BGP      ebgp     start  19:53:43    Idle          
luebeck1 BGP      ebgp     start  19:53:43    Idle          
luebeck2 BGP      ebgp     start  19:53:43    Idle          
luenen   BGP      ebgp     start  19:53:43    Idle          
magdeburg1 BGP      ebgp     start  19:53:43    Idle          
magdeburg2 BGP      ebgp     start  19:53:43    Idle          
mainz1   BGP      ebgp     start  19:53:43    Idle          
mainz2   BGP      ebgp     start  19:53:43    Idle          
meerane1 BGP      ebgp     start  19:53:43    Idle          
moehne003 BGP      ebgp     start  19:53:43    Idle          
moehne1  BGP      ebgp     start  19:53:43    Idle          
moehne103 BGP      ebgp     start  19:53:43    Idle          
muenchen1 BGP      ebgp     start  19:53:43    Idle          
muenchen4 BGP      ebgp     start  19:53:43    Idle          
muenster1 BGP      ebgp     start  19:53:43    Idle          
muensterlandFusselkater BGP      ebgp     start  19:53:43    Idle          
mueritz_bgp1 BGP      ebgp     start  19:53:43    Idle          
nordwest1 BGP      ebgp     start  19:53:43    Idle          
nordwest2 BGP      ebgp     start  19:53:43    Idle          
nordwest3 BGP      ebgp     start  19:53:43    Idle          
ostholstein1 BGP      ebgp     start  19:53:43    Idle          
paderborn01 BGP      ebgp     start  19:53:43    Idle          
paderborn02 BGP      ebgp     start  19:53:43    Idle          
pinneberg BGP      ebgp     start  19:53:43    Idle          
rhein_neckar BGP      ebgp     start  19:53:43    Idle          
rsk1     BGP      ebgp     start  19:53:43    Idle          
rheinufer1 BGP      ebgp     start  19:53:43    Idle          
rheinufer3 BGP      ebgp     start  19:53:43    Idle          
ruhrgebiet1 BGP      ebgp     start  19:53:43    Idle          
trier1   BGP      ebgp     start  19:53:43    Idle          
trier2   BGP      ebgp     start  19:53:43    Idle          
troisdorf1 BGP      ebgp     start  19:53:43    Idle          
nrw1     BGP      ebgp     start  19:53:43    Idle          
nrw2     BGP      ebgp     start  19:53:43    Idle          
nrw3     BGP      ebgp     start  19:53:43    Idle          
nrw4     BGP      ebgp     start  19:53:43    Idle          
nrw5     BGP      ebgp     start  19:53:43    Idle          
waldheim1 BGP      ebgp     start  19:53:43    Idle          
weimar1  BGP      ebgp     start  19:53:43    Idle          
weimar2  BGP      ebgp     start  19:53:43    Idle          
westkueste1 BGP      ebgp     start  19:53:43    Idle          
westpfalz1 BGP      ebgp     start  19:53:43    Idle          
westpfalz2 BGP      ebgp     start  19:53:43    Idle          
schilcher1 BGP      ebgp     start  19:53:43    Idle          
wiesbaden1 BGP      ebgp     start  19:53:43    Idle          
wiesbaden2 BGP      ebgp     start  19:53:43    Idle          
wuppertal1 BGP      ebgp     start  19:53:43    Idle

Mit IPv6 gehts komischer weise schon.

# birdc6 show protocols
BIRD 1.5.0 ready.
name     proto    table    state  since       info
k_mast   Kernel   master   up     19:53:51    
device1  Device   master   up     19:53:51    
p_maintbl Pipe     master   up     19:53:51    => ebgp
p_ibgptbl Pipe     ebgp     up     19:53:51    => ibgp
p_freitbl Pipe     ibgp     up     19:53:51    => freifunk
unreachable_default Static   freifunk up     19:53:51    
static_ffue Static   ebgp     up     19:53:51    
local_ffue Static   freifunk up     19:53:51    
aachen1  BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
augsburg1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
bayreuth BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
berlin1  BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
berlin2  BGP      ebgp     start  19:53:51    Active        Socket: Connection closed
bielefeld1 BGP      ebgp     start  19:53:51    Active        Socket: Connection closed
bielefeld6 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
braunschweig1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
braunschweig2 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
bremen1  BGP      ebgp     up     19:53:54    Established   
bremen2  BGP      ebgp     up     19:53:55    Established   
bremen3  BGP      ebgp     up     19:53:55    Established   
darmstadt1 BGP      ebgp     up     12:24:05    Established   
darmstadt2 BGP      ebgp     up     19:53:55    Established   
diepholz1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
dreilaendereck1 BGP      ebgp     up     12:35:27    Established   
dreilaendereck2 BGP      ebgp     start  19:53:51    Active        Socket: Connection closed
dreilaendereck4 BGP      ebgp     start  19:53:51    Active        Socket: Connection refused
dresden1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
dresden2 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
flensburg1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
flensburg2 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
freiburg1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
fulda1   BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
gera_greiz1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
goettingen1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
guetersloh1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
guetersloh4 BGP      ebgp     start  19:53:51    Active        Socket: Connection closed
gueterslohbgp1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
gueterslohbgp2 BGP      ebgp     up     12:39:21    Established   
rhwdbgp1 BGP      ebgp     start  19:53:51    Active        Socket: Connection timed out
hamburg01 BGP      ebgp     up     05:54:04    Established   
hamburg02 BGP      ebgp     up     12:23:49    Established   
hamburg03 BGP      ebgp     start  06:58:48    Connect       Socket: Connection timed out
hennef1  BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
karlsruhe1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
karlsruhe2 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
kassel1  BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
kassel3  BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
koeln1   BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
kiel0    BGP      ebgp     start  19:53:51    Active        Socket: Connection timed out
kiel4    BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
leichlingen0 BGP      ebgp     start  19:53:51    Active        Socket: Connection refused
leipzig2 BGP      ebgp     start  11:12:25    Active        Socket: Connection closed
luebeck1 BGP      ebgp     up     19:53:54    Established   
luebeck2 BGP      ebgp     up     19:53:55    Established   
magdeburg1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
magdeburg2 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
mainz1   BGP      ebgp     up     19:53:54    Established   
mainz2   BGP      ebgp     start  19:53:51    Active        Socket: Connection refused
meerane1 BGP      ebgp     start  19:53:51    Active        Socket: Connection refused
moehne003 BGP      ebgp     start  19:53:51    Active        Socket: Connection closed
moehne1  BGP      ebgp     up     19:53:54    Established   
moehne103 BGP      ebgp     up     19:53:54    Established   
muenster1 BGP      ebgp     start  19:53:51    Active        Socket: Connection closed
muensterlandFusselkater BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
mueritz_bgp1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
ostholstein1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
paderborn01 BGP      ebgp     up     19:53:54    Established   
paderborn02 BGP      ebgp     up     19:53:54    Established   
pinneberg BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
rhein_neckar BGP      ebgp     start  19:53:51    Active        Socket: Connection closed
rsk1     BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
rheinufer1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
rheinufer3 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
ruhrgebiet1 BGP      ebgp     up     19:53:55    Established   
trier1   BGP      ebgp     up     00:49:45    Established   
trier2   BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
troisdorf1 BGP      ebgp     up     19:53:54    Established   
nrw1     BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
nrw2     BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
nrw3     BGP      ebgp     start  19:53:51    Active        Socket: Connection refused
nrw4     BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
nrw5     BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
weimar1  BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
weimar2  BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
westkueste1 BGP      ebgp     up     19:54:51    Established   
westpfalz1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out
westpfalz2 BGP      ebgp     start  00:44:38    Active        Socket: Connection reset by peer
wiesbaden1 BGP      ebgp     up     19:53:54    Established   
wiesbaden2 BGP      ebgp     up     19:53:55    Established   
wuppertal1 BGP      ebgp     start  19:53:51    Connect       Socket: Connection timed out

Auch Routen werden ganz viele angezeigt und ich kann auch via IPv6 z.B. über ULA Adressen auf Internet Dienste von z.B. Freifunk Paderborn zugreifen.

# birdc6 show route all | less
BIRD 1.5.0 ready.
2001:bf7:820::/44  via fec0::a:cf:0:6 on icvpn [hamburg01 05:55:01 from fec0::a:cf:0:3d] * (100) [AS44194i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 49009 44194
        BGP.next_hop: fec0::a:cf:0:6 fe80::8ca9:4cff:fe5b:d710
        BGP.local_pref: 100
                   via fec0::a:cf:0:6 on icvpn [gueterslohbgp2 12:39:48 from fec0::a:cf:0:85] (100) [AS44194i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 65533 44194
        BGP.next_hop: fec0::a:cf:0:6 fe80::8ca9:4cff:fe5b:d710
        BGP.local_pref: 100
                   via fec0::a:cf:0:5 on icvpn [dreilaendereck1 12:35:59 from fec0::a:cf:0:be] (100) [AS44194i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 65043 44194
        BGP.next_hop: fec0::a:cf:0:5 fe80::ac49:aff:fecd:883e
        BGP.med: 0
        BGP.local_pref: 100
                   via fec0::a:cf:0:6 on icvpn [darmstadt1 12:24:05 from fec0::a:cf:0:da] (100) [AS44194i]
        Type: BGP unicast univ
        BGP.origin: IGP
        BGP.as_path: 65038 44194
        BGP.next_hop: fec0::a:cf:0:6 fe80::345f:9fff:fe2c:cf99
        BGP.local_pref: 100
...

Woran liegts bei IPv4? Unsere bird.conf liegt hier: http://pastebin.com/C9ETV5Eb

11

Ich würde Dir (und anderen) dringend die Puppet-Skripte der FFNord-Kollegen (siehe GitHub - ffnord/ffnord-puppet-gateway: Deploy and manage your Freifunk community gateway, mostly compatible with Gluon.) ans Herz legen. Ich habe damit mueritzbgp1 und gueterslohbgp2 aufgesetzt (okay, faktisch mit unserem Fork, GitHub - ffgtso/ffgt-gln-gw-puppet: Forked off ffgtso/ffnord-puppet-gateway due to incompatible goals), und es macht seine Sache gut. Insbesondere muß man sich nicht mehr auf die Suche nach Quirks in der lokalen BGP-Config machen, i. d. R. fällt da 'ne sinnvolle Config raus, inkl. Updates der icvpn-Repos per cron.

Sprich: man hat einen schnellen Erfolg, und kann das »wie geht das eigentlich« auf später verschieben. (Vielleicht parallel zur dn42-Teilnahme, wo man dann mit BGP und Co. rumexperimentieren kann, ohne sein Freifunk-Setup zu torpedieren ;))

12

Nenn mich altmodisch, aber ich fühle mich besser wenn ich Configs zu „Fuß“ erledige und wenig via automatisierter Scripte. Zumal ich mit Scripten eh auf Kriegsfuß hier und da stehe. Zudem habe ich Angst das mir sowas meine jetzige Config zerschießt auf meinen Gateways und ich danach vielleicht noch mehr Arbeit habe als jetzt nur mit diesem einem Problem. Kann man sich vielleicht mal anschauen wenn ein neues Gateway ansteht, aber bislang brauchen wir keines, da 3 Stück für 170 Knoten völlig ausreichen sind. Zumal sich die Last eh nicht aufteilt und fast alles Knoten nur ein Gateway auswählen.

Deswegen hier auch nur explizit warum es mit Bird6 scheinbar alles klappt nur mit bird nicht und keine Router ausgetauscht werden. Das Log sagt nicht viel außer diesem hier.

Aug  3 10:49:08 uegw1 bird: KRT: Received route 0.0.0.0/0 with unknown ifindex 2
Aug  3 10:49:18 uegw1 bird: KRT: Received route 0.0.0.0/0 with unknown ifindex 2
Aug  3 10:49:28 uegw1 bird: KRT: Received route 0.0.0.0/0 with unknown ifindex 2
13

Ok. Jetzt laufen auch die v4 Routen. Zu mindestens kann ich vom Gateway andere Freifunk Hosts erreichen. Der Fehler war das ich bird keine Interfaces mitgegeben habe. Ein birdc show interfaces zeigt nix an.

root@uegw1:/etc/bird# traceroute pads.ffpb
traceroute to pads.ffpb (10.132.250.173), 30 hops max, 60 byte packets
 1  10.207.0.231 (10.207.0.231)  22.096 ms  22.063 ms  22.046 ms
 2  10.132.250.173 (10.132.250.173)  33.955 ms  34.553 ms  34.556 ms
root@uegw1:/etc/bird#

Aber jetzt fehlt noch die Kür. Da wir ja das Schweden VPN Modell fahren, gehen eingehende Pakete aus dem MeshVPN über die Routing Table 42 in den OpenVPN Schweden Tunnel.

traceroute to pads.ffpb (10.132.250.173), 30 hops max, 60 byte packets
 1  uegw1.ffue (10.134.10.1)  62.433 ms  63.866 ms  64.507 ms
 2  10.7.0.1 (10.7.0.1)  106.265 ms  106.603 ms  106.846 ms
 3  * * *
 4  * * *
 5  *^C
marc-andre@amd-x4:~$

Nun gibt es aber im BGP ja kein default Gateway sondern bird passt ja quasi Live die Kernel Routing Tabelle an, soweit ich das verstanden haben. Ein ip route show erschlägt mich auch quasi mit Routen.

Im Grunde müsste jetzt das was bird an routen ermittelt aber nicht in der default kernel Tabelle landen, sondern in der Table 42 auf diesem einen Gateway, so das aufschlagende Pakete dort ins icvpn geleitet werden. Jemand ne Idee wie ich bird sage, schmeiß die Routen nicht in die default kernel Tabelle sondern in die Table 42?

14

wir haben das bei uns im protocol Kernel:

kernel table 42;
15

Danke! Du bist mein Held.

traceroute to pads.ffpb (10.132.250.173), 30 hops max, 60 byte packets
 1  ffuegw3.ffue (10.134.30.1)  31.233 ms  31.245 ms  31.339 ms
 2  uegw1.ffue (10.134.10.1)  46.685 ms  46.912 ms  46.894 ms
 3  10.207.0.231 (10.207.0.231)  51.507 ms  52.902 ms  52.942 ms
 4  10.132.250.173 (10.132.250.173)  69.328 ms  69.629 ms  71.624 ms
marc-andre@amd-x4:~$
16

Fortsetzung der Diskussion von Wie lautet meine IP Service: ifconfig.ffhh:

Also, bgp1 nutzt bei uns z. Zt. zwecks Test den Exit via FFRL (an bgp1 hängt aber effektiv auch noch nix der FFGT-Infrastruktur dran), das »Problem« haben wir also auch.

Mit Tagging arbeite ich hier z. Zt. gar nichts mehr, solange ich es vermeiden kann. Mit ip rule läßt sich recht viel machen, und es ist dann auch relativ übersichtlich, was wohin geht; mit ip rule add to 10.0.0.0/8 lookup freifunk und ip rule add from 10.255.0.0/16 lookup freifunk z. B., daß alles an 10/0 und alles von 10.255/16 über die Freifunk-Routingtabelle gehen soll. Hilfreich auch: ip rule add iif icvpn lookup freifunk; nur für SNAT habe ich noch iptables-Regeln:

root@bgp1:~# iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 1288M packets, 152G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 1284M packets, 151G bytes)
 pkts bytes target     prot opt in     out     source               destination         

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

Chain OUTPUT (policy ACCEPT 477M packets, 36G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 478M packets, 36G bytes)
 pkts bytes target     prot opt in     out     source               destination         
root@bgp1:~# iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 73727 packets, 8759K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 2651 packets, 172K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 70266 packets, 4273K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 78524 packets, 4904K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  872 65860 SNAT       all  --  *      icvpn  !10.0.0.0/16          10.0.0.0/16          to:10.207.0.136
   13  2248 SNAT       all  --  *      eth1    10.255.0.0/16        0.0.0.0/0            to:192.251.226.114
 1392  212K SNAT       all  --  *      ffrl-+  10.255.0.0/16        0.0.0.0/0            to:185.66.193.64
17

Ich stelle mich jetzt mal Dumm.

Raus gehts so bei uns so:

PC > Knoten > MeshVPN > Tag 0x1 > GW1 {GW2 > GW1, GW3 > GW1} > Table 42 > icvpn Interface > Ziel.

Funktioniert auch. Aber nicht zu allen Zielen.

Paderborn geht:

traceroute to start.ffpb (10.132.250.250), 30 hops max, 60 byte packets
 1  uegw1.ffue (10.134.10.1)  34.758 ms  36.534 ms  36.883 ms
 2  10.207.0.231 (10.207.0.231)  48.884 ms  49.575 ms  49.964 ms
 3  10.132.250.250 (10.132.250.250)  63.493 ms  63.882 ms  66.600 ms

traceroute to start.ffpb (fdca:ffee:ff12:a250::250) from fd83:e002:c8a1:0:902:9d9:79a9:1473, 30 hops max, 24 byte packets
 1  ffuegw2.ffue (fd83:e002:c8a1::2)  65.47 ms  30.932 ms  31.272 ms
 2  uegw1.ffue (fd83:e002:c8a1::1)  34.807 ms  36.573 ms  35.325 ms
 3  fdca:ffee:ff12:a251::1 (fdca:ffee:ff12:a251::1)  48.393 ms  47.973 ms  51.513 ms
 4  fdca:ffee:ff12:a250::250 (fdca:ffee:ff12:a250::250)  73.518 ms  61.476 ms  61.409 ms

Andere Ziele wiederum nicht zum Beispiel DNS Gütersloh:

traceroute to 10.255.1.1 (10.255.1.1), 30 hops max, 60 byte packets
 1  uegw1.ffue (10.134.10.1)  43.627 ms  43.981 ms  44.322 ms
 2  10.207.0.136 (10.207.0.136)  44.457 ms !H  44.846 ms !H *

Bei der Rückroute stehe ich jetzt auf dem Schlauch. Denke das Pakete die über das ICVPN Tinc Interface aufschlagen ja eigentlich Automagisch zum Interface br-ffue geleitet werden müssten.

# ip route
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

ip route show table 42 = http://pastebin.com/9R1eVgrw

18

Treffer :wink: Die Kiste ist nicht mehr (VM terminiert), icvpn-meta habe ich grade aktualisiert, aber das klemmt wg. vorigem pull-request. Naja, irgendwann »RSN« wird die 10.255.128.53 hoffentlich erreichbar sein.
Wegen der Umstellung von den handgeklöppelten Kisten aus 2014 (gw01, 10.255.1.1, und gw04, 10.255.4.1), die damals halt alles machten, auf ein saubereres Setup (welches basierend auf wiederholbaren Abläufen installiert wird), könnte es sein, daß außer 10.255.255.1 derzeit nix via ICVPN geht. (gw04 und bgp1 announcen ggf. beide 10.255.0.0/16, haben aber keine Verbindung untereinander; gw04 wird für IPv6 aus Berlin benötigt und wird daher b. a. w. nicht mehr angefaßt).

Nimm zum testen Müritz, das sollte sauber tun (10.169.1.1).

[quote]
Bei der Rückroute stehe ich jetzt auf dem Schlauch. Denke das Pakete die über das ICVPN Tinc Interface aufschlagen ja eigentlich Automagisch zum Interface br-ffue geleitet werden müssten.[/quote]

Automagisch passiert nur wenig. Was sagt „ip rule show“, was "iptables -L -n -v -t mangle"? Sofern Du dem System nicht sagst, es solle eingehende Pakete X, Y, Z anders behandeln, geht’s über die default Table (ip route show).

10.255.255.1 ping derzeit 10.134.10.1; mach’ doch mal ‚n tcpdump -n -i <if> host 10.255.255.1 für mit eth0, tun0, icvpn und guck‘ mal, wo die Antworten rausgehen :wink:

Ja, mehrere Routingtabellen sind … Spaß pur :wink:

19

Tut.

traceroute to 10.169.1.1 (10.169.1.1), 30 hops max, 60 byte packets
 1  ffuegw3.ffue (10.134.30.1)  30.328 ms  30.694 ms  31.096 ms
 2  uegw1.ffue (10.134.10.1)  41.314 ms  41.698 ms  41.696 ms
 3  10.169.1.1 (10.169.1.1)  63.636 ms  64.024 ms  65.524 ms

root@uegw1:/etc/bird# ip rule show
0:    from all lookup local 
32765:    from all fwmark 0x1 lookup 42 
32766:    from all lookup main 
32767:    from all lookup default 
root@uegw1:/etc/bird# iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 46M packets, 12G bytes)
 pkts bytes target     prot opt in     out     source               destination         
1653K  235M MARK       all  --  br-ffue *       0.0.0.0/0            0.0.0.0/0            MARK set 0x1

Chain INPUT (policy ACCEPT 43M packets, 10G bytes)
 pkts bytes target     prot opt in     out     source               destination         

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

Chain OUTPUT (policy ACCEPT 104M packets, 18G bytes)
 pkts bytes target     prot opt in     out     source               destination         
 213K   17M MARK       udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:53 MARK set 0x1
  534 32893 MARK       tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            tcp dpt:53 MARK set 0x1

Chain POSTROUTING (policy ACCEPT 107M packets, 20G bytes)
 pkts bytes target     prot opt in     out     source               destination         
root@uegw1:/etc/bird#

root@uegw1:/etc/bird# 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:44:43.165776 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22490, seq 690, length 18
18:44:44.175829 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22490, seq 691, length 18
18:44:45.182176 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22490, seq 692, length 18
18:44:46.190718 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22490, seq 693, length 18
^C
4 packets captured
205 packets received by filter
0 packets dropped by kernel

Deine Pings gehen in ICVPN rein und gehen auf ETH0 wieder raus. :frowning:

Aber das passt doch nicht zusammen dann.

root@uegw1:/etc/bird# ip route
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

Der Kernel weiß doch das 10.134.0.0/16 an br-ffue anliegt. Wieso jagt er die jetzt nach eth0 raus?

20

[quote=„Freifunker, post:19, topic:6672“]
Tut.[/quote]

Verstehe ich übrigens nicht :wink:

root@mueritzbgp1:~# 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  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
root@mueritzbgp1:~# traceroute -s 10.207.0.138 -m 5 10.134.30.1
traceroute to 10.134.30.1 (10.134.30.1), 5 hops max, 60 byte packets
 1  uegw1.icvpn (10.207.0.18)  17.665 ms  18.087 ms  18.109 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Auch spannend:

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)  16.156 ms  16.557 ms  16.585 ms
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  * * *

Das ist schon sonderbar, nur directly connected (aus 10.207/16) tut.

Probier’ mal ip rule add iif icvpn lookup 42.

Also mit allem, was nicht 10.207 als Quelle ist, gibt’s schein’s Probleme. Was hast Du in iptables -L -n -v -t nat stehen?

Nachtrag: lt. mangle taggst Du alles, was: a) über br-ffue reinkommt (von 0/0 nach 0/0), b) lokal erzeugte UDP-Pakete mit Zielport 53 (von 0/0 nach 0/0) über eth0 — hä?

Lt. ip rule routest Du alles, was mit 0x1 getaggt wurde, gemäß Tabelle 42. Und in Tabelle 42 fehlt Dir der Eintrrag 10.134.0.0/16 dev br-ffue proto kernel scope link src 10.134.10.1 … Damit fällt, da kein from all fwmark 0x1 unreachable hinter from all fwmark 0x1 lookup 42 vorhanden ist, das Ziel 10.134.10.1 durch die Tabelle 42 durch nach main. Und in main ist default via 31.214.242.1 dev eth0 … Warum allerdings 10.134.0.0/16 dev br-ffue proto kernel scope link src 10.134.10.1 in main nicht greift, verstehe ich grade noch nicht …

Try:

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