• Themen zum Gatewaytreffen:
• =======================

Ergebnisse: https://pad.wazong.de/p/ffs-gatewaytreffen-ergebnisse

• DNS Server zentralisieren
• Loadbalancing fuer GWs
  • dynamischer Update fuer DNS vom einzelnen GW aus
• Tinc VPN vereinfachen. Ich bin dafür es auf Layer 3 zu ändern. Einfacher ist einfacher
  • TINC L3 mit TINC-Routing ist schlecht zu debuggen, ist mit Tinc 1.1 besser
    • tinc 1.1-pre12 gibt es gerade mal in Debian Experimental
  • TINC L3 mit OSPF erfordert Umkonfiguration OSPF
  • IC-VPN ist einfacher wenn wir schon dynamisches Routing haben, Anforderung ist da. Reicht aber wenn die Rechner die am ICVPN dran sind das können, oder nicht?
    • reicht nicht, die Netze muessen ja auch den anderen mitgeteilt werden. Die Vereinfachung 'alle privaten Netze' trifft leider nicht ganz. Wieso nicht? Soweit ich weiß hat Freifunk eigentlich nur noch 10.x, also 10/8 nach ic-vpn könnte reichen. Funkfeuer, so aus dem Kopf und eine ganze Menge IPv6 Netze, muss aber alles trotzdem irgendwo hin, d.h. irgend jemand muss dann dynamisch eine tinc-config umbauen und die anderen die Config aktualisieren mit StrictSubnets, was ich klar bevorzuge, sonst weiss keiner mehr wo was hin gehen koennte. Verschwindet irgendwie in der tinc-Wolke und kommt an oder auch nicht. Irgendwo. Genau das finde ich den Vorteil, ich muss mich nciht drum kümmern, es kommt an oder es ist nicht vorhanden oder es ist was kaputt.
• DHCP zentral * 3
  • statische IPs
  • maximal 1000 Clients, mehr macht kein Sinn, Veranstaltungsaware /21 -> 2048

• • • if (packet(24, 4) != 00:00:00:00) {
    •     set last_giaddr = packet(24, 4);
    • }
    • option space freifunk;
    • option freifunk-encapsulation code 82 = encapsulate freifunk;
    • option freifunk.server-id code 11 = { unsigned integer 8, unsigned integer 8, unsigned integer 8, unsigned integer 8, unsigned integer 8 };
    • subnet 10.191.255.0 netmask 255.255.255.0 {
    •     if (packet(24, 4) != 00:00:00:00) {
    •         option routers = packet(24, 4);
    •         option freifunk.server-id = packet(24, 4);
    •         option domain-name-servers = packet(24, 4);
    •         option dhcp-server-identifier = packet(24, 4);
    •     }
    • }

• • TINC wieder ueberall mit bird aktivieren, z.Zt. nur auf gw01 und gw05*
  • Bird/OSPF hätte ich gerne wieder los. Keiner kann es wirklich erklären, ist einfach zu kompliziert. Und ein Debugging finde ich auch nicht besser als bei Tinc. Wir haben da eine Config die irgendwie tut, aber selbst der Umbau, dass NUR 10.190/15 innerhalb OSPF geht, kann mir schon keiner sagen wie das geht. Ich will das eigentlich nicht haben, wie es im Moment ist.
    • kann ich mittlerweile erklaeren, es gibt verschiedene Moeglichkeiten, syntaktisch identisch, stehen nur an verschiedenen Stellen als 'filter':
      • nicht ins ospf schicken
      • nicht vom ospf nehmen
      • nicht ins Kernel Routing schreiben

• • • filter ffs {
      • if net ~ [ 10.190.0.0/15+ ] then accept;        Braucht man die Klammern? Wofür?, was bedeutet das +? + heisst dass Du auch 10.190.0.0/16 announcen darfst, nicht aber /14. Die Klammern waren sind in der Syntax und funktionieren nachweislich.
      • reject;
    • }
    • dann in der 'protocol kernel'-Sektion 'import all;' ersetzen durch 'import filter ffs;', das ist dann die Variante nicht ins Kernel Routing zu schreiben.
    • Wie sieht dann eine korrekte Config aus? Am besten mit Anmerkung was wofür ist in deutsch.
    • Ich habe gerade wieder die Config angeschaut und sorry, ich halte es für zu kompliziert, das blickt nur jemand der dauernd damit zu tun hat, dann mag es super sein, aber für uns ist es zu kompliziert.

• • Evtl. können wir bei den Gateways auch mit einer statischen Route schaffen, und lediglich ein paar wenige Kisten müssen dann dynamische Routen können, die dann die Segmente verbinden
• Weitere Gateways in Betrieb nehmen und weitere Gatewaybetreiber
• Neue kleinere Segmente in Betrieb nehmen die dann auch nur noch 2-3 Gateways haben und die zentralen DHCP Server verwenden
  • setzt aber vorraus, das wir die Segmentverbindungsprobleme gelöst bekommen und zentrale DHCP Server haben
• Nodes verschieben, Hilfstools, wie was wo, damit das noch mehr Leute können.
  • Gerne auch noch mehr Leute die Repozugriff haben.
• Konzept fuer direkt ausleitende Nodes und Moeglichkeiten das in die Firmware zu bekommen, also Node mit
  • dynamischer IPv4 aus seinem Segment
  • DHCP-Relay
    • isc-dhcp-relay gibt es nicht für openwrt bzw nur uralt Version. Ohne Relay der nicht zusammen mit isc-dhcp-server tut ist es nicht möglich.
  • Exit-Policy (alles, teilweise)
• statische IPs im FFS

• Tinc VPN strukturiert aufbauen:
  • dhcp Server jeweils connect zu allen anderen DHCP Servern (2 Verbindungen)
  • Gateways jeweils Connect zu allen DHCP Servern (3 Verbindungen)
  • Nach Bedarf Direktlinks, wenn hocher Traffic

Umsetzung wenn man nur Tinc L3 nehmen würde:

• Es wird ein Tinc Netz 10.190.0.0/15 erstellt auf jedem GW und den DHCP Servern, evtl. auch noch auf Serveren die Dienste innerhalb Freifunk anbieten
• 3 DHCP Server erhalten die IPs 10.191.255.1/15, 10.191.255.2/15, 10.191.255.3/15, diese werden bei den GWs als Relay Server eingetragen
• die Gateways nutzen ihre eigene IP im Tinc Netz, sollten sie mehrere Segmente haben alle Adressen angeben, die eigene Ip muss man bei L3 in Tinc eh angeben
• In jedem Segment muss mindestens 1 GW das Segment announcen, es können auch alle GWs ihr Segment announcen Bsp: 10.190.64.0/18.
• Jeder GW macht in Tinc 3 VPN Connects zu den 3 DHCP Servern, diese fungieren als Zentralen des VPN Netzes.
• Das wars!