Gateway aufsetzen

Also ich habe nach meinem erfolglosen Versuch neulich (Neu zu verteilende Aufgaben bei Freifunk Rhein-Neckar) nochmal probiert ein eigenes Gateway aufzusetzen. Diesmal hat das auch einigermaßen geklappt. Ich hatte mich im Vorhinein aber auch stärker damit beschäftigt was für Software genutzt wird, was sie macht usw. Ein paar Dinge sind mir in Bezug auf das Setup von FFRN aber immer noch nicht ganz klar.

Die Ansible Rolle lief diesmal dann auch auf einem kleinen CX11 bei Hetzner mit Debian 9 (vorher hatte ich es (unter anderem im Unterschied) mit Debian 10 probiert und musste da mehrmals manuell eingreifen) problemlos durch. Um allerdings keine decrepated Warnungen von ansible mehr zu bekommen, habe ich die entsprechenden Stellen mal aktualisiert und einen Pull Request aufgemacht.
Knoten die ich dann mit einer Firmware mit den notwendigen Informationen um sich zu verbinden versorgt habe, haben sich auch problemlos verbunden, die Clients haben per DHCP eine private IPv4 bekommen und IPv4 “ins Internet” funktioniert auch. Was aktuell nicht komplett funktioniert ist IPv6. Die Geräte bekommen von dem Router zwar das für mich richtige /64 IPv6 Prefix und generieren sich dann auch eine passende IPv6. Innerhalb meines Freifunk Netzes funktioniert das auch. Ich kann also innerhalb meines Netzes (auch mit zwei unterschiedlichen Uplinks, es geht also über das Gateway) auf andere Geräte zugreifen. Ich komme aber halt nicht raus oder rein. So wie ich das sehe ist das aber auch nicht auf dem Gateway konfiguriert.
Meine Frage wäre also, wie funktioniert das mit dem IPv6 bei den FFRN Gateways? In der Ansible Rolle kommt ja zum Beispiel radvd nicht vor.

Der FFRN hat ja scheinbar bei Hetzner als IPv6 Prefix 2a01:4f8:171:fc00::/56 (im Whois dafür steht zwar als Adresse der Freifunk Rhein-Neckar e.V. aber nicht die aktuelle Straße und als Person noch Leah Oswald drin [der Eintrag ist also veraltet]) und der FFRN nutzt dieses Prefix auch innerhalb des Netzes für alle Geräte.
Jedoch ist mir nicht klar, da ich vermute das man bei Hetzner dieses Präfix nur einem der 3 physikalischen Server zuordnen kann und es dort vermutlich an eine einzelne Mac Adresse einer Netzwerkkarte geknüpft ist, wie der Traffic ausgeleitet wird? Gibt es hier also keine Redundanz?

Auch ist mir aufgrund der Ansible Rolle noch nicht so klar, wie beim FFRN die virtualisierten Gateways untereinander kommunizieren.

Es wäre echt cool, wenn (ich vermute mal es wird @leah sein :wink:) mir das jemand etwas genauer erklären könnte, da ich versuche besser zu verstehen wie das “alles” funktioniert.

Falls es jemanden interessiert, die Seiten auf denen ich mich unter anderem etwas zu Freifunk-Gateways etwas eingelesen habe sind die folgenden:

2 Like

Es empfiehlt sich oft, zurückhaltend bei der Distributionswahl zu sein; im Falle der Münsteraner Ansible-Rollen war der SW-Stand z. B. im 1. Quartal noch auf Debian 8 fixiert. (Die fflip-Rollen auf github sollten für Ubuntu 18.04 LTS passen.)

Hmm. Von meinem ffrn-Test-Client aus sieht das so aus:

root@ffrn-client:~# traceroute -6 mail.4830.org
traceroute to mail.4830.org (2a06:e881:2604:42::4), 30 hops max, 80 byte packets
 1  int.v6upstream.rz17.fks.de.noc.ffrn.de (2a01:4f8:171:fcff::1)  13.915 ms  13.863 ms  13.835 ms
 2  vm01.rz17.fks.de.ffrn.de (2a01:4f8:171:3242::2)  13.628 ms  14.341 ms  14.325 ms
 3  2a01:4f8::a:17:a (2a01:4f8::a:17:a)  14.318 ms  14.492 ms  14.474 ms
 4  core24.fsn1.hetzner.com (2a01:4f8:0:3::169)  14.467 ms  15.738 ms  15.730 ms
 5  core1.fra.hetzner.com (2a01:4f8:0:3::119)  19.165 ms core1.fra.hetzner.com (2a01:4f8:0:3::1bd)  19.135 ms  19.095 ms
 6  irz42.fra.ecix.net (2001:7f8:8:20:0:334f:0:1)  31.315 ms  29.234 ms  29.196 ms
 7  hellgate-g.gre.irz42.net (2a00:14b0:4200:3280::150)  29.377 ms  29.356 ms  28.684 ms
 8  de2.as206946.net (2a06:e881:2604:42::1)  26.829 ms  27.411 ms  26.992 ms
 9  mail.4830.org (2a06:e881:2604:42::4)  27.769 ms  27.754 ms  28.045 ms

Das /56 kann ich gerade nicht deuten; augenscheinlich teilen sich alle Gateways das eine :fcff:-/64 (:${GW_ID}::53 ist lt. Ansible die jeweilige IP des Nameservers):

…
root@ffrn-client:~# traceroute 2a01:4f8:171:fcff:1::53
traceroute to 2a01:4f8:171:fcff:1::53 (2a01:4f8:171:fcff:1::53), 30 hops max, 80 byte packets
 1  ffrn-client (2a01:4f8:171:fcff:0:f9ff:fe3c:ca37)  3054.669 ms !H  3054.595 ms !H  3054.578 ms !H
root@ffrn-client:~# traceroute 2a01:4f8:171:fcff:2::53
traceroute to 2a01:4f8:171:fcff:2::53 (2a01:4f8:171:fcff:2::53), 30 hops max, 80 byte packets
 1  2a01:4f8:171:fcff:2::53 (2a01:4f8:171:fcff:2::53)  48.310 ms  48.240 ms  48.224 ms
root@ffrn-client:~# traceroute 2a01:4f8:171:fcff:3::53
traceroute to 2a01:4f8:171:fcff:3::53 (2a01:4f8:171:fcff:3::53), 30 hops max, 80 byte packets
 1  2a01:4f8:171:fcff:3::53 (2a01:4f8:171:fcff:3::53)  36.492 ms  36.347 ms  36.410 ms
root@ffrn-client:~# traceroute 2a01:4f8:171:fcff:4::53
traceroute to 2a01:4f8:171:fcff:4::53 (2a01:4f8:171:fcff:4::53), 30 hops max, 80 byte packets
 1  2a01:4f8:171:fcff:4::53 (2a01:4f8:171:fcff:4::53)  48.071 ms  47.667 ms  47.647 ms
root@ffrn-client:~# traceroute 2a01:4f8:171:fcff:5::53
traceroute to 2a01:4f8:171:fcff:5::53 (2a01:4f8:171:fcff:5::53), 30 hops max, 80 byte packets
 1  2a01:4f8:171:fcff:5::53 (2a01:4f8:171:fcff:5::53)  50.593 ms  50.217 ms  50.195 ms
root@ffrn-client:~# traceroute 2a01:4f8:171:fcff:6::53
traceroute to 2a01:4f8:171:fcff:6::53 (2a01:4f8:171:fcff:6::53), 30 hops max, 80 byte packets
 1  2a01:4f8:171:fcff:6::53 (2a01:4f8:171:fcff:6::53)  56.408 ms  56.341 ms  56.282 ms
root@ffrn-client:~# traceroute 2a01:4f8:171:fcff:7::53
traceroute to 2a01:4f8:171:fcff:7::53 (2a01:4f8:171:fcff:7::53), 30 hops max, 80 byte packets
 1  ffrn-client (2a01:4f8:171:fcff:0:f9ff:fe3c:ca37)  3078.984 ms !H  3078.901 ms !H  3078.886 ms !H
…

Fühlt sich demnach so an, als ob mehrere VMs auf nur einem Host für die Redundanz zuständig sind?

Offensichtlich pushen das hier (nur?) die Knoten:

 OpenWrt 18.06-SNAPSHOT, r7629+12-eef6bd3393
 -----------------------------------------------------
