IC-VPN

Aus wiki.freifunk.net
Zur Navigation springenZur Suche springen
VPN connections (2007/10/29)
VPN connections (2009/02/09)

Das Freifunk-InterCity-VPN verbindet die autonomen Systeme der Freifunk-Netze der einzelnen Communities durch ein vermaschtes VPN unter der Verwendung von BGP miteinander.

Realisierung

Die Verbindungen unterhalb der Communities werden über Tinc als VPN-Tunnel bereitgestellt, worauf BGP als Routing-Protokoll für den Austausch der Routen zuständig ist. Dazu wird ein Router mit Tinc und einem BGP-Daemon (z.B Quagga, bird) ausgestattet und an das VPN angebunden. Der Router kann dann mit anderen über das VPN erreichbaren Routern peeren und die Subnetze der eigenen Stadt per BGP bekanntgeben. Da die unterschiedlichen Communities sich eigenständige IP-Bereiche in der IP-Liste ausgesucht haben, sollte es hierbei nicht zu kollidierenden Announcements kommen. BGP ist in erster Linie ein Filtermechanismus, der es ermöglicht zu entscheiden welche IP-Bereiche man von welchem Peering-Partner haben bzw. nicht haben möchte. Sollten also doch mal Konflikte auftreten, so kann man das Routing zwischen der eigenen Stadt und anderen Städten sehr gezielt steuern.

Für eine redundante Anbindung empfiehlt es sich bis zu zwei VPN-Server pro Community einzurichten.

Als Transfernetz dient 10.207.0.0/16, mit grober Einteilung 10.207.LAND.STADT. Als Transfernetz für IPv6 dient fec0::a:cf:0:0/96 (hexadezimale Repräsentation von 10.207.0.0/16), mit grober Einteilung fec0::a:cf:LAND:STADT. Bei IPv6 bitte beachten, dass es sich um hexadezimal Zahlen handelt => 10 = A, etc.!

Zuerst eine IP-Adresse (siehe unten stehende Liste – Netzübersicht) und AS-Nummer registrieren. Bei der Gelegenheit gleich die unten stehende Beispielkonfiguration mit euren Werten erweitern.

IC-VPN/Infopage (nicht mehr aktuell)

Stand der Vernetzung

Status

BGP Looking Glasses finden sich bei

Smokeping-Installation finden sich bei

Es existiert zudem ein WHOIS-Server, der auf den Daten aus icvpn-meta aufbaut. 

whois -h freifunk.draic.info 2001:bf7:110::f00
whois -h freifunk.draic.info AS65056
whois -h freifunk.draic.info 10.8.1.2
whois -h freifunk.draic.info ffhl

