Hamburg/Dienst mit öffentlicher IPv4

Aus wiki.freifunk.net
Zur Navigation springenZur Suche springen

Einleitung

Im Hamburger Netz nutzen wir IPv4 und v6. Da es bekanntlich hinreichend IPv6 Adressen gibt sind alle Geräte im Hamburger freifunk im öffentlichen IPv6 Internet erreichbar. Bei v4 sieht das etwas anders aus. Hier steht uns nur eine sehr begrenzte Anzahl öffentlicher Adressen zur Verfügung, weshalb wir NAT benutzen. Das bedeutet für v4 aber auch, dass ein Rechner nicht von außen erreichbar ist (jedenfalls wenn er die Verbindung nicht selbst angefordert hat), was das betreiben von Diensten behindert. Wie man einem Dienst eine öffentliche IPv4-Adresse zur Verfügung und sicher stellt, dass diese auch durch das freifunk-Netz geroutet wird, wird hier beispielhaft am Dienst speicher.hamburg.freifunk.net erläutert.

Wählen von IPv4-Adressen

Öffentlichen IPv4-Adresse

Zunächst schauen wir, was noch frei ist. Auskunft hierüber gibt der reverse DNS Eintrag unseres öffentlichen IPv4 Netzes in db.arpa.in-addr.193.96.224 im Abschnitt ; /32 Host Routes. Pick anything between .232 and .239.. Für speicher wählen wir die 237, machen den Eintrag aber erst am Ende, zusammen mit dem regulären DNS-Eintrag. Zusätzlich sollte man sicherheitshalber einmal pingen, um zu sehen, dass die gewählte Adresse wirklich nicht belegt ist: 

ping 193.96.224.237

Intranet IPv4-Adresse

Wie jeder Dienst im freifunk (auch die, die nur netzintern sind), sollte dieser eine feste interne v4-Adresse bekommen. Wie das geht, steht hier. Im konkreten Beispiel hängt unser Dienst im Richtfunk. Und wie alle dem Richtfunk angeschlossenen Geräte ist er per Definition Teil der West-Domäne. Dementsprechend editieren wir die https://github.com/freifunkhamburg/dhcp-static/blob/master/static-west.json. Wir suchen uns eine noch nicht genutzte IP aus (hier 10.112.96.23) und fügen der Datei hinzu: 

   {
       "hw-address": "70:85:c2:23:d4:ae",
       "ip-address": "10.112.96.23",
       "hostname": "speicher"
   },

Die Änderungen auf github werden automatisch von den DHCP-Servern übernommen, ohne das ein manueller Eingriff erforderlich wäre. Die MAC (hw-address) bekommt man auf der Maschine des Dienstes über: 

ip a

Einstellungen auf dem Host

Netzwerkadressen festlegen

Der Kiste, die wir ans Netz bringen wollen, müssen feste IPs zugeordnet werden denn das default gateway wird nicht mehr per DHCP oder IPv6 Autokonfiguration zugewiesen sondern (in einem folgenden Schritt) per bird. Wir lassen uns die bestehende physikalische Schnittstelle anzeigen 

ip a

In unserem Beispiel heist die Schnittstelle enp1s0 und hat die folgende Adressen:

  • v4 (freifunk Hamburg Intranet): 10.112.96.23
  • v6 (Internet): 2a03:2267:2:0:7285:c2ff:fe23:d4ae
  • v6 (link local): fe80::7285:c2ff:fe23:d4ae

Für diese Schnittstelle legen wir die IPs nun fest: 

vi /etc/network/interfaces.d/enp1s0

Der bestehnde Eintrag 

auto enp1s0
iface enp1s0 inet dhcp
iface enp1s0 inet6 auto

wird geändert nach 

auto enp1s0
iface enp1s0 inet static
	address 10.112.96.23/19
iface enp1s0 inet6 static
	address 2a03:2267:2:0:7285:c2ff:fe23:d4ae/64

