Hamburg/IPv4Uplink

Überblick

Der Freifunk Rheinland e.V. (FFRL) stellt uns die Möglichkeit zur Verfügung, über ihre Server unseren IPv4 Datenverkehr in Deutschland ins Internet zu routen. Die Rheinländer sind RIPE-Mitglied und haben Providerstatus, wodurch die Störerhaftung an dieser Stelle kein Problem darstellt.

Technische Umsetzung

Derzeit läuft der IPv4 Datenverkehr von gw13 und gw01 im Testbetrieb über die FFRL Server ins Internet. Hierzu wurden zwei GRE-Tunnel aufgesetzt, einer zum Berliner und einer zum Frankfurter Server des FFRL. FFHH steht ein /29 IPv4 Subnetz zur Verfügung, welches wir per BGP dem FFRL announcen (konkret: pro Gateway eine Hostroute aus diesem Netz). Von dort bekommen wir per BGP eine Default Route. Über je eine IP aus dem /29 Netz kann auf einem Gateway NAT für die Freifunk Clients gemacht werden.

Konfiguration

Die folgende Tabelle zeigt die Parameter, welche zur Konfiguration genutzt wurden.

Gateway	Gegenstelle	GRE Endpunkt FFRL	GRE Endpunkt FFHH	Tunnel IPv4 FFRL	Tunnel IPv4 FFHH	Tunnel IPv6 FFRL	Tunnel IPv6 FFHH
gw01: NAT IPv4 185.66.193.2	Berlin (BB-B.AK.BER.DE)	217.197.83.142	212.12.51.132	100.64.0.4/31	100.64.0.5/31	2a03:2260:0:e::1/64	2a03:2260:0:e::2/64
	Frankfurt (BB-A.FRA3.FRA.DE)	195.20.242.195	212.12.51.132	100.64.0.6/31	100.64.0.7/31	2a03:2260:0:f::1/64	2a03:2260:0:f::2/64
gw13: NAT IPv4 185.66.193.1	Berlin (BB-A.AK.BER.DE)	185.66.192.3	62.201.165.199	100.64.0.2/31	100.64.0.3/31	2a03:2260:0:4::1/64	2a03:2260:0:4::2/64
	Frankfurt (BB-B.FRA3.FRA.DE)	195.20.242.196	62.201.165.199	100.64.0.8/31	100.64.0.9/31	2a03:2260:0:5::1/64	2a03:2260:0:5::2/64

BGP Peers sind jeweils die Tunnel IPv4 Adressen von FFRL mit AS201701. Für das Peering können von uns die Netze 185.66.193.0/29 und 2a03:2260:112::/48 genutzt werden. Letzteres wird derzeit nicht eingesetzt, da für den IPv6 Internetzugang die uns zugeteilten /44 Netze aus dem Fundus des Freie Netzwerke e.V. genutzt werden. Hier wird das IC-VPN zum Peering genutzt.

Tunnel

Der GRE-Tunnel wird über die /etc/network/interfaces wie folgt konfiguriert.

 auto tun-ffrl-ber
 iface tun-ffrl-ber inet static
   address <Tunnel IPv4 Adresse>
   netmask 255.255.255.254
   pre-up ip tunnel add $IFACE mode gre local <Öff. IPv4 des Gateways> remote <Öff. IPv4 der Gegenstelle> ttl 255
   post-up ip link set $IFACE mtu 1426
   post-down ip tunnel del $IFACE
 
 iface tun-ffrl-ber inet6 static
   address <Tunnel IPv6 Adresse>
   netmask 64

Hinweis zur MTU: Per tracepath (Debian-Paket: iputils-tracepath) sollte die MTU zur Gegenstelle festgestellt werden. Hier wird davon ausgegangen, dass die minimale MTU auf dem gesamten Pfad zur Gegenstelle (path mtu) 1500 Byte ist. Dadurch ergibt sich durch den GRE-Header (24 Byte) eine MTU von 1426.