(Ankündigung durch tcatm: https://forum.freifunk.net/t/ein-kleiner-whois-service-fur-freifunk/1502)

Stand August 2018 scheint freifunk.draic.info offline zu sein, Alternativen: whois -h node2.ff3l.net, whois -h whois.freifunk.xyz [...]

Mailinglist

There is a mailinglist [1] for all operators to make the coordination of new peerings easier.

Please subscribe to it and send a brief email to introduce yourself.

Tinc einrichten

Tinc einrichten

BGP Einrichten

Wie in der Einleitung schon erwähnt wurde, kann der Routenaustusch zwischen den Netzwerken (BGP) mittels bird oder quagga realisiert werden.

Ein Teil der Konfiguration musst du selbstverständlich an deine Community anpassen. Ein anderer Teil, nämlich der, der IP-Adressen und AS-Nummern von anderen enthält, lässt sich aber sehr gut automatisch generieren. Dazu gibt es das Repository https://github.com/freifunk/icvpn-meta, in dem du eine neue Datei mit deinen eigenen Werten anlegst und einen Pull-Request stellst, sowie die Scripte in https://github.com/freifunk/icvpn-scripts, um daraus die entsprechenden Configs zu bauen. Das könnte etwa so aussehen: 

cd /var/lib
git clone https://github.com/freifunk/icvpn-meta
cd /opt
git clone https://github.com/freifunk/icvpn-scripts
cat > /etc/cron.hourly/icvpn-update
#!/bin/sh

DATADIR=/var/lib/icvpn-meta

cd /etc/tinc/icvpn
git pull -q

cd "$DATADIR"
git pull -q
^D

Das Script am Ende aktualisiert stündlich das meta-Repo. Das alleine bringt natürlich noch nichts, der Rest hängt aber davon ab, ob du Quagga oder Bird einsetzen möchtest.

Quagga

Dies ist eine Beispielkonfiguration für quagga.

/etc/quagga/bgpd.conf.head_v4 

!
hostname [HOSTNAME]
password [SOMETHING]
!
router bgp [ASN]
 bgp router-id 10.207.X.Y

! Here you can specify the networks you are using.
 network 10.20.30.40/32

 neighbor icvpn4 peer-group
 neighbor icvpn4 soft-reconfiguration inbound
 neighbor icvpn4 prefix-list icvpn4 in
 neighbor icvpn4 prefix-list icvpn4 out

/etc/quagga/bgpd.conf.head_v6 

 address-family ipv6

! Here you can specify the networks you are using.
 network fec0:123::/128

 neighbor icvpn6 peer-group
 neighbor icvpn6 activate
 neighbor icvpn6 prefix-list icvpn6 in
 neighbor icvpn6 prefix-list icvpn6 out

/etc/quagga/bgpd.conf.foot 

! exit-address-family
!

  ip prefix-list icvpn4 description *** ICVPN prefix-list for internal and public IP address space ***
  !
  ! deny the default gateway route
  !
  ip prefix-list icvpn4 seq 10 deny 0.0.0.0/0
  !
  ! permit RFC1918 networks
  !
  ip prefix-list icvpn4 seq 20 permit 10.0.0.0/8 le 24
  ip prefix-list icvpn4 seq 21 permit 172.16.0.0/12 le 24
  ip prefix-list icvpn4 seq 22 permit 192.168.0.0/16 le 24
  !
  ! permit this 6/8 network as it is almost unused in the wild.
  !
  ip prefix-list icvpn4 seq 30 permit 6.0.0.0/16 le 32
  ip prefix-list icvpn4 seq 31 permit 6.0.0.0/8 le 24
  !
  ! permit 104/8 and 105/8
  !
  ip prefix-list icvpn4 seq 40 permit 104.0.0.0/8 le 24 ge 9
  ip prefix-list icvpn4 seq 41 permit 105.0.0.0/8 le 24 ge 9
  !
  !
  ! permit public IP ranges which will be announced in the ICVPN
  !
  ip prefix-list icvpn4 seq 501 permit 77.87.48.0/21
  ip prefix-list icvpn4 seq 502 permit 78.41.112.0/22
  ip prefix-list icvpn4 seq 503 permit 188.40.227.0/24
  ip prefix-list icvpn4 seq 504 permit 193.238.156.0/22
  !
  ! deny all others
  !
  ip prefix-list icvpn4 seq 999 deny 0.0.0.0/0 le 32
!
 ipv6 prefix-list icvpn6 permit 2000::/3 le 64
 ipv6 prefix-list icvpn6 deny any
!
log file /var/log/quagga/bgpd.log
!
!log stdout

Die access-list ist so gewählt das nur ausgewählte Netze übernommen werden, bei BGP handelt es sich um Routing Protokoll das über den AS Border hinaus arbeitet. D.h. sollte man jedem Announcment grundsätzlich Misstrauen. Es könnte durchaus passieren das ein Admin bei sich einen Filter falsch setzt und euch plötzlich den Globalen Routing Table announciert. Das macht auf schwachen Kisten keine große Freude. :)

Um diese Schnipsel zusammen mit den dynamischen Daten aus dem Meta-Repo zu benutzen, erweitern wir das oben angelegt Cron-Script wie folgt: 

cat >> /etc/cron.hourly/icvpn-update
sudo -u nobody /opt/icvpn-scripts/mkbgp -f quagga -4 -s "$DATADIR" -x <DEINE_COMMUNITY> -d icvpn4 -p icvpn_ > /tmp/bgpd.conf.v4
sudo -u nobody /opt/icvpn-scripts/mkbgp -f quagga -6 -s "$DATADIR" -x <DEINE_COMMUNITY> -d icvpn6 -p icvpn_ > /tmp/bgpd.conf.v6
cat /etc/quagga/bgpd.conf.head_v4 /tmp/bgpd.conf.v4 /etc/quagga/bgpd.conf.head_v6 /tmp/bgpd.conf.v6 /etc/quagga/bgpd.conf.foot > /etc/quagga/bgpd.conf

# reload quagga (TODO: how do you do this?)

Das -x <DEINE_COMMUNITY> musst du natürlich entsprechend anpassen und sorgt dafür, dass du keine Verbindungen zu deinen eigenen Routern aufbaust. Da sie zum selben AS gehören sollten hier andere Filterregeln und iBGP benutzt werden.

/etc/quagga/zebra.conf 

hostname HOSTNAME
password PASSWORT
enable password PASSWORT

Ist eigentlich mehr oder weniger leer, startet aber nicht ohne.

Die Konfiguration kann auch interaktiv über vtysh erledigt werden, dadurch ist kein restart des Quagga Prozesses nötig. Dabei hilft folgendes snipplet: 

telnet localhost bgpd

enable
configure terminal
router bgp <as-number>

neighbor 10.207.0.x remote-as <as-number>
neighbor 10.207.0.x peer-group icvpn4
neighbor 10.207.0.x description <bla>

