Halb so wild, ist ein Netz zum Spielen und Lernen .
- Tunneldigger Fanlin neu gestartet, hat gesponnen
- Corny Nat-IP korrigiert, da sie von außen nicht pingbar war. Alte wieder aktiviert, ausgerollt und neu gestartet
=> Damit geht dann jetzt auch Domäne 51 wieder. Da gab es leider auf beiden Gateway zeitgleich unterschiedliche Probleme
c1024 neu gestartet weil komisch…
tj01 neu ausgerollt da sich hier wohl irgendwie unsere ifupdow2 Konfig hin verschlichen hat und daher keine bck-* Tunnel zu den anderen Gateways aufbauen konnte.
Remue-09 neu gestartet weil:
mesh-announce in der Rolle gateways_respondd leicht modifiziert damit Gateways eindeutige Hostnamen auf der Karte bekommen und auf alle Gateways ausgerollt.
py-respondd hab ich deaktiviert.
mesh-announce ersetzt damit vorerst unser bisher genutztes py-respodd von @descilla bis wir py-respondd „repariert“ haben.
Forum aktualisiert.
IPv4-NAT vom Firmware-Server repariert.
Interne IP hatte sich geändert -> iptables angepasst.
Dem Firmware-Server eine Native IPv4 spendiert da das NAT andauernd kapod is und die IP noch frei war…
Auf der neuen check MK VM Port 111 per iptables gedropt und iptables-persistent installiert weil das BSI Portmapper doof findet und Nervmails verschickt… rpcbind ist wohl eine Abhängigkeit von Check MK daher hab ich es nicht einfach deinstalliert.
Auf der check_mk-Kiste:
systemctl stop rpcbind
systemctl stop rpcbind.socket
systemctl disable rpcbind.socket
systemctl disable rpcbind
systemctl disable rpcbind.target
systemctl stop rpcbind.target
Ich hatte deinen Post vorher nicht gelesen. @corny456.
Doppelt hält besser
Zertifikate für den CheckMK-Server status.tld konfiguriert.
Was lange währt, wird endlich gut: corny läuft mit dem Ansible-Zweig as-router-als-gateway mit ifupdown2 produktiv.
eth0 kann auf Grund des folgenden Bugs noch nicht neu gestartet werden: https://github.com/CumulusNetworks/ifupdown2/issues/147
Dies kann manuell umgangen werden:
ip addr del 144.76.69.56 peer 144.76.69.37/32 dev eth0
Da mir aufgefallen war das diverse IPs aus zwielichtiger Herkunft ein starkes Interesse an unseren SSH Zugängen haben, hab ich mal eine kleine fail2ban rolle gebaut und auf alles was so da ist ausgerollt. Mit Ausnahme der debian 8 Maschinen. Da ist die Installation fehlgeschlagen und da wir die eh abreißen hab ich da keine mühe investiert.
IPs werden für 60 Minuten geblockt wenn sie mehr als 3 Fehlgeschlagene Logins binnen 10 Minuten hatten.
Wiki war nicht erreichbar. Updates gemacht und neu gestartet.
Reverse-User auf Parad0x neu angelegt und autossh auf dem Server an der BEZ repariert.
PS: + LAFP
Festplatte vom meshviewer war vollgelaufen.
Logrotate war kapod und somit hatten sich 15GB Syslog angehäuft.
Konkret mussten nur die Rechte von /var/log auf 755 gesetzt werden. Keine Ahnung warum das nicht so war…
Abschließend noch schnell n paar Updates gemacht und alles durchgebootet.
Stats Server upgedatet und neu gestartet.
rowe’s Hypervisor erhielt Updates und startete neu.
Blech unter TJ01 hat updates bekommen und einen Reboot gemacht.
würde demnächst ein upgrade von Ubuntu 18,xx auf 20.04 machen
oder auf ein neues Blech wechseln?