net.netfilter.nf_conntrack_max war in /etc/sysctl.conf korrekt gesetzt, jedoch war ein viel geringerer Wert (32k) in Verwendung. Das lag vermutlich daran, dass der Wert Hash-Wert (warum auch immer) zu klein gesetzt war/wurde. Wert in /sys/module/nf_conntrack/parameters/hashsize neu gesetzt und Einstellungen mit /sbin/sysctl -p neu geladen. Nun glühen die Leitungen wieder.
Zusammen mit @Parad0x habe ich gerade die Domäne-14 ins Ansible gesteckt und auf Remue-07 ausgerollt. Zusätzlich wurden für ffwaf-srv4 Tunnel auf Fanlin angelegt.
Zu meinem Bedauern hat sich @paulinsche für Ubuntu statt Debian entschieden, sodass er diesen Host alleine aufsetzen und verwalten muss. Die Tunnel stehen jedenfalls bereit.
Dazu haben wir zunächst die bestehende bind-Rolle in bind_services für die Service-VM und bind_gateway für den Teil, der auf den Gateways läuft, aufgeteilt und geprüft, dass alles noch läuft.
Danach haben wir die automatische Serialisierung der Zonen per Linux-Zeitstempel eingebaut. Das führt leider dazu, dass auf der Service-VM jedes mal in Ansible eine Änderung durchgeführt wird. Dies lässt sich nicht verhindern, da man nicht zuverlässig prüfen kann, ob irgendwo sich irgendwas verändert hat. Die Einträge sind also immer gelb, das ist aber auch nicht weiter schlimm.
Es muss jetzt noch der Zonentransfer an die Backbone-Server konfiguriert werden, wir brauchen von @void eine Liste mit allen derzeitigen Einträgen und dann, wenn alles läuft, kann bei der domainfactory der Eintrag geändert werden.
iptables Regeln auf dem Blech der des* VMs angepasst. Das dort fehlerhaft konfigurierte MASQUERADE hat die Quell und Ziel Adressen an Stellen verändert, wo sie nicht verändert werden sollten. Das hat zu einer kurzen Unterbrechnung beim Monitoring auf BB fanlin geführt, was @fanlin instantan gefixt hat.
Ich habe auf remue-07 l2tp aktiviert. Der Dienst ist aktuell nicht reboot fest, weil ich sehen will, wie es sich macht. Installations-Hinweise zum Asiblelisieren, schick ich an @MPW …
Auch noch anderes Zeug installiert, für den Map, aber das ist sekundär.
remue-07 ist gerade nach einem „batctl if del tap-ffwaf-srv4“ gestorben. Ich vermute, das übliche Problem: crash im Kernel, durch batman, wenn ein Interface entfernt wird.
Domäne-14 würde jetzt die Aufteilung in mehrer Broadcast-Domänen unterstützen. Das netz auf bat0 nenne ich ab jetzt immer br-client0.
Allerdings stehen einige Probleme zu Lösung an. Problem:
Aus der site.conf
-- Prefixes used within the mesh. Both are required.
prefix4 = '10.43.112.0/21',
prefix6 = '2a03:2260:115:1400::/64'
ipv4: es werden Netze aus einem passenden Netz via DHCP vergeben. Dazu wurde ein Interface br-client1 auf ffwaf-srv4 und remue-07 angelegt und dort aus einem /28 vergeben. Um nicht mit den IP-Adressen verschwenderisch umzugehen, laufen die DHCP für das Netz im Failover-Mode. Insgesamt läuft das mit dem Routing auf remue-07 noch nicht rund, denn der bird startete nicht richtig (habe sysctrl enable bird*) ausgeführt und die Netze werden nicht in den ffnet-Tabelle übernommen, außer ich mache das (so wie ich das in Warendorf immer gemacht habe) von Hand: ip route replace 10.43.120.0/28 dev br-client1 table ffnet. Adressen aus der site.conf dürfen also nicht genutzt werden.
ipv6: die Knoten verbreiten weiter das IPv6-Netz, dass die Clients auf br-client1 dann nicht erreichen können, weil sie annehmen, dass es ohne Mitwirkung eines Routers geht.
Fazit: sowohl in br-client0 als auch br-client1 müssen Adressen genutzt werden, die nicht in der site.conf stehen dürfen.
Die Frage außerdem ist, wie man die beiden Netz in die Karten bekommt. An der Stelle habe ich gestern aufgehört.
Alle Änderungen findet man auf remue-07 so:
cd /etc && git diff e9405923fc063544a17f513d31b6788c12556c2f
Domäne-14 kann jetzt, wahrscheinlich nicht reboot-sicher mit zwei batman-Interfaces umgehen. Damit das in Zukunft auch funktioniert, müssen vermutlich neue VPN-Knoten immer angemeldet und freigeschaltet werden. Siehe dazu auch hier.
Muss die Realität mal in die Skripte gießen und dann einen Reboot versuchen.