neighbor  fec0::a:cf:0:xx remote-as  <as-number>
neighbor  fec0::a:cf:0:xx description XXX
no neighbor  fec0::a:cf:0:xx activate
address-family  ipv6
neighbor  fec0::a:cf:0:c4 activate
neighbor  fec0::a:cf:0:c4 soft-reconfiguration  inbound

write file

bird

Einige jüngere Freifunk-Communities setzen auf bird statt quagga. Im Netz findet man einige gute Konfigurationsbeispiele:

Prinzipiell existiert unter Debian Wheezy ein Software-Paket für den Routing-Dämonen bird (Version 1.3.7). Die angebotene Version ist jedoch fehlerhaft. Quelladressen für Routen werden in bestimmten Fällen nicht korrekt auf Routing-Tabellen des Kernels übertragen. Glücklicherweise beheben neuere Versionen das Problem (wenigstens ab Version 1.4.5). Die jeweils letzte stabile Version lässt sich über die Web-Seite des Projekts beziehen. Im Folgenden ist eine Konfigurations-Variante ausgehend vom Hamburger Beispiel wiedergegeben.

Bird kommt in zwei Varianten: einer für IPv4 (bird) und einer für IPv6 (bird6). Die beiden Dämonen werden unabhängig voneinander konfiguriert. Die Konfiguration für IPv4 schreiben wir in die Datei /etc/bird/bird.conf. Der Platzhalter <router-id> in dieser Datei bezeichnet eine eindeutige 32 Bit-Kennung des Routers, für welche wir die IPv4-Adresse unseres Gateways innerhalb des Transportnetzes verwenden (z.B. 10.207.0.75). Die Angabe hat keinen Einfluss auf das Routing selbst. Der Platzhalter <freifunk-ipv4> steht die IPv4-Adresse unserer Routers innerhalb des eigenen Freifunk-Netzes (z.B. 10.119.0.2). Anstelle des Platzhalter <ownas> tragen wir unsere zuvor registrierte AS-Kennziffer ein (z.B. 65043). Der Platzhalter <freifunk-ipv4-net> steht für unser lokales Freifunk-Netz (z.B. 10.119.0.0/16).

Im statischen Konfigurationsblock “static_ff3l” geben wir an, dass wir keine fremden Routen für unser eigenes Netz akzeptieren. Im statischen Block “ff3l_local” spezifizieren wir, dass alle Pakete über die Schnittstelle <mesh-vpn-interface> geleitet werden sollen. Die Vorlagen “locals” und “peers” dienen der bequemen Konfiguration von internen (d.h. innerhalb des eigenen Freifunk-Netzes) und externen (d.h. außerhalb des eigenen Freifunk-Netzes) Routern, mit denen Routen ausgetauscht werden sollen. Zuletzt lesen wir weitere Konfigurationsdateien aus dem Verzeichnis /etc/bird/bird.d ein. Dort werden wir später die Konfiguration der "locals" und “peers” hinterlegen. 

router id <router-id>;
define ownip = <freifunk-ipv4>;
define ownas = <ownas>;

table ibgp; # internal BGP peerings
table ebgp; # external (icvpn) BGP peerings
table freifunk; # kernel table 42 for routing from ff network

### functions ###

# own network
function is_self_net() {
    return (net ~ [ <freifunk-ipv4-net>+ ]);
}

# freifunk ip ranges in general
function is_freifunk() {
  return net ~ [ 10.0.0.0/8+,
    172.16.0.0/12+,
    104.0.0.0/8+
  ];
}

### kernel ###

# synchronize from bird to main kernel routing table
# nothing in the other direction
protocol kernel k_mast {
    scan time 10;
    import none;
    export filter {
        krt_prefsrc = ownip;
        accept;
    };
};

# this pseudo-protocol watches all interface up/down events
protocol device {
    scan time 10;
};

### pipes ###

# sync nothing from main routing table to ebgp
# sync routes (not own network) from ebgp to main routing table
protocol pipe p_maintbl {
    peer table ebgp;
    import where !is_self_net();
    export none;
};

# sync routes (not own network) from ebgp to ibgp
# sync routes (all) from ibgp to ebgp
protocol pipe p_ibgptbl {
  table ebgp;
  peer table ibgp;
  import all;
  export where !is_self_net();
};

# sync routes (freifunk, dn42 and chaosvpn) from ibgp to freifunk
# sync nothing from freifunk to ibgp
protocol pipe p_freitbl {
  table ibgp;
  peer table freifunk;
  import none;
  export where is_freifunk();
};

### static routes ###

# if no openvpn is running, reject everything we do not have a route for
protocol static unreachable_default {
  route 0.0.0.0/0 reject;
  table freifunk;
};

protocol static static_ff3l {  
  route <freifunk-ipv4-net> reject;
  table ebgp;
};