root@ffrn-wusel-test:~# ps -w | grep rad | grep -v grep
 2227 root      2736 S    /usr/sbin/uradvd -i local-node -p 2a01:4f8:171:fcff::/64 --rdnss 2a01:4f8:171:fcff::ffff
 3009 root      6904 S    /usr/sbin/gluon-radv-filterd -i br-client -c RADV_FILTER -t 20

Danke für deine Antwort @wusel!

Der Freifunk Rhein Neckar hat soweit ich weiß 3 Maschinen bei Hetzner stehen und auf denen laufen dann einige virtuelle Maschienen für die einzelnen Sachen:

Ich habe mir hier nur IPv4 angeschaut, da dies gerade einfacher war. Aber das zeigt die Struktur die es hier zu geben scheint etwas. Wenngleich das die saubere Variante ist, frage ich mich doch, ob es sich lohnt so “viel” Geld für zusätzliche IP-Adressen auszugeben und virtuelle Hosts und Reverse Proxys nicht auch “reichen” würden.

Das habe ich mir dann auch gedacht, gerade da eben die Gateways laut ihrer Ausgabe aktuell mit Debian 9 laufen. Man muss es ja nicht überstürzen.

1 Like

Das ist einfach und hast du richtig erkannt, aus diesen Gründen ist das V6 Netz auf einen VM Host und die darauf laufenden Gateways beschränkt.

1 Like

Bis zu 6 zusätzliche IPv4-Adressen je Host kosten je 1 €//Monat; das macht den Kohl bei ~45 EUR Grundkosten imho nicht fett (jedenfalls verfahre ich für meine private Hetzner-Kiste so), und es ermöglicht KISS.

JFTR, unser Server in Berlin hatte seinerzeit zu wenig lokale IPv4-Adressen und ich habe dann das Forum auf einer v6-only-VM aufgesetzt (faktisch eine public-v6 und NAT-v4-VM, denn mit v6-only scheitert schon ein apt-get update :frowning:) und den Zugriff aus der v4-Welt per Reverse-Proxy umgesetzt. Geht, aber u. a. war es dann immer wieder ein Aufwand, das Lets-Encrypt-Zertifikat zwischen den 2 Rechnern zu synchronisieren. Bei den Logs muß man mit X-Forwarded-For arbeiten. Und der Mailversand war noch eine andere Geschichte, bei v4 war die absendende IP ja die des Hosts, nicht der VM (=> SPF, DKIM). (Mittlerweile nutzen wir in Berlin dafür einfach ein /27 unseres v4-Spaces, das ist routingtechnisch ggf. suboptimal, aber operativ viel einfacher als die Reverse-Proxy-Lösung.)

Auch hier recht kurz gehalten.
@leah: Bist Du noch am Start? Unterstuetzt Du hinter den Kulissen die neuen Anwaerter oder nur hier per kurzem Kommentar (“Das ist einfach und hast du richtig erkannt…”)?

Was ist Dein Ziel? Bei Freifunk 2.0 dabei sein? Hier alles an die Wand fahren und auf Phoenix aus der Asche warten? Oder hoffen, dass der nicht aufersteht?
Mir ist das wirklich unklar, deshalb frage ich hier. Klare Worte halte ich fuer angebracht.

Das troepfelt hier sehr spaerlich und ohne @wusel, der hier eigentlich ueberhaupt nicht am Start ist, unterstuetzen die alten Hasen hier kaum beim Neuanfang.

Öhm…wo am Start? Und ein hinter den Kulissen gibt es nicht.

Öhm…eigentlich keins, ich guck hier primär zu.

Da ich keinen Zugriff mehr auf irgendwelche Kisten habe und auch keinerlei Entscheidungsgewalt, kann ich nichts an die Wand fahren. Da braucht es aber auch keine Nachhilfe von mir, das passiert ganz von alleine.

Meine klaren Worte gab es glaub irgendwann im April, ich bin raus aus der Sache. Wer lieb und respektvoll fragt bekommt Antworten, ansonsten hab ich das Projekt inzwischen völlig abgeschrieben.

Naja… so wirklich ernsthaft gefragt hat nach Hilfe bisher niemand und ganz ehrlich, nach dem Stunk der hier abging ist die Motivation der alten Hasen halt leider auch nicht sonderlich groß da proaktiv irgendwie zu helfen. Erst alles kritisieren und die Schuld an allem Abladen, dann aber Hilfe wollen. Da muss von anderer Seite zuerst etwas kommen.

1 Like