Beispiel /etc/network/interfaces.d/enp1s0

Eine zusätzliche Schnittstelle dummy0 wird angelegt mit der Internet-route-baren Adresse 193.96.224.237: 

vi /etc/network/interfaces.d/dummy0

auto dummy0
iface dummy0 inet static
       address 193.96.224.237
       netmask 255.255.255.255
       pre-up ip link add dummy0 type dummy

Beispiel /etc/network/interfaces.d/dummy0

Damit die dummy0-Schnittstelle überhaupt geladen werden kann müssen wir das dummy kernel Modul laden: 

vi /etc/modules

Wir fügen hinzu 

dummy

Beispiel /etc/modules

Abschalten der IPv6 Autokonfiguration: 

vi /etc/sysctl.d/disable-autoconf.conf

net.ipv6.conf.enp1s0.accept_ra=0
net.ipv6.conf.enp1s0.autoconf=0

Beispiel /etc/sysctl.d/disable-autoconf.conf

Ausführen der Konfiguration: 

sysctl -p /etc/sysctl.d/disable-autoconf.conf

Neutstarten. 

reboot

Routing Dienst konfigurieren

Um Routinginformationen zwischen dem Dienst host und den gateways auszutauschen wird das Protokoll OSPF über den routing daemon bird genutzt. Wir Nutzen die bird version 1.6. Falls das richtige bird Paket nicht im Paketmanager vorhanden ist, kann die Anleitung für Debian zur Installation von bird befolgt werden.

Sinn des Ganzen ist, dass Daten von der Internet IP des Dienstes (hier: 193.96.224.237) direkt zu den Gateways geroutet werden. In diesem speziellen Beispiel ist es übrigens so, dass unser Dienst im Richtfunknetz hängt nur die gateways 01 & 03 eine Direktverbindung hierzu haben, gw02 aber nicht. Um Querverkehr zu vermeiden, wird gw02 also nicht in der Konfiguration berücksichtigt.

Die IPv4 Konfigurationsdatei wird angepasst: 

vi /etc/bird/bird.conf

Die Beispiel /etc/bird/bird.conf dient als Vorlage. Wichtig ist, dass die Router ID (eigentlich nur eine 32bit-Zahl, weshalb sich die IPv4 Adresse anbietet), IP Adressen und der Name des Netzwerkinterfaces (hier: enp1s0) entsprechend angepasst werden: 

[...]

router id 10.112.96.23;

[...]

protocol static natips {
       import all;
	route 193.96.224.237/32 reject;
};