# in hamburg we use a /18 from our /16 in the mesh
# create a route for that in freifunk table
protocol static local_ff3l {
  route <freifunk-ipv4-net> via "<mesh-interface>";  # mind and include the quotes
  table freifunk;
};

### 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;
};

# template for icvpn gateways of other cities
template bgp peers {
  table ebgp;
  local as ownas;
  # ignore routes for our own network
  import where (is_freifunk() && !is_self_net());
  export where is_freifunk();
  route limit 10000;
};

### additional configuration  ###

include "/etc/bird/bird.d/*";

Die Konfiguration für IPv6 schreiben wir in die Datei /etc/bird/bird6.conf. Die <router-id> (nicht zu verwechseln mit der IP-Adresse des Routers) ist hierbei identisch. Der Platzhalter <freifunk-ipv6> steht die IPv6-Adresse unserer Routers innerhalb des eigenen Freifunk-Netzes (z.B. fdc7:3c9d:b889:a272::2). Der Platzhalter <freifunk-ipv6-net> steht für unser lokales Freifunk-Netz (z.B. fdc7:3c9d:b889:a272:://64). Neben den Konfigurationsvorlagen “locals” und “peers” definieren wir eine weitere Vorlage “upstream”, welche dazu dient, Routen mit dem Router eines Providers auszutauschen. Zuletzt lesen wir wieder weitere Konfigurationsdateien aus dem Verzeichnis /etc/bird/bird.d ein. 

router id <router-id>;
define ownip = <freifunk-ipv6>;
define ownas = <ownas>;

table ibgp; # internal BGP peerings
table ebgp; # external (icvpn) BGP peerings
table freifunk; # kernel table 42 for routing from ff network

### functions ###

# own networks
function is_self_net() {
  return net ~ [ <freifunk-net-ipv6>+ ];
}

# freifunk ip ranges in general
function is_freifunk() {
  return net ~ [ fc00::/7{48,64},
    2001:bf7::/32+];
}

function is_default() {
  return net ~ [ ::0/0 ];
}

### kernel ###

# synchronize from bird to main kernel routing table
# nothing in the other direction
# (do not sync a default route we received to the main routing table
# as this might collide with the normal default route of the host)
protocol kernel k_mast {
  scan time 10;
  import none;
  export filter {
    krt_prefsrc = ownip;
    accept;
  };
};

# this pseudo-protocol watches all interface up/down events
protocol device {
    scan time 10;
};

### pipes ###

# sync nothing from main routing table to ebgp
# sync routes (not own network) from ebgp to main routing table
protocol pipe p_maintbl {
  peer table ebgp;
  import where !is_self_net();
  export none;
};

# sync routes (not own network) from ebgp to ibgp
# sync routes (all) from ibgp to ebgp
protocol pipe p_ibgptbl {
  table ebgp;
  peer table ibgp;
  import all;
  export where !is_self_net();
};

# sync routes (freifunk and default routes we got) from ibgp to freifunk
# sync nothing from freifunk to ibgp
protocol pipe p_freitbl {
  table ibgp;
  peer table freifunk;
  import none;
  export where is_freifunk() || is_default();
};

### static routes ###

# if no openvpn is running, reject everything we do not have a route for
protocol static unreachable_default {
  route ::/0 reject;
  table freifunk;
};

protocol static static_ff3l {  
  route <freifunk-net-ipv6> reject;
  table ebgp;
};

protocol static local_ff3l {
  route <freifunk-net-ipv6> via "<mesh-vpn-interface>"; # mind and include the quotes
  table freifunk;
};

### 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;
};

# template for icvpn gateways of other cities
template bgp peers {
  table ebgp;
  local as ownas;
  # ignore routes for our own network
  import where is_freifunk() && !is_self_net();
  export where is_freifunk() || (source = RTS_BGP);
  route limit 10000;
};

# template for upstream gateways
template bgp upstream from peers {
  # accept freifunk networks and default route
  import where (is_freifunk() || is_default()) && !is_self_net();
};

### additional configuration  ###

include "/etc/bird/bird6.d/*";

Um die Konfiguration für die Peers aus dem Meta-Repo automatisch zu erstellen, muss das Cron-Script, welches oben angelegt wurde, noch wie folgt erweitert werden: 

cat >> /etc/cron.hourly/icvpn-update
sudo -u nobody /opt/icvpn-scripts/mkbgp -4 -f bird -d peers -s "$DATADIR" -x <DEINE_COMMUNITY> > /etc/bird/bird.d/icvpn.conf
sudo -u nobody /opt/icvpn-scripts/mkbgp -6 -f bird -d peers -s "$DATADIR" -x <DEINE_COMMUNITY> -t berlin:upstream > /etc/bird/bird6.d/icvpn.conf

birdc configure > /dev/null
birdc6 configure > /dev/null
^D

