Nutzung der Ansible-Vorlage als Fremd-Community - erste Fortschritte, Lernkurve


#1

Hallo,

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.

nette Grüße, Martin


#2

Hi,

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.

Liebe Grüße
Matthias


#3

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.


#4

IPv4:
https://github.com/FreiFunkMuenster/ansible-ffms/blob/master/roles/iptables/templates/rules.v4.j2

und IPv6:
https://github.com/FreiFunkMuenster/ansible-ffms/blob/master/roles/iptables/templates/rules.v6.j2

Voraussetzung ist, dass die ffrl tunnel interfaces mit tun- beginnen.


#5

Wir hatten das Problem ganz am Anfang mal. Dort liefen bei uns die ffrl tunnel noch nicht sauber.


#6

Hi,

Die iptables-rules sind bei mir genau so 1:1 aus dem ansible übernommen.

Wenn es bei euch das Problem auch schon gab, heißt dann das erst mal abwarten?
Bis das routing in unser Netz draussen mal public ist?

Aber die Clients bekommen ja Antworten auf DNS-Anfragen, nur der Gateway bekommt keine. Der Zusammenhang will mir nicht in den Kopf.


#7

Es gibt kaum einen Zusammenhang. Einmal ist es Forwarding, das andere Mal ist es Input/Output. Das sind zwei verschiedene Regelsätze.


#8

Der Schuldige ist gefunden!

in der Config von Hetzner stand unter
/etc/sysctl.d/99-hetzner.conf
ein
net.ipv4.conf.all.rp_filter=1

Das macht sich wohl bei redundanten Uplinks mit FFRL gar nicht gut.

Grüße, Martin


#9

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.