[...]
               10.112.96.0/19; #West- / Richtfunk-Domaene
          };
          interface "enp1s0" {
[...]

Die IPv6 Konfigurationsdatei wird angepasst: 

vi /etc/bird/bird6.conf

Auch hier dient die Beispiel /etc/bird/bird6.conf als Vorlage. Wichtig ist, dass die Router ID und der Name des Netzwerkinterfaces (hier: enp1s0) entsprechend angepasst werden: 

[...]

router id 10.112.96.23;

[...]
               interface "enp1s0" {
[...]

Zum laden der neu angelegten Konfigurationen: 

birdc configure
birdc6 configure

Einstellungen auf dem freifunk-Knoten

Auf dem freifunk-Knoten, hinter dem der Dienst hängt, muss konfiguriert werden, dass er Datenpakete von der öffentlichen IPv4-Adresse des Dienstes weiterleitet. Dazu editieren wir die Routingregeln auf dem Knoten (die Nummer am Anfang des Dateinamens gibt die Reihenfolge vor, in der die Regeln abgearbeitet werden): 

vi /lib/gluon/ebtables/109-local-forward-allow-speicher

In der Beispiel /lib/gluon/ebtables/109-local-forward-allow-speicher wird die Zeile hinzugefügt bzw. angelegt: 

[...]

rule('LOCAL_FORWARD -p IPv4 --ip-src 193.96.224.237/32 -j RETURN')

[...]

Dies bedeutet, dass der Knoten Pakete mit der Absenderadresse des Dienstes ins freifunk-Netz durchlässt. Um die neue Regel zu laden: 

 /etc/init.d/gluon-ebtables start 109-local-forward-allow-speicher

Leider übersteht diese neue ebtables-Regel keine Aktualisierung der firmware. Deshalb wird ein shell script geschrieben, welches prüft, ob diese Regel da ist und falls nicht, schreibt es sie neu: 

 vi /etc/rc.local



[...]

CLOUD_IPV4=/lib/gluon/ebtables/109-local-forward-allow-speicher
if [ ! -f $CLOUD_IPV4 ]; then
        echo "Installing cloud IPv4 rule"
        echo "rule('LOCAL_FORWARD -p IPv4 --ip-src 193.96.224.237/32 -j RETURN')" > $CLOUD_IPV4
        /etc/init.d/gluon-ebtables start $CLOUD_IPV4
else
        echo "Cloud IPv4 rule already exists"
fi

[...]

Beispiel /etc/rc.local.

Einstellungen auf den gateways

Nun muss die Routeninformation für OSPF von der anderen Seite gesetzt werden - für die Beispiel Adresse 193.96.224.237 aus dem Internet durch die gateways zu dem Dienst host hin. Und diesmal von allen gateways (gw02 wird nicht ausgenommen), denn man weiß nicht durch welches gateway die Anfrage nach dieser IP aus dem Internet reinkommt.

Routing Informationen

IPv4: 

vi /etc/bird/bird.conf.d/ospf.conf

Hinzufügen der Route für die Internet IPv4 Adresse über die Intranet IPv4 Adresse: 

protocol static natips {

[...]
       route 193.96.224.237/32 via 10.112.96.23; #speicher
 };

[...]
       
                 neighbors {

[...]
       
                               10.112.96.23 eligible; #speicher       
                       };

[...]

IPv6: 

vi /etc/bird/bird6.conf.d/ospf.conf

Hinzufügen der link local Adresse des Dienst hosts: 

[...]
       
                       neighbors {

[...]        
                               fe80::7285:c2ff:fe23:d4ae eligible; #speicher
                       };

[...]

Laden der geänderten Konfigurationen: 

birdc configure
birdc6 configure

Firewall Regeln

vi /etc/iptables/rules.v4

Hinzufügen der Weiterleitungsregeln: 

[...]

-A FORWARD -d 193.96.224.237/32 -i eth2 -j ACCEPT
-A FORWARD -s 193.96.224.237/32 -o eth2 -j ACCEPT

[...]

Anwenden der geänderten Regeln: 

iptables-restore < /etc/iptables/rules.v4

DNS

Im letzten Schritt werden die DNS-Einträge gesetzt. Dabei kann man sich an der DNS-Anleitung orientieren.

Reverse DNS

In der db.arpa.in-addr.193.96.224 wird der Abschnitt hinzugefügt und (nicht vergessen!) die Serial hochgesetzt: 

[...]

; /32 Host Routes. Pick anything between .232 and .239.

; speicher.hamburg.freifunk.net
; to be reachable from outside
237			PTR	speicher.hamburg.freifunk.net.

[...]

Reguläres DNS

In der db.net.freifunk.hamburg wird der Abschnitt hinzugefügt und (nicht vergessen!) die Serial hochgesetzt: 

[...]

; SERVICES
speicher		A	193.96.224.237
			AAAA	2a03:2267:2:0:7285:c2ff:fe23:d4ae
  
[...]

Final muss auf dem primären DNS-Server (srv01) die neue konfiguration geladen werden 

cd /etc/bind/
git pull
service bind9 restart

Fertig. Der Dienst sollte nun aus dem IPv4 Internet erreichbar sein (und v6 natürlich auch).

Abgerufen von „https://wiki.freifunk.net/index.php?title=Hamburg/Dienst_mit_öffentlicher_IPv4&oldid=46983“