Das -x <DEINE_COMMUNITY> musst du natürlich entsprechend anpassen und sorgt dafür, dass du keine Verbindungen zu deinen eigenen Routern aufbaust. Da sie zum selben AS gehören sollten hier andere Filterregeln und iBGP benutzt werden. Das -t berlin:icvpn_default weist der Community "berlin" ein anderes Template als icvpn zu, nämlich icvpn_default, welches auch Default-Routen akzeptiert.

Netzübersicht / Network Information

Eine aktuellere Tabelle, die aus dem icvpn-meta Repository generiert wird, fandet ihr unter: http://freifunk.draic.info/icvpn.txt (archiv: https://web.archive.org/web/20151103174952/http://freifunk.draic.info/icvpn.txt)

Um euch einzutragen, schickt einen Patch oder Pullrequest an das Repository: https://github.com/freifunk/icvpn-meta

Stadt / City AS IPv4 (Transfernetz / Transitnetwork) IPv6 (Site-Local) Admin Announciert / announces
Leipzig 65041 10.207.0.1 (vpn1) freifunk ÄD poelzi DOT org 104.61.0.0/16, 6.0.1.1/32, 10.61.0.0/16, 6.61.0.0/18
Leipzig 65041 10.207.0.2 (vpn2) fec0::a:cf:0:2/96 freifunk ÄD poelzi DOT org 104.61.0.0/16, 6.0.1.1/32, 10.61.0.0/16, 6.61.0.0/18
Leipzig 65041 10.207.255.1 (services ip) freifunk [ät] poelzi [döt] org
Monitoring Moehne 65057 10.207.0.120 (monitoringmoehne) fec0::a:cf:0:120/96 icvpn ÄD wg1337 DOT de
Weimar 1 65042 10.207.0.3 fec0::a:cf:0:3/96 freifunkATandi95.de 10.63.0.0/16
Weimar 2 65042 10.207.0.4 fec0::a:cf:0:4/96 freifunkATandi95.de 10.63.0.0/16
Berlin 44194 (peeringDB) 10.207.0.5 (vpn1) fec0::a:cf:0:5/96 noc at berlin.freifunk.net 10.31.0.0/16, 10.36.0.0/16, 10.230.0.0/16, 2001:bf7::/32 (in /44 chunks)
Berlin 44194 10.207.0.6 fec0::a:cf:0:6/96 noc at berlin.freifunk.net 10.31.0.0/16, 10.36.0.0/16, 10.230.0.0/16, 2001:bf7::/32 (in /44 chunks)
Erfurt 65099 10.207.0.9 stephan at freifunk-erfurt.de 10.99.0.0/16
Erfurt 65099 10.207.0.10 hipoosen at gmx.de 10.99.0.0/16
Hamburg 49009 10.207.0.61
10.207.0.62
10.207.0.63
10.207.0.64
10.207.0.65 		fec0::a:cf:0:31
fec0::a:cf:0:3e
fec0::a:cf:0:3f
fec0::a:cf:0:40
fec0::a:cf:0:41
Helgoland 65189 10.207.0.34 fec0::a:cf:0:22 10.189.0.0/18, 2a03:2267:4e16:01ad::/64
Rheinland0 65078 10.207.0.76 fec0::a:cf:0:4c/96 nomaster@chaosdorf.de, privat@herms-it.de
Rheinland1 65078 10.207.0.77 fec0::a:cf:0:4d/96 nomaster@chaosdorf.de, privat@herms-it.de
Rheinland2 65078 10.207.0.78 fec0::a:cf:0:4e/96 nomaster@chaosdorf.de, privat@herms-it.de
Ruhrgebiet1 65079 10.207.0.79 fec0::a:cf:0:9 adminz@freifunk-ruhrgebiet.de 10.105.0.0/16, 2a02:f98:0:25::/64, 2a02:f98:0:26::/64
Stuttgart 65045 10.207.0.11/12 albi !?
augsburg2 65050 10.207.0.68 soma 10.11.0.0/18
Diepholz 65501 10.207.1.12 fec0::a:cf:0:1a noc@freifunk-dh.de 10.213.0.0/16
Halle 65046 10.207.0.13 freifunk at 3dfxatwork dot de 104.62.0.0/16
Halle 65046 10.207.0.14 freifunk at 3dfxatwork dot de 104.62.0.0/16
Aurich 65047 10.207.0.15 simon.frerichs@gmail.com 188.40.227.0/24 + peering to dn42
Aurich 65047 10.207.0.16 (noch nicht online, siehe 10.207.0.15 ) simon.frerichs@gmail.com ....
Graz 42729, 65048 10.207.1.2 + 3 otti-ff ÄT graz.funkfeuer.at 193.33.150.0/23, 10.12.0.0/16
Augsburg 1 65050 10.207.0.17 fec0::a:cf:0:a/96 freifunk AT somakoma DOT de 10.11.0.0/18
Treuenbrietzen 65045 10.207.0.18 freifunk AT shony DOT de 10.24.0.0/22
Dresden 1 65051 10.207.0.19 fec0::a:cf:dd:1/96 freifunk AT freifunk-dresden DOT de 10.200.0.0/16, 10.201.0.0/16, fd11:11ae:7466::/48
Dresden 2
(reserviert) 		65051 10.207.0.20 fec0::a:cf:dd:2/96 freifunk AT freifunk-dresden DOT de 10.200.0.0/16, 10.201.0.0/16, fd11:11ae:7466::/48
Freiburg 1
(noch im Test) 		65060 10.207.0.21 fec0::a:cf:0:21/96 marcus AT wolschon DOT biz 104.60.0.0/16
diac24.net 64600 10.207.2.0 fec0::a:cf:ac:16 equinox AT diac24 DOT net 172.22.0.0/15, versch. IPv6
Basel 1
(im Aufbau) 		65090 10.207.5.1 openwireless ÄT skeps DOT ch 10.239.0.0/16
Hannover 1
(inaktiv) 		65511 10.207.0.22 info ÄT hannover.freifunk DOT net 10.2.0.0/16
Franken 65024 10.207.0.23 fec0::a:cf:0:17 tokkee 10.50.0.0/16
Franken 65024 10.207.0.24 fec0::a:cf:0:18 octo 10.50.0.0/16
NOT USED 65025 10.207.0.25
Nordwest 1 (ex OL) 65513 10.207.0.27 info@nordwest.freifunk.net 10.18.0.0/16
Nordwest 2 65513 10.207.0.38 info@nordwest.freifunk.net 10.18.0.0/16
Nordwest 3 65513 10.207.0.39 info@nordwest.freifunk.net 10.18.0.0/16
Bayreuth 65025 10.207.0.28 fec0::a:cf:0:19/96 nospam.freifunk@criede.de 10.195.0.0/16
ljubljana1
(kiberpipa.net) 		65023 10.207.3.23 fec0::a:cf:3:23/96 lowkey -> l0ki<at>frubsd<dot>org 10.14.0.0/16, 10.254.0.0/16, 2001:15c0:66e9::/48
Ljubljana 2 64768 10.207.3.30 fec0::a:cf:3:30/96 janprunk@gmail.com 172.22.168.0/25
Franken3 65024 10.207.0.31 info@freifunk-ansbach.de 10.50.0.0/16
Karlsruhe1 65081 10.207.0.214 fec0::a:cf:0:d6 info at freifunk-karlsruhe.de 10.214.0.0/16
Karlsruhe2 65081 10.207.1.214 fec0::a:cf:1:d6 info at freifunk-karlsruhe.de 10.214.0.0/16
Koblenz 65032 10.207.0.32 simonmail@gmx.de
Jena 1 65055 10.207.0.33 fec0::a:cf:3:33/96 post@freifunk-jena.de 10.17.0.0/16
Jena 2 65055 10.207.0.66 fec0::a:cf:3:66/96 post@freifunk-jena.de 10.17.0.0/16
Jena 3 65055 10.207.0.99 fec0::a:cf:3:99/96 post@freifunk-jena.de 10.17.0.0/16
Gütersloh Gateway 1 65533 10.207.0.132 fec0::a:cf:0:84 technik ät guetersloh.freifunk.net 10.255.0.0/16, fd42:ffee:ff12:aff::/64
Gütersloh BGP2 65533 10.207.0.133 fec0::a:cf:0:85 technik ät guetersloh.freifunk.net 10.255.0.0/16, fd42:ffee:ff12:aff::/64
Gütersloh Gateway 4 65533 10.207.0.134 fec0::a:cf:0:86 technik ät guetersloh.freifunk.net 10.255.0.0/16, fd42:ffee:ff12:aff::/64
Ostholstein 1 65152 10.207.0.135 fec0::a:cf:0:87 steffen_moeller@gmx.de 10.135.8.0/18, fd73:111:e824::/48
Gütersloh BGP1 65533 10.207.0.136 fec0::a:cf:0:88 technik ät guetersloh.freifunk.net 10.255.0.0/16, fd42:ffee:ff12:0aff::0/64
Rheda-Wiedenbrück BGP1 65502 10.207.0.137 fec0::a:cf:0:89 technik bei guetersloh.freifunk.net 10.234.0.0/16, fd42:ffee:ff13:0aea::/64
Müritz BGP1 65534 10.207.0.138 fec0::a:cf:0:8a wusel+ffmue ät uu.org 10.169.0.0/16, fd39:e4e3:eee1:0aa9::/64
Frankfurt 1 65026 10.207.0.35 info at ffm.freifunk.net 10.126.0.0/16
Chemnitz 1 65053 10.207.0.36 nemesis@chemnitz.freifunk.net 10.8.0.0/16
Schilcher 1 65054 10.207.0.51 robert.kiendl AT gmail DOT com 10.51.0.0/16
Kiel 0 65525 (10.207.0.52) peering v6-only fec0::a:cf:0:34 sargon AT toppoint.de 10.116.0.0/16, fda1:384a:74de::/48
Kiel 4 65525 (10.207.0.53) peering v6-only fec0::a:cf:0:35 sargon AT toppoint.de 10.116.0.0/16, fda1:384a:74de::/48
Goettingen 65527 10.207.0.65 fec0::a:cf:ab:01 freifunk AT cccgoe.de 10.109.0.0/16, fde6:36fc:c985::/48
Gronau 65526 10.207.0.60 fec0::a:cf:0:51 freifunk AT liztv.net 10.244.16.0/20, 10.244.48.0/20, fd16:3e14:ce68::/48 + 10.244.32.0/20 (Enschede)
Köln-Bonn und Umgebung 65528 10.207.0.57 fec0::a:cf:0:57/96 icvpn@kbu.freifunk.net 172.26.0.0/15
Bielefeld 1 65529 10.207.0.59 fec0::a:cf:0:59/96 Bodems 10.29.0.0/16, fdef:17a0:ffb1::/48, 2001:bf7:1320::/44, dn42
Bielefeld 4 65529 10.207.0.69 fec0::a:cf:0:69/96 Bodems 10.29.0.0/16, fdef:17a0:ffb1::/48, 2001:bf7:1320::/44
nrw1 (derzeit inaktiv) 65530 10.207.0.7 fec0::a:cf:0:7/96 kontakt@freifunk-nrw.de 10.0.0.0/16 10.45.0.0/16 10.52.0.0/16 10.69.0.0/16 10.76.0.0/16 10.79.0.0/16 10.82.0.0/16 10.92.0.0/16 10.103.0.0/16 10.144.0.0/16 10.146.0.0/16 10.147.0.0/16 10.151.0.0/16 10.154.0.0/16 10.221.0.0/16 10.156.0.0/16 10.206.0.0/16 10.224.0.0/16
nrw2 65530 10.207.0.8 fec0::a:cf:0:8/96 kontakt@freifunk-nrw.de 10.0.0.0/16 10.45.0.0/16 10.52.0.0/16 10.69.0.0/16 10.76.0.0/16 10.79.0.0/16 10.82.0.0/16 10.92.0.0/16 10.103.0.0/16 10.144.0.0/16 10.146.0.0/16 10.147.0.0/16 10.151.0.0/16 10.154.0.0/16 10.221.0.0/16 10.156.0.0/16 10.206.0.0/16 10.224.0.0/16
NRW3 65530 10.207.0.55 FIXME kontakt@freifunk-nrw.de
wuppertal1 65523 10.207.0.73 fec0::a:cf:0:71/96 felix@devtal.de 10.3.0.0/16, fda0:747e:ab29:e1ba::/64, 2a03:2260:1002::/56
wuppertal7 65523 10.207.0.80 fec0::a:cf:0:80/96 kontakt@freifunk-wuppertal.net 10.3.0.0/16, fda0:747e:ab29:e1ba::/64, 2a03:2260:1002::/56
wuppertal9 65523 10.207.0.81 fec0::a:cf:0:81/96 kontakt@freifunk-wuppertal.net 10.3.0.0/16, fda0:747e:ab29:e1ba::/64, 2a03:2260:1002::/56
Bremen 65196 10.207.0.196 fec0::a:cf:0:c4/96 vpn@bremen.freifunk.net 10.196.0.0/16
dreilaendereck1 65043 10.207.0.75 fec0::a:cf:0:be icvpn@freifunk-3laendereck.de 10.119.0.0/16, 2001:bf7:20::/64
dreilaendereck2 65043 10.207.0.74 fec0::a:cf:0:ba Pepto 10.119.0.0/16, 2001:bf7:20::/64
dreilaendereck3 65043 10.207.0.72 fec0::a:cf:0:bc BenLue 10.119.0.0/16, 2001:bf7:20::/64
dreilaendereck4 65043 10.207.0.71 fec0::a:cf:0:47 icvpn@freifunk-3laendereck.de 10.119.0.0/16, 2001:bf7:20::/44
mainz1 (Reserve) 65037 10.207.0.37 fec0::a:cf:0:25 admin bei freifunk minus mainz punkt de 10.37.0.0/16
mainz2 65037 10.207.1.37 fec0::a:cf:1:25 admin bei freifunk minus mainz punkt de 10.37.0.0/16
Freifunk Rhein Neckar (über nazco) 76118 10.207.0.142 fec0::a:cf:0:142 mail at nazco dot de 10.142.0.0/16 and 172.23.138.0/23
muenchen 1 65080 10.207.1.80 fec0::a:cf:1:80 info@muenchen.freifunk.net 10.80.0.0/16
muenchen 2 65080 10.207.2.80 fec0::a:cf:2:80 info@muenchen.freifunk.net 10.80.0.0/16
muenchen 3 65080 10.207.3.80 fec0::a:cf:3:80 info@muenchen.freifunk.net 10.80.0.0/16
muenchen 4 65080 10.207.4.80 fec0::a:cf:4:80 info@muenchen.freifunk.net 10.80.0.0/16
regensburg1 65190 10.207.1.90 fec0::a:cf:1:90 info@regensburg.freifunk.net 10.90.0.0/16
wiesbaden1 65036 10.207.0.56 fec0::a:cf:0:38 admin bei freifunk minus mainz punkt de 10.56.0.0/16
wiesbaden2 65036 10.207.1.56 fec0::a:cf:1:38 admin bei freifunk minus mainz punkt de 10.56.0.0/16
magdeburg1 65039 10.207.39.1 fec0::a:cf:39:1 andreas at netz39 dot de 10.139.0.0/16, fda9:026e:5805::/48
magdeburg2 65039 10.207.39.2 fec0::a:cf:39:2 andreas at netz39 dot de 10.139.0.0/16, fda9:026e:5805::/48
Flensburg 2 (im Aufbau) 65056 10.207.0.128 fec0::a:cf:0:11 felix at wlan-fabrik dot de 10.129.0.0/16, 2001:bf7:10::/44, fddf:bf7:10::/44
Darmstadt 65038 10.207.0.218 fec0::a:cf:0:218 icvpn@darmstadt.freifunk.net 10.223.0.0/16, fdca:ffee:ffda::/64
Darmstadt 65038 10.207.0.219 fec0::a:cf:0:219 icvpn@darmstadt.freifunk.net 10.223.0.0/16, fdca:ffee:ffda::/64
Trier 65022 10.207.0.220 fec0::a:cf:0:dc stefan@bka.li 10.172.0.0/16, fdca:ffee:fc0f::/64
Trier 65022 10.207.0.221 fec0::a:cf:0:dd stefan@bka.li 10.172.0.0/16, fdca:ffee:fc0f::/64
Braunschweig 1 65380 10.207.0.40 fec0::a:cf:0:28 sho+ffgw@stratum0.net 10.38.0.0/16, 2001:bf7:380::/44
Braunschweig 2 65380 10.207.0.41 fec0::a:cf:0:29 sho+ffgw@stratum0.net 10.38.0.0/16, 2001:bf7:380::/44
Westpfalz 1 65242 10.207.0.85 fec0::a:cf:0:55 info@freifunk-westpfalz.de 10.198.0.0/16, fdc6:c4fe:1de4::/48
Paderborn 65132 10.207.0.231
10.207.0.232 		fec0::a:cf:0:e7
fec0::a:cf:0:e8 		ops@paderborn.freifunk.net 10.132.0.0/16, fdca:ffee:ff12::/48
Muensterland 65251 10.207.0.43
10.207.0.44 		fec0::a:cf:0:43
fec0::a:cf:0:44 		info@freifunk-muenster.de 10.43.0.0/16, 2a03:2260:115::4/48
Waldheim 65210 10.207.0.45
10.207.0.46
10.207.0.47 		dnoelte@gmail.com 10.23.0.0/16
Amsterdam 65205 10.207.0.205 fec0::a:cf:0:205 wireless-amsterdam@lists.puscii.nl 10.205.0.0/16
Aachen 65077 10.207.0.114 fec0::a:cf:0:72 technik@freifunk-aachen.de 10.5.0.0/16, 2a03:2260:114::/48
Brandenburg 1 65147 10.207.0.100 fec0::a:cf:0:64 kontakt@freifunk-brandenburg.de 10.147.0.0/16, 2001:bf7:140::/44
Brandenburg 2 65147 10.207.0.101 fec0::a:cf:0:65 kontakt@freifunk-brandenburg.de 10.147.0.0/16, 2001:bf7:140::/44
Brandenburg 3 65147 10.207.0.102 fec0::a:cf:0:66 kontakt@freifunk-brandenburg.de 10.147.0.0/16, 2001:bf7:140::/44

DNS

FIXME: mention icvpn-meta/mkdns

Die meisten Communities haben eine eigene Domain (z.b. leipzig.freifunk.net). Einige Communities haben eine eigene TLD, die nicht im Internet verwendet wird. Damit diese im eigenen Netz genutzt werden können, muss ein weiterer DNS-Server eingerichtet werden. Wie dies geschieht, ist hier dokumentiert.

Abgerufen von „https://wiki.freifunk.net/index.php?title=IC-VPN&oldid=48812“