wir https://www.freifunk-donau-ries.de
nutzen derzeit zum Aufbau einer eigenen Infrastruktur einen Fork eurer Ansible-Konfiguration und möchten euch ein wenig Feedback geben.
Bis dato liefen ein paar Problemchen auf, zu deren Behebung wir erst peu à peu in die Tiefen des Ansible eintauchen.
DNS-Server und Option Bind
Im DHCP-Server sind, falls man den Bind-Server weglässt,
entsprechende DNS-Server einzutragen.
Als Vorgabe-Wert steht hier die IP des Gateways
DNS, IP-Tables, mangeling
Problem: sobald in /etc/iptables/rules.v4 nachfolgende Regeln eingetragen sind
bekomme ich von Gateway aus von keinem Nameserver entsprechende Antworten.
Versucht wurden:
die des Providers Hetzner, ja ob die wohl Anfragen von Außen mögen…
8.8.8.8
8.8.4.4
Folge sind:
lange Anmeldezeiten über ssh
Ich bekam bind nicht wirklich zu laufen
ich habe den DNS-Eintrag im DHCP verbogen
*mangle
:POSTROUTING ACCEPT [0:0]
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -j MARK --set-xmark 0x1/0xffffffff
Für angepasste IPTables-Regeln zum Betrieb vn Bind auf dem Gateway selbst bin ich derzeit noch nicht kreativ genug.
unklare Perfomance, Erreichbarkeit einzelner http-Server
Grundsätzlich rennt l2tp und die Anbindung an FFRL
bei einer lokalen 32Mbit/s-Leitung und einem WR841N als VPN-Node einen Testdownload mit 31Mbit/s zu bekommen ist schon fein, das würde mit FASTd nie gehen.
Jedoch sind einzelne Web-Sites praktisch nicht nutzbar
Beispiel: slack.com
Nun würde ich ein mtu-Problem vermuten.
Eure Config wurde dahingehend nicht angefasst.
ein “ip a” bringt folgendes zu Tage:
eth0: mtu 1500
batnn: mtu 1500
brnn: mtu 1364
gre@none: mtu 1476
gretap0@NONE: mtu 1462
tnn-services: mtu 1458
tun-ffrl-nn: mtu 1400
l2tpnn: mtu 1364
Der Client bekommt hinter dem Node eine mtu 1280
Wenn ich teste http://www.routertech.org/viewtopic.php?t=1720
bringe ich angeblich Pings mit 1472 unfragmentiert durch die Leitung.
Hierauf kann ich mir derzeit noch keinen Reim machen.
wir hatten uns nie groß mit der MTU beschäftigt, weil wir damit bisher kaum Probleme hatten. Weder in Fastd- noch in L2TP-Domänen.
Wenn du da eine Idee hast, wie man das sauber gerade ziehen kann, sind PRs sehr willkommen. Wir hatten da kürzlich noch was übernommen und die MSS korrekt gesetzt. Ich weiß nicht, ob du das schon drin hast bei dir.
Die DNS-Rolle ist wohl die am wenigstens generalisierte. Wir haben eine interne DNS-Auflösung von einem Server aus mit Zonentransfer. Da steht aber als TLD fest .ffms drin, das muss noch parametrisiert werden.
An den Tunnel zum ffrl muss via iptables und ip6tables passend gesetzt werden. Icmp Packet zu gross die von den vpn- und anderen Servern gesendet werden, müssen in der Freifunk Tabelle nachgeschlagen werden. Wir via fwmark und sysctrl gesetzt. Inwie weit das alles im ansibel ist, kann ich nicht sagen.
Das ist ein Sicherheits-Feature, dass man auf Routern dann einsetzt, wenn man Sicher weiß, dass von gewissen Stellen, nur Pakete mit bestimmten Quell-IP-Adressen kommen dürfen. Ich würde mal vorschlagen das Feature auf den Bridges zum BATMAN anzustellen, dann werden alle nicht zulässigen IP-Pakete als 192.168.x.x und 10.x.x.x die nichts in der Wolke zu suchen haben gleich am VPN-Server verworfen und nicht zum ffrl transportiert (wo sie dann verworfen werden).
Wir das an jedem VPN-Server eingetragen, kann/sollte das auf den Tunneln dann abgestellt werden. Für ipv6 ist das ganze wohl in die iptables gewandert: target ist rpfilter. Für ipv4 gibt es die Kernel und die iptables Variante.