Münster-Stadt hat jetzt zwei vollwertige Gateways, sowohl IPv4 als auch IPv6 klappt auf beiden. Die IPv6s sind an beiden Gateways extern erreichbar.
Die NAT-IP im loopback-Interface ist jetzt statt /30 auf /32, vermutlich ist dies für die Punkt-zu-Punkt-Verbindungen erforderlich.
Gestern hat es sn-descilla-1 zerissen. Syslog wenig aussagekräftig. Nur einen Berg icmpv6 Fehlermeldungen, dann tot. Neu durchgestartet.
Nachdem ich gestern die fastd Rolle gebaut habe, habe ich mich heute an die interfaces gesetzt.
Hier ist der Pull-Request dazu: https://github.com/FreiFunkMuenster/ansible-ffms/pull/5
Getestet wurde es auf der ffmstd Domäne. Dort lief es, bitte dennoch durchgucken und bei Fragen / Fehlern am Pull-Request kommentieren.
Simon
added sn-kgbvax-3
Mit der bitte um neue Experimental @void
Danach sollten wir genug Kapazität haben das wir die GWs stückweise aus dem fastd nehmen können.
Auf dem Buildserver war die Festplatte voll, alte Firmware Images entfernt jetzt kann wieder gebaut werden.
webserver: gzip für application/json angeschaltet (für nodes.json, etc al)
https://forum.freifunk-muensterland.de/t/ladezeit-karte-optimieren/114?source_topic_id=75Wir konnten heute das Ansible Template für fastd fertigstellen und testweise auf sn-sense-2 applizieren.
Das Template ist ansible-ffms comitted und bewusst noch nicht in der supernodes.yml eingetragen, damit nicht versehentlich die Keys auf den bestehenden Servern überschrieben werden.
@vax: Hier wäre eine Einbindung deiner multi-fastd Konfiguration sinnvoll.
multi-fastd ist dead simple:
Ich schau mir mal das Template an
Wir haben heute Abend angefangen, wie letzten Mittwoch besprochen, die erste VM für die neue Domäne zu basteln, die dann an das Backbone angeschlossen werden soll.
Zur Erklärung: Wir haben uns kurz überlegt, ob es dazu eine separate Rolle geben soll, uns dann aber dafür entschieden, dass jede Rolle ihre eigenen Abhängigkeiten auflösen muss. Denn sonst hat man auch auf Servern, die kein fastd bräuchten, nacher das Repo hinterlegt. Das kann bei apt-get theoretisch zu Abhängigkeitsproblemen führen und ist auch unsauberer.
Grüße
Matthias
Ergebnis der Fehlersuche zum DHCP im Mumble: DHCP authorative auf allen DHCP-Servern deaktiviert, DHCP-Server auf Superknoten abgeschaltet.
Der virt-Host, welcher die fanlin-Maschinen beheimatet, wurde auf 10 MBit/s kastriert!
Sehr geehrter Herr Faryn,
wir haben einen von Ihrem Server ausgehende DOS Angriff (http://de.wikipedia.org/wiki/Ddos) festgestellt.
Diese Angriff stellt ein Verstoß gegen §3.8 unserer Allgemeinen Geschäftsbedingungen ( http://agb.myloc.de/ ) dar.
Diese Bedingungen hatten Sie bei der Bestellung des Server akzeptiert.
Bitte beachten Sie das Sie Administrator des Servers und somit für die
Sicherheit und die Einhaltung der Allgemeinen Geschäftsbedingungen
verantwortlich sind.
Bitte nehmen sie Stellung dazu.
Auszug aus dem “Beweis”:
19:43:46 UDP: 85.14.245.16:14242 -> 89.166.227.139:34200 flags: 0x00 size: 114
19:43:47 UDP: 85.14.245.16:14242 -> 185.22.140.49:2116 flags: 0x10 size: 188
19:43:47 UDP: 85.14.245.16:14242 -> 80.143.24.121:59779 flags: 0x00 size: 188
19:43:47 UDP: 85.14.245.16:14242 -> 79.243.172.87:52353 flags: 0x00 size: 121
19:43:47 UDP: 85.14.245.16:14242 -> 87.166.135.41:59672 flags: 0x02 size: 156
19:43:47 UDP: 85.14.245.16:14242 -> 185.63.124.17:53946 flags: 0x00 size: 188
19:43:47 UDP: 85.14.245.16:14242 -> 87.133.115.56:55195 flags: 0x10 size: 114
19:43:47 UDP: 85.14.245.16:14242 -> 185.22.142.237:2405 flags: 0x00 size: 121
19:43:47 UDP: 85.14.245.16:14242 -> 84.187.49.56:56052 flags: 0x18 size: 156
19:43:47 UDP: 85.14.245.16:14242 -> 109.91.134.60:48767 flags: 0x00 size: 142
19:43:47 UDP: 85.14.245.16:14242 -> 185.63.124.17:53946 flags: 0x10 size: 114
Und hier meine Antwort:
Hallo!
UDP-Port 14242 wird von mir für fastd-VPN-Tunnel genutzt. Die
Verbindungen werden von den Clients auf Port 14242 UDP initiiert und
entsprechend auf einem anderen Zielport beantwortet. Das System arbeitet
wie gewollt und konfiguriert.
Die Vermutung einer ausgehenden DOS-Attacke und damit ein Verstoß gegen §3.8 der AGB ist ergo gegenstandslos.
Weitere Infos folgen.
So, alles wieder freigeschaltet. Angeblich …
Sehr geehrter Herr Faryn,
die IP-Adresse wurde erfolgreich freigegeben.
Meine Antwort:
Guten Morgen.
Danke für die Wiederfreischaltung.
Ein Speedtest in verschiedene Rechenzentren ergab allerdings keine
wirklich befriedigenden Ergebnisse. Insbesondere der Upload scheint noch
stark gedrosselt zu sein.
Hier mal ein Auszug:
Testing from myLoc managed IT AG (93.186.196.76)…
Hosted by HillCom Solutions (Alsfeld) [33.58 km]: 22.663 ms
Testing download speed…
Download: 202.19 Mbit/s
Testing upload speed…
Upload: 2.29 Mbit/s
[…]
Bitte überprüfen sie nocheinmal die Konfiguration ihrerseits.
Mehr in Kürze.
Nach einigen zusätzlichen iperf-Messungen bekam ich folgende Nachricht:
Hallo Herr Faryn,
ich werde das Ticket an unser Netzwerk Team weiterleiten, bitte haben Sie etwas Geduld.
Die Server fanlin, sn-fanlin-1, sn-fanlin-2 sind jetzt wieder in Betrieb.
Auf dem Server fanlin haben wir den fastd mal direkt abgeschaltet gelassen.
Server “greyworm” bereitgestellt mit Debian 8.
An @Parad0x übergeben zwecks Einrichtung Proxmox und 2x VM für SN.
sn-sense-2 ist unkonfiguriert, daher wäre dies ein guter Kandidat für die zweite VM in Domäne-1.
Ich ziehe den in der hosts-Datei daher jetzt rüber.
Wiki auf den aktuellen Stand gebracht. Falls Probleme auftreten, die ich beim Testen nicht gefunden habe, dann gerne direkt bei mir melden.
Mein Root hat wieder IPv6 (siehe https://forum.freifunk-muensterland.de/t/ipv6-traffic-faellt-lokal-raus-sn-descilla-1/128/ ). Vermutlich lag das Problem an der gesetzten forwarding.conf. Zur Sicherheit habe ich jedoch die iptables Regeln auf meinem Root angepasst, sodass keine v6 Pakete mit einer v6 Source Addresse aus dem FFMS Addressbereich mehr rausgehen können. Außerdem läuft ein TCPdump auf genau diese Filterung, ist bis jetzt aber noch nichts aufgeschlagen.
Für die FFMStd Domäne werfe ich gerade rudimentäre Statistiken auf mein Graphite/Grafana: http://5.9.86.151:3000/dashboard/db/ffmstd
Soll mittelfristig auf den FFMS Server geworfen werden, ist im Moment aber wohl zu umständlich.
Arbeiten an greyworm
ToDos
Netzwerkkonfig in den VMs
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 89.163.247.45
netmask 255.255.255.255
pointopoint 146.0.42.1
gateway 146.0.42.1