und es geht weiter…

Es ist wieder einiges passiert seit dem letzten Blogeintrag:

IPv6 für Freifunk Franken

Wie bereits im letzten Blogeintrag erwähnt, ist es nun möglich von mir IPv6 Adressen zu beziehen Das ganze wurde intensiv getestet und funktioniert nun einwandfrei. Es haben auch schon weitere Leute sich Adressen organisiert und verwenden sie. Viel Spaß damit 🙂 Eingetragen habe ich die URL auch im Freifunk Franken Wiki unter L3 Peering, da ich mir so dachte das es da wohl noch am besten passt. Wenn weitere Angebote in dieser Richtung kommen muss man sich evtl. nochmal überlegen ob es wo anders besser aufgehoben ist.

Freifunk Angebote

Als 2. Punkt habe ich nun angefangen einige Angebote rund um Freifunk zu erstellen. Die Freifunk Franken Community hat am #18fff gründlich darüber diskutiert und kam zu dem Schluss, das solche Angebote der Community durchaus helfen können. Daher hab ich mich entschieden hier auch etwas zu helfen und mich auch ins Freifunk Franken Wiki auf der entsprechenden Seite eingetragen.

IPv6 und https

mal wieder ein kurzer Blogeintrag. Übrigens der erste den ich per https schreibe 😉 Ich habs nun endlich auch geschafft ein Cert drauf zu legen.

Auch hab ich mein v6 System nun langsam im Griff. Ich hab nun 2 Boardgateways, einmal merkur bei Stefan in Frankfurt der direkt mit 100Mbit am Kleyrex und 1Gbit am Locix hängt. Als 2. Maschine, genannt pluto, hab ich eine VM in den Niederlande die mit 1Gbit am Speed-IX hängt und ich Transit von Hurricane Electric bekomme. Somit announce ich nun mein 2a06:e881:340a::/48 Netz an 2 verschiedenen Stellen, ausfallsicher 🙂

Auch eine Abusesseite habe ich hier im Blog erstellt.

Als nächster Schritt ist nun geplant, IPv6 Adressen auch im Freifunknetz für andere Gatewaybetreiber zur Verfügung zu stellen. Dazu verwende ich das Script, welches ich für F3 Netze e.V. bereits geschrieben habe.

Ich hab es nun hier installiert und eine kurze Erklärung dazu geschrieben wie man die Adressen anschließend in unseren Babelnetz verwenden kann.

Das ganze ist aktuell noch im Testbetrieb, sobald die ersten Leute Adressen geklickt haben und sich niemand beschwert werde ich es auf „grün“ schalten, es ist allerdings jetzt schon voll funktionsfähig.

Oh Gott oh Gott oh Gott ich habs gemacht #Freifunk

Ja es ist soweit 🙂 Vor kurzem kam der Brief der BNetzA, dass meine Providermeldung akzeptiert wurde. Auch mein Sicherheitskonzept hat auf Anhieb gefallen \o/

Nunja dann gings los, mein eigenes v6 Netz zu deployen. Ich hab ja bei Stefan eine VM in Oldenburg (übrigens sehr zu empfehlen, super netter Kontakt und auch Sonderwünsche werden jederzeit erfüllt wenn möglich und der Support ist deutlich mehr als man erwarten kann: http://vserver.site/ ) die mit einem Ethernetport am kleyrex (100Mbit)hängt und mit einem 2. Port am locix (1Gbit glaub ich) worüber mir Stefan auch Transit sponsort.

ALso nix wie los, mein 2a06:e881:3400::/44 announcen, ein /48 nämlich 2a06:e881:340a::/48 herausschneiden und für Freifunk nutzen.

Ich hab danach also das gemacht, was laut guten Freifunk-Freunden Freifunker am besten können nämlich:

„Tunnel baun, Tunnel baun, Tunnnnneeellll bauuuunnnnn“

Ja also einmal GRE zu meinen PeeringServer sowie einen Wireguard Tunnel zu mir nach Hause.

Und dann gings los, per Babel wird nun in unser Netz das Subnetz als source specific announced und ich kann in meinen Layer 2 Netzen jeweils ein /64 ausrollen. Mega coooool ich hab endlich v6 in meinen Netzen und dann noch mit meinen Namen dran.

Eine Peeringanfrage an google über den kleyrex wurde leider (noch) verneint mit dem Kommentar:

„Kein Traffic vom AS205165 wir wollen nicht peeren“ (sinngemäß)

Na wartet google, ich mach jetzt soviel Traffic das ihr betteln werdet mit mir peeren zu dürfen (oh man merkt den Federweiser oder ;))

Nun gut mal sehen wie das ganze jetzt so tut 🙂 Mir gefällt es bisher sehr gut.

Gluon Node für Freifunk Franken

Hallo mal wieder ein neuer Beitrag 🙂 Diesmal will ich aufzeigen wie ich das Gluon Framework für einen Freifunk Franken Node angepasst habe. Wobei angepasst eigentlich schon sehr übertrieben ist, viel musste man eigentlich gar nicht tun. Der Node ist aktuell hier oder hier (sofern Online) zu sehen.

Warum mach ich das ganze eigentlich? Im moment läuft bei mir an den meisten Punkten unsere Freifunk Franken Firmware. Diese wird aktuell aber nur sehr zäh weiter entwickelt und durch das automatische Hood konfigurieren gibt es immer wieder Probleme bei mir. Ich will einfach eine statische Hood kompilieren und dann ist der Node NUR und NUR(!) für diese Hood gebaut.

Ich versuche mal Vor- und Nachteile von Gluon zusammen zu fassen:

Vorteil Gluon:

  • Es geht extrem viel automatisch
  • Es ist deutlich aktueller als unsere Firmware (neueres Batman, neuer Kernel, etc.)
  • Hood wird einfach statisch kompiliert ohne viel Script Kram.
  • SSH Key mit einbauen geht ganz einfach über site.conf (wie auch vieles andere was man dort direkt einstellen kann)
  • Node holt sich auch eine public V6 Adresse, das ist bei Freifunk Franken eher nicht gewünscht und müsste man selbst nachrüsten.

Nachteile Gluon:

  • wirkt sehr aufgeblasen, ich musste erstmal viel Kram entfernen der unnötig ist
  • im Gluon IRC Channel liest man von vielen Problemen, ich glaube diese treten aber meist nur auf weil Gluon oft in riesen L2 Netzen verwendet wird, die ich ja nicht habe (meist 1stellig oder niedrige 2 stellige Nodezahlen pro L2 Netz). Anderseits wird da aber sehr aktiv an der Fehlerbehebung gearbeitet (siehe Vorteil wird aktiv entwickelt)
  • bisschen viel Magie was ich aktuell noch nicht verstanden habe aber Magie die funktioniert ist vielleicht auch gute Magie 😉
  • LUA

Fakten (seh ich aktuell weder als Vor- noch als Nachteil):

  • Kein VPN möglich, wäre wohl theoretisch auch möglich über sie site.conf / site.mk einzustellen, für mich aber aktuell nicht nötig daher hab ich den kompletten VPN Kram einfach rausgeworfen.
  • wird nur für eine Hood gebaut. Hoodwechsel benötigt neues Flashen des Routers. Für mich ganz klar ein Vorteil da meine Router in der Hood sein sollen wo ICH sie haben will und nicht wo jemand anders oder irgendeine Automatik sie gerade hinschieben möchte.
  • Ich hab den Autoupdater aktuell komplett ausgebaut. Aktuell muss ich das Zeug erstmal zum laufen bekommen bevor ich mich traue meinen ganzen Kram automatisch upzudaten.

Gluon bauen

Benötigen tun wir eigentlich nur einen Linux PC um die Gluon Firmware zu bauen. Danach legen wir irgendwo einen Ordner an und ziehen uns erst mal Gluon ausm Git herunter:

git clone https://github.com/freifunk-gluon/gluon.git gluon
cd gluon

(evtl. hier noch auf das letzte Release wechseln wenn man nicht den Master bauen möchte, ich hab aktuell einfach mal den Master gebaut)

danach brauchen wir eine site.conf und site.mk im sites Unterordner. Ich hab meine für Hood Unterfürberg mal in ein Git gelegt:

https://github.com/ChristianDresel/GluonSiteUFB

einfach die site.mk und site.conf nach /sites kopieren und wenn nötig für die eigene Hood anpassen. Ich hab bei mir den config-mode deaktiviert (setup_mode = { skip = true, },) und direkt meinen SSH Key mit eingebaut ( authorized_keys = […]). Zudem hab ich alle LAN Ports direkt auf Mesh/Batman gestellt (mesh_on_lan = true,) und Geräte die nur einen Ethernetport haben, den Port so eingestellt das er wie ein LAN Port (also Mesh/Batman) behandelt wird (single_as_lan = true,).

Damit sich der Router später im Monitoring meldet, brauchen wir noch ein angepasstes Nodewatcher Paket. Hier hab ich mir von ffol das Nodewatchergluon Paket genommen welches auch Freifunk Rothenburg verwendet, die ausführbare Nodewatcherdatei von Freifunk Franken genommen und ein wenig für Gluon angepasst (Koordinaten, Owner, etc.) und schon frisst Gluon den Nodewatcher und das Monitoring die Daten.

Das Paket habe ich fertig hier abgelegt:

https://github.com/ChristianDresel/GluonNodewatcherFFF

einfach das ganze nach /package/gluon-ffol-nodewatcher/ kopieren.

Aktiviert wird es über sie site.mk indem die packages alfred und ffol-nodewatcher  in GLUON_FEATURES :=  hinzugefügt werden.

Danach sind wir mit dem Vorbereiten fertig und müssen Gluon nur noch kompilieren.

make update
make GLUON_TARGET=ar71xx-generic

man kann GLUON_TARGET=ar71xx-generic auch weglassen, dann wird angezeigt für welche Targets (=Gerätetypen) Gluon gebaut werden kann, und kann beim bauen entsprechend angegeben werden. Für den typischen 841er muss man z.b. ar71xx-tiny verwenden.

Danach dauerts je nach CPU ein paar Minuten und am Ende landet der fertige build ist:

/lede/bin/targets/ar71xx/generic/

danach die File ganz normal auf den Router flashen und schon ist der Gluonnode fertig 🙂

Problem

Aktuell gibt es noch ein Problem, das Gluon in der neuen Version irgendein VXLAN Zeug für Kabelmesh verwendet. Das will ich eigentlich nicht. Man kann es wärend der Laufzeit ausschalten aber aktuell noch nicht über die site.conf. Daran wird nach meinen Kenntnis aber gerade gearbeitet. Mehr dazu hier.

Domainprobleme

So da bin ich wieder…

Bisschen in der Matrix (ja ich nutzt diesen Neumodischen scheiß wirklich :)) diskutiert über E-Mail und so… und mir wurde nun uberspace.ähhh https://uberspace.de/ empfohlen. Problem dabei, meine alte chrisi01.de Domain ist einfach aus meiner Jugendzeit und schon lange nicht mehr zeitgemäß. Nicht umsonst läuft der Blog auf cdresel.de

cdresel.de nunja das wäre mal die erste Option für E-Mail Adressen. Beim bisschen rumhacken und versuchen cd.ENDUNG was zu bekommen, wurde mir recht schnell klar… no way da findeste nix schönes bezahlbares. Aber hey ich bin 1986 gebohren und kurz probiert cd86.de war frei und gehört nun mir JAAJIAAA hübsch oder? Kurz darauf ist mir mein AS205165 wieder eingefallen und natürlich war auch as205165.de wieder frei 🙂 Aber das als E-Mail nehmen? Ne oder? Das leite ich vllt. auf den Blog hier weiter oder so.

Also steht nun die Wahl zwischen cd86.de und cdresel.de. Schwere Entscheidung was nimmt man denn nun? Mal ne Nacht drüber pennen 😉

edit:

Lassen wir doch Twitter entscheiden, wobei ich schon weiß was raus kommt. Es war eine schöne Zeit mit euch, kurz aber schön…

AS205165 läuft wieder :)

So endlich hab ich meinen Kram mal wieder im Griff und meine VM mit dem AS205165 läuft wieder 🙂

Hab ja schon lange überlegt die für Freifunk zu verwenden. Providermeldung an die BNetzA und schon wäre man ziemlich fein raus. Im Sinne der Dezentralität wäre es ja echt super, wenn nicht zuviel an F3 Netze e.V. hängt. Ja ich hatte es wirklich schon fast vor und dann kommt die #EH18 und dieser Vortrag

Jetzt zweifel ich wieder an mir selbst. Soll ich es wirklich tun? Oh man echt schwere Entscheidung. Mal nochmal paar Nächte drüber pennen und überlegen.

Ob sich so Hausdurchsuchungen vermeiden lassen, wenn man als Provider gemeldet ist? Ansbach war es ja nicht. Ich wäre also hier schon einen Schritt voraus. Echt schwere Entscheidung

edit:

Der Blogpost entstand natürlich auf Reaktion eines Twitter-Tweets. Jetzt macht er mir aber direkt wieder Hoffnung 🙂

Denn genau der Eintrag in der RIPE und das Konzept ISP trifft dann natürlich wieder auf mich zu. Also doch „tun“? Den Tweet werde ich mal noch ein bisschen im Blick behalten und danke schon mal für die Tipps 🙂

FreifunkV3

Hihi bei Twitter mal bisschen was geschrieben und schon waren Nachfragen da 😛

Schön  das den Blog wohl noch immer niemand kennt und ich die Idee einfach mal runtertippen kann 😉 Glückwunsch wenn du ihn gefunden hast mal sehen wer später nach FreifunkV3 googelt und hier landet 😉

Also was ist nun dieses ominöse FreifunkV3. Fangen wir mal mit den 0815 Standartfreifunk an:

Man packt Pakete ins Batman ein, packt sie in ein VPN ein um sie über eine DSL Leitung zu verschicken. Selbst ein wdr4900 schafft da bestenfalls 22Mbit (fastd). Ein x86 braucht viel Strom und will auch niemand. Also wie gehts schneller. Es entstand die Idee der dezentralen Hood:

https://wiki.freifunk-franken.de/w/Dezentrale_Hood

Keine schlechte Idee und genau darauf ist auch der keyxchangev2 entstanden:

https://wiki.freifunk-franken.de/w/KeyXchangeV2

Aber irgendwie wurde das ganze endlos kompliziert und hatte Bugs, niemand blickt mehr durch und man hat versucht eine eierlegende Wollmilchsau zu bauen:

https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-hoods/files/usr/sbin/configurehood

Ja das ganze soll wie von selbst laufen, was dann passiert kann man hier nachlesen:

https://lists.berlin.freifunk.net/pipermail/berlin/2015-September/030046.html

Nein die User müssen ihre Netze selbst aufbauen, leicht, wenig automatisch und von jedem der sich bisschen mit beschäftigt umsetzbar,

Die Idee der dezentralen Hood wurde also wieder aufgegriffen und ich hab heute mal in kurzer Zeit folgendes gebaut:

  • wdr4900 mit aktuellen LEDE geflasht
  • opkg update
  • opkg install babeld
  • opkg install wireguard
  • opkg install luci-proto-wireguard

Danach bisschen Wireguard konfiguriert damit er sich zu meinem Server verbindet der in der Freifunk Franken Backbone angebunden ist (hier müsste noch eine [halb]automatisch Lösung her), darauf Babel geworfen damit ich alle Routen aus dem Freifunk Franken Netz habe (ja wir haben eine Babel Backbone). Danach noch ein bisschen Routingregeln und Firewall (ist nicht viel und mit ner kurzen Anleitung umsetzbar, notfalls kann man auch ein kleines Script schreiben das man einfach ausführt und alles automatisch macht).

Zum erweitern des Netzes nimmt man dann Accesspoints namhafter Hersteller die deutlich besser funktionieren als so ein 841er mit LEDE, 5GHz Outdoor ist auch kein Problem und wer Mesh will, es gibt mittlerweile genug Hersteller die ein besseres Mesh machen als Freifunk (weil mehrere Kanäle verwendet werden was Freifunk noch immer nur sehr bescheiden kann). Man kann also dran hängen was immer man will, vom 20€ Repeater über geiles Meshnetz.

Besser noch, Babel kann man als „erweiterter Nutzer“ auch auf einen Ethernetport werfen und z.b. per Richtfunk sich mit seinen Nachbar der das gleiche (oder ähnliches) Setup fährt direkt verbinden (nennt sich übrigens Routing und nicht dieses krüppelL2Routing was Batman macht ;)), genau das was man bei Freifunk will 🙂

Falls es jemand nachbauen will, einfach mal melden vielleicht hab ich Muse die Anleitung runter zu tippen und paar Tipps zu geben 😉

IPv6 Routing ins Freifunknetz (Franken)

So und nun wollen wir uns an die Königsklasse wagen, wir wollen alle Router in den Hoods die bereits ULA Adressen haben erreichen können. Speziell betrifft das die dezentralen Hoods wie auch beim KeyxchangeV2.

Um diese Anleitung umzusetzen ist es zwingend notwendig ein Gateway in der Hood wo man sitzt selbst betreibt da man Routen ins Freifunknetz announcen muss.

Zuerst generieren wir uns ein eigenes ULA v6 Netz. Am einfachsten geht das z.b. hier, man gibt die MAC Adresse der eigenen Netzwerkkarte ein und erhält dann ein generiertes /48 Netz.

Wenn man nun sein Netz hat, muss man dies zusätzlich auf dem Interface vergeben, wo das lokale Netz dran hängt, in meinem Fall eth1. Man klickt also am Dashboard bei eth1 auf Actions und config. Danach wählt man „Add IP“ und gibt eine Adresse des /48 ein (ich hab ::1 genommen).

Danach das ganze mit Save abspeichern. Danach müssen wir unseren radvd noch sagen, das er dieses Subnetz ebenfalls im privaten Netz verteilen soll. Dazu klicken wir auf configtree und machen folgenden Baum auf (kennen wir bereits von der IPv6 Anleitung):

interfaces – ethernet – eth1 (oder das, wo unser privates Netz dran hängt) – ipv6 – – prefix

und legen dort mit „Add“ ein neues prefix an und geben dort ein /64 aus dem /48 ein (evtl. kann man auch das ganze /48 nehmen, bin mir da unsicher und hab ein /64 genommen also z.b. fdc6:xxxx:xxx::/64).

Nach dem abspeichern sollte man an Endgeräten schon eine IP aus diesem Subnetz erhalten.

Jetzt kommt der interessante Part, wir wollen dieses Subnetz ins Freifunk routen und im Freifunk bescheid sagen, dass diese Subnetz über unser Gateway erreichbar ist. Dies machen wir indem wir es ins Babel announcen. Hier sollte man sich bewusst sein, dass man dadurch sein privates Netz im Freifunk öffnet. Daher stellen wir weiter unten noch eine Firewall ein, damit niemand aus dem Freifunknetz ins private Netz kommen kann.

Wir legen also zuerst mal in unserem Router eine statische Route ins Freifunknetz an, dazu nutzen wir wie immer bei IPv6 den configtree:

protocols – static – route6

hier legen wir eine neue Route an, wir wollen alles zu fc00::/7 auf das Freifunk routen, also geben wir fc00::/7 ein. Danach auf „Update List“ klicken und links kann man dann als Unterpunkt von fc00::/7 „next-hop“ auswählen.

Hier muss die IP Adresse des Freifunkgateways eingeben werden. Wir haben in Franken typischerweise fd43:5602:29bd::/48, ich hab in meiner Hood das fd43:5602:29bd:5::/64 Subnetz und mein Gateway hat fd43:5602:29bd:5::6466:b3de:f861 somit habe ich diese Adresse genutzt. Ihr müsst dies natürlich auf eure eigenen Adressen anpassen, danach das ganze noch abspeichern. Aussehen sollte das ganze nun so:

Somit haben wir eine route in das Freifunknetz, allerdings „weiß“ das Freifunknetz natürlich nicht, wie es uns findet, wir müssen also auch einen Rückweg bekannt geben.

Wir legen also auf unserem Gateway eine statische Route in die Tabelle fff mit „proto static“ damit Babel das ganze auch redistributed. Die route sollte so aussehen:

fdc6:xxxx:xxxx::/48 via fd43:5602:29bd:5:de9f:dbff:fe29:44c9 dev br-mesh proto static

Die erste Adresse ist unser eigenes Subnetz, bei via muss die Adresse rein die sich unser Edgerouter auf das eth2 Interface gelegt hat. Als device das nutzen worüber der Edgerouter erreichbar ist (da mein Gateway ein LEDE System ist und in der br-mesh bridge das Clientnetz mit drinnen hängt, habe ich dieses Interface verwendet).

Danach muss man Babel nur noch sagen das man diese route auch wirklich redistributen will. Unter LEDE z.b. die /etc/config/babel anpassen und folgendes hinzufügen:

config filter
option type ‚redistribute‘
option local ‚true‘
option ip ‚fdc6:xxxx:xxxx::/48‘

config filter
option type ‚redistribute‘
option ip ‚fdc6:xxxx:xxxx::/48‘

Als IP natürlich unsere eigene IP nutzen. Unter Debian muss dies natürlich in der /etc/babeld.conf gemacht werden, etwa so:

 

redistribute local ip fdc6:xxxx:xxxx::/48
redistribute ip fdc6:xxxx:xxxx::/48

Wenn man nun Babel neu startet, sollte diese route mit redistributed werden. Wie oben bereits gesagt ist das private Netz aber nun offen wie ein Scheunentor, man sollte tunlichst die Firewall dazu erweitern.

Dazu gehen wir wieder in den configtree und gehen dort nach:

firewall – ipv6-name

Zuerst legen wir einen neuen Unterpunkt FREIFUNKv6_LOCAL an. Dieser beschreibt den localen Zugang zum Edgerouter (NICHT das routing dahinter). Da man vom Freifunknetz keinesfalls NIE auf den Edgerouter kommen soll, droppen wir einfach alles bis auf ipv6-icmp (ping).

Bei default-action geben wir also erstmal „drop“ ein.

Danach legen wir eine rule an, nennen sie „10“ bei „action“ -> „accept“ und bei „protocol“ -> ipv6-icmp. Damit erlauben wir nun IPv6 Pings.

Dies sperrt aber noch nicht den Zugang hinter dem Edgerouter, also das ganze private Netz. Dies wird mit der Regel „IN“ erledigt. Wir legen also wieder unter ipv6-name einen neuen Punkt an und nennen diesen .

Hier können wir natürlich nicht alles sperren, denn sonst kommen wir ja nicht mehr raus. Dazu gibt es bei der Firewall state was wir nutzen.

Zuerst legen wir wieder eine rule 10 an und erlauben ipv6-icmp wie schon oben bei local. Danach legen wir eine rule 20 an, setzen diese auch auf accept. Hier lassen wir protocol aber leer und wählen den Unterpunkt „state“. Die Punkte „established“ und „related“ auf „enable“ stellen:

Danach mach es noch Sinn, UDP Port 33434-33523 freizugeben damit traceroutes ordentlich funktionieren. Wir legen eine rule 30 an, setzen diese auch wieder auf accept, protocol auf udp und unter destination -> port auf 33434-33523 stellen. Danach alles abspeichern.

Die ganzen Regeln müssen wir jetzt nur noch auf dem eth2 Interface anwählen. Dazu öffnen wir

interfaces – ethernet – eth2 – firewall

unter „IN“ schreiben wir bei „ipv6-name“ -> „FREIFUNKv6_IN“ rein und unter „LOCAL“ bei ipv6-name -> „FREIFUNKv6_LOCAL“.

Abspeichern und nun sollte die Firewall aktiv sein. Man kann nun zwar aus dem Freifunknetz Geräte im privaten Netz pingen aber da alle Ports gesperrt sind ist kein Service im privaten Netz erreichbar. Andersherum sollte man aus dem privaten Netz heraus aber alle v6 ULA Adressen im Freifunknetz erreichen. Man sollte dies auf jeden Fall nochmal intensiv testen um sicher zu sein das man nichts verkehrt gemacht hat.

 

 

IPv4 ins Freifunknetz mit NAT über den Edgerouter

Die Fortsetzung der Geschichte rund um meinen Edgerouter. Diesmal eine kurze Erklärung wie man sein priv. Netz ins Freifunknetz NATtet.

Wie im letzten Beitrag schon erklärt, hängt bei mir am eth2 der Clientport eines Freifunkrouters dran. Wenn man das Interface nun auf IP per DHCP beziehen stellt, bekommt man auch schon eine IP aus dem Freifunknetz. Alternativ kann man auch eine feste IP setzen.

Danach klickt man auf Routing und „Add static route“ denn wir wollen ja eine statische Route ins Freifunknetz setzen. Destination Network beschreibt das Zielnetz, in unseren Fall also 10.0.0.0/8. Als Next Hop müssen wir uns ein Gateway aus unserem Freifunknetz suchen. Wenn man es nicht kennt, verbindet man sich mit einen Laptop o.ä. ins Freifunknetz und schaut was man als Gatewayip zugewiesen bekommt. Diese kann man dann verwenden und bei Next Hop eintragen.

Jetzt steht schon die statische Route von allen Clients im privaten Netz ins Freifunknetz. Da das Freifunknetz aber den Rückweg ins eigene Netz nicht kennt, müssen wir unsere Pakete noch NATten. Dies erreichen wir im Menü „Firewall/NAT“ und dort im Reiter „NAT“.

Dort klicken wir auf „Add Source NAT“ und geben folgendes ein:

Description: Irgendeine Beschreibung, z.b. „NAT ins Freifunk“

Enable: Den Haken setzen, wir wollen es ja aktivieren

Outbound Interface: eth2 (bzw. das Interface wo Freifunk drauf hängt)

Bei „Use Masquerade“ und „All protocols“ jeweils einen Haken setzen.

Abspeichern und sich freuen das man nun von seinem privaten Netz aus das IPv4 Netz im Freifunk erreichen kann.

Für IPv6 geht das ganze noch ein gutes Stück schöner, da man hier auf das NAT verzichten kann. Wie das geht erkläre ich im nächsten Beitrag.

Konfiguration Edgerouter

So ich hab das Ding nun komplett fertig eingerichtet und möchte hier mal meinen Netzaufbau erklären.

Anschlüsse:

  • eth0: DSL Modem
  • eth1: privates Netz (hier hängt bei mir ein 24 Port managed NETGEAR GS724T)
  • eth2: Clientport Freifunkrouter

IPv4 ist die Einrichtung noch recht leicht. Ich hab ein PPPoE Interface angelegt, meine Telekomzugangsdaten reingeklopft, als Interface eth0 ausgewählt und schon hat sich das Ding über mein DrayTek Vigor 130 verbunden.

Aufpassen muss man, das man auf dem eth0 (also dort, wo das DSL Modem hängt) DHCP Client ausschaltet. Sonst holt sich der Edgerouter eine 192.168.1.X IP vom DSL Modem und will darauf routen. Da das Modem aber kein Router ist, kommt man darüber natürlich nicht ins Internet. Nachdem ich DHCP aus hatte, hat der Edgerouter es dann auch verstanden das er die default route auf das PPPoE Interface werfen soll.

Die Konfiguration des DHCP Servers sollte selbsterklärend sein, dazu einfach mal oben auf Services klicken und dann kommt man direkt auf den DHCP Punkt.

Danach hab ich mich mal ein wenig mit den config tree auseinander gesetzt. Wirklich einfach zu bedienen ist er nicht, aber wenn man es mal verstanden hat geht es eigentlich. Ich will hier mal kurzfassend die größten Probleme erklären.

Mit dem > Pfeil vor dem Text kann man das Untermenü aufmachen

Mit dem + kann man einen Unterpunkt anlegen

Mit dem – deaktiviert man den Unterpunkt wieder

Text in rot ist eine Änderung die noch nicht gespeichert wurde

Mit discard verwirft man alle Änderungen, mit preview übernimmt man sie.

Hier ist IPv6 aktiviert und daher ein Minus davor (damit könnte man es wieder deaktivieren)

Wenn man das Prinzip mal verstanden hat, ist es eigentlich ganz angenehm damit zu arbeiten. Als erstes aktivieren wir IPv6 auf dem PPPoE Interface. Dazu öffnen wir folgenden Baum mit dem Pfeil: Interface – ethernet – eth0 (oder das Interface wo das Modem dran hängt) – pppoe – 0 – ipv6 – address. Bei dem Unterpunkt autoconf der dann erscheint klickt man auf das + und aktiviert somit IPv6. Danach mit preview abspeichern, bestätigen und einmal auf dem Dashboard neu die PPPoE Verbindung aufbauen. Voila schon sollte eine IPv6 Adresse auf dem PPPoE Interface sein, wo vorher nur eine v4 drauf war.

Diese wird aber immer noch nicht ins private Netz geroutet dazu müssen wir noch ein paar Sachen setzen, genaugenommen ist es der Unterpunkt dhcpv6-pd im selben Baum (auf dem Bild rechts 4 Punkte über ipv6).

Wir setzen hier dhcpv6-pd – pd – 1 – interfaces auf eth1 (oder das Interface, wo unser PC dran hängt) und aktivieren den Unterpunkt prefix-only. Wenn wir nun die Interfaces neu starten, sollte nun das eth1 Interface eine IPv6 bekommen haben.

Wenn dies der Fall ist, muss nur noch radvd gestartet werden, damit auch Adressen per SLAAC an die Endgeräte vergeben wird. Dazu bewegen wir uns wieder im configtree unter interfaces – ethernet – eth1 (oder das, wo unser privates Netz dran hängt) – ipv6 – – prefix und geben dort das Prefix an, das wir auf eth1 bekommen haben, also z.b.: 2003:a:abcd:abcd::/64.

Danach das Zeug abspeichern und schon sollte der PC eine IPv6 bekommen, mit der man auch ins Internet kommt. Glückwunsch man hat den Edgerouter nun konfiguriert 🙂

Natürlich kann man das ganze auch auf der Konsole machen, das ist allerdings auch ein wenig gewöhnungsbedürftig und gerade für den Anfang fand ich die den configtree ganz schick. Ohne den configtree ist nach meinen Kenntnisstand IPv6 nicht zu konfigurieren.

In einen weiteren Beitrag werde ich noch beschreiben, wie man auf eth2 wo bei mir ja das Freifunknetz drauf hängt, eine statische Route mit NAT bzw. mit IPv6 sogar richtiges Routing (aber nur wenn man im Freifunk Franken Layer 3 Babel Netz aktiv ist) setzen kann.