@Sandmann88: Die Freifunk-spezifische Software wird von Ansible automatisch installiert. Wir brauchen nur das nackte Betriebssystem und Zugriff per SSH. Solltest du noch nie Linux installiert haben, kann ich dir das gerne mal virtuell in einer VBox zeigen. Ich glaub den ganzen Rechner brauchst du dafür nicht nach Münster schleppen.
@genscher: Ich denke die Anforderungen sind nicht sehr hoch:
zwei PCI(e)-Netzwerkkarten (kein USB gefrickel)
Öffentliche IPv4
Debian 8
SSH-Server auf dem mein Schlüssel hinterlegt ist (root-Zugriff)
Abschottung von deinem Netzwerk oder Vertrauen
GRE-Weiterleitung
Und weil du den Strom bezahlst: stromsparend
Da nur GRE dürfte der Prozessor relativ egal sein, theoretisch müsste sogar ARM reichen, aber dann müssten wir alle Pakete per Hand kompilieren. Mir wäre x86 32 oder 64 bit von Intel oder AMD schon lieber
Ich denke Pis und Bananas können wir wegen dem Gefrickel mit USB-Netzwerkkarten vergessen. Außerdem halt wegen ARM aufwändiger.
Ein Problem könnte es bei der GRE-Weiterleitung geben. GRE benötige ich doch auch für IPSEC-Tunnel, oder ?
Dann muss ich schauen, ob ich noch öffentliche IPv4 Adressen bekommen kann, bzw. eine über habe, bei der GRE nicht benötigt wird.
In meiner alten Fritzbox 7170 wird GRE unter Portfreigaben angezeigt, und es klappt auch.
Somit sollten die neueren Router von AVM (hoffentlich) GRE durchleiten können.
Auf Dauer und für ein echtes Backbone will man glaube ich echte Hardware (keine Futuros) und auch eher keinen Privatanschluss (auch nicht mit 100/200 synchron) sondern schon so was Rechenzentrum mäßiges. Da bekommt man ggf. zwar auch nur 100mbit und kein Gigabit aber dafür sollte das Rechenzentrum an sich deutlich besser angebunden sein als so ein Privatanschluss und hat auch die möglichkeiten für Kühlung und Strom einer entsprechenden Kiste.
Es gibt btw noch div. kleinere Rechenzentren, Buch.de/Aschendorf wurde glaube ich schon erwähnt, afaik hat die Citey noch irgendwo was, und im Gewerbegebiet südlich der Zone am Albersloher Weg liegt auch noch mindestens ein Rechenzentrum, hinten am Schiffahrterdam ist außerdem noch globe wo Commander gearbeitet hat.
Wir haben das inzwischen getestet. GRE fließt wunderbar durch das NAT, aber GRETAP leider überhaupt nicht. Google spuckt zu Gretap behind NAT überhaupt nichts aus, ich habe keinen Ansatz, wie wir das weiter diagnostizieren können.
Bei GRE alleine ist das Problem, dass das Backbone dann teilweise als Route den Testserver gewählt hat und dies die Domäne-06 lahm gelegt hat. Das müsste man also gezielt mit spezifischerem Routing lösen. Selbst wenn Gretap funktionieren würde, würde es die ganze Domäne lähmen, wenn die Pakete durch die DSL-Leitung hin- und wieder zurück müssen. Also nicht ganz so einfach, wie wir uns das vorgestellt hatten und definitiv ohne spezifischeres Routing nicht machbar.
Bei IPv4 ist es durch die Nat-IPs so, dass der ausgehende Verkehr auch zumselben Backbone zurück kommt. Von dort wird er aber dann bei mehreren Tunneln nicht eindeutlich zurückverteilt und es gibt Quertraffic.
Bei IPv6 ist es leider so gar so, dass der eingehende Verkehr an ein beliebiges Backbone geschickt wird und von dort weiterverteilt wird. Es gibt also auf jeden Fall Querverkehr. Wir sollten da mittelfristig mit IPv6-Subnetzen, z.b. /64, gegensteuern.
Heute hat ein lokaler Internetanbieter und Betreiber eines Rechenzentrums bei mir angerufen und nach freifunk “gefragt”. Wir haben in der nächsten Woche ein Termin mit denen, um über eine mögliche Zusammenarbeit zu reden. Vllt kommen wir dann auch hier weiter
Dafür dürfen die RAs von einem gateway nicht durch ein weiteres gatway zum Client.
gw → gw → client
Dann wäre der client in zwei Netzen und könnte es sich wieder aussuchen. Mögliche Variante wäre dieses bridge-loop-avoindance ding, dass ich immer bewerbe, aber das nicht so perfekt läuft, dann wäre die bat-interfaces nicht direkt miteinander verbunden und man könnte das mit ebtables wegfiltern…
Weitere Erkenntnisse zu lokalen Gateways von den FFRL Routing Days:
Für IPv4 könnte man lokale Gateways halbwegs passabel aufbauen, weil mein die DHCP-Bereich spezifisch routen kann. Das Problem ist, dass Batman bei IPv6 völlig zufällig das Gateway nimmt. Sprich ein gewisser Teil der Clients in einer Domäne werden auch das lokale Gateway wählen, obwohl sie per VPN an einem regulären Gateway hängen. Das ist seitens Batman derzeit nicht vernünftig lösbar. Es würde dann also einiges an Volumen sinnlos durch die DSL-Leitung runter und wieder rauf gehen.
Das würde die ganze Domäne ausbremsen, daher ist das Konzept lokaler Gateways in einer normalen Domäne gestorben. Man kann es aber an großen Standorten einsetzen und dort eine eigene Domäne aufmachen, die dann allerdings nicht mehr mit anderen mescht.
@Sandmann88: Du kannst dein lokales Gateway dann offline nehmen.
Kann man entsprechende Pakte auf der verbindung vom lokalen Gateway zu den anderen Gateways nicht via iptables rausfiltern? Oder werden, die vom batman so verunstaltet, dass das nicht möglich ist?
…gestorben würde ich nicht sagen. Kreativität ist erforderlich!
Die lokalen Gateways müssen schlicht eine andere Broadcast Domain bedienen. Ich teste das gern mal. Dafür brauche ich aber ein kleines IPv4 Netz. Im IPv6 hab ich genug. Wo bekomme ich das Netz her? Darauf muss dann sowas wie das Aachener Modell darauf machen.