BGP

Für eBGP mit FFRL wird Bird genutzt. Die Konfiguration sieht folgendermaßen aus.

 function is_default() {
   return (net ~ [0.0.0.0/0]);
 }
 protocol direct {
   interface "tun-*";
   table ebgp;
 }
 protocol static uplink_hostroute {
   import all;
   table ebgp;
   route <NAT IPv4>/32 reject;
 }
 template bgp uplink {
   table ebgp;
   local as ownas;
   import where is_default();
   export where proto = "uplink_hostroute";
   next hop self;
   multihop 64;
 }
 protocol bgp ffrl_ber from uplink {
   source address <Tunnel IPv4 Adresse>;
   neighbor <Tunnel IPv4 Adresse der Gegenstelle> as <AS von FFRL>;
   default bgp_local_pref 200;
 }

Das untere Protokoll ffrl_ber wird wiederholt für jede der redundanten Verbindungen. Natürlich mit angepassten IP Adressen.

Die Zeile mit bgp_local_pref bevorzugt eine Verbindung (default bgp_local_pref ist 100, höher wird bevorzugt), auf gw13 ist dies die mit der niedrigeren Round Trip Time (RTT). Dies sagt allerdings nichts darüber aus, auf welchem der Tunnel (wenn mehr als einer konfiguriert ist) die angefragten Daten eingehen. Dies ist einzig die Entscheidung des Routings an der Gegenstelle. Aus diesem Grund (Hin- und Rückroute können unterschiedlich sein) muss Reverse Path Filtering aus sein.

Die Zeile multihop 64 stellt sicher, dass die TTL der Pakete, die über den Tunnel gehen, richtig konfiguriert ist. Damit dies funktioniert, müssen die Device Routes der Tunnelinterfaces über das protocol direct in die entsprechende Tabelle importiert werden.

NAT

Das statische Protokoll uplink_hostroute definiert die nach FFRL zu announcende IP Adresse (Host Route), welche von dem Gateway für NAT genutzt wird (nachfolgend wird diese durch den Platzhalter NAT IPv4 gekennzeichnet). Diese IP sollte localhost (lo) zugeordnet werden.

 ip addr add <NAT IPv4>/32 dev lo

Achtung: ifconfig zeigt die Adresse nicht an. Dafür ip a nutzen.

Für das NAT wird folgende iptables Regel angelegt.

 iptables -t nat -A POSTROUTING -o tun-ffrl+ ! -s <Subnetz Tunnel IPs> -j SNAT --to <NAT IPv4>

Das angegebene Subnetz sollte alle Tunnel IPs enthalten. Dies garantiert, dass bird eine Verbindung über den Tunnel bekommt und vom NAT ausgenommen ist.

Zusätzliches

Gleichzeitig sollte noch eine Regel angelegt werden, die eingehende Pakete auf den Tunnel mit dem entsprechenden Packet Mark versieht, damit diese Pakete vom Policy Routing erfasst werden.

 iptables -t mangle -A PREROUTING -i tun-ffrl+ -j MARK --set-xmark 0x1/0xffffffff

Damit der Import der Default Route von FFRL funktioniert, muss zusätzlich zur von FFHH genutzten IP Rule from all fwmark 0x1 lookup 42 eine Rule danach eingefügt werden. /etc/rc.local kann dafür folgendermaßen angepasst werden. Es wird keine Unreachable Default Route mehr angelegt, was auch in bird entsprechend deaktiviert werden muss.

 /sbin/ip rule add from all fwmark 0x1 unreachable
 /sbin/ip rule add from all fwmark 0x1 table 42

Oft gibt es Probleme mit TCP-Verbindungen zu bestimmten Hosts im Internet. Dies liegt an einer Filterung von ICMP Paketen, die für die Path MTU Discovery benötigt werden [[1]]. Da der Tunnel keine 1500 Byte MTU haben kann, ist dies notwendig.

 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu