|
|
| (26 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| | + | [[Category:Dokumentation]][[Category:Server]] |
| | == Git-Repositories == | | == Git-Repositories == |
| | | | |
| − | Für den Betreiber eines Freifunk Servers (Vserver) gibt es ein GIT Repository. Dieses erlaubt das fast automatische Aufsetzen eines Freifunk Servers (für Internet-Gateway). | + | Für den Betreiber eines Freifunk Servers gibt es ein GIT Repository. Dieses erlaubt das fast automatische Aufsetzen eines Freifunk Servers (für Internet-Gateway). |
| | | | |
| − | * https://github.com/cremesk/ffdd-server
| + | https://github.com/Freifunk-Dresden/ffdd-server |
| | | | |
| − | Informationen dazu sind derzeit in der README.md auf github gegeben, werden aber in Zukunft hier gepflegt. | + | == Freifunk Dresden Server (ffdd-server) == |
| | + | '''Bitte siehe dazu für Allgemeine Informationen sowie für eine [https://github.com/Freifunk-Dresden/ffdd-server#vorausetzungen Installations-Anweisung] auf die aktuelle Github [https://freifunk-dresden.github.io/ffdd-server/ README.md].''' |
| | | | |
| − | Bitte beachtet die Hinweise für andere Communities, welche auf der Dresdner Installation basieren sollen.
| + | Eine weiterführende Dokumentation findest du hier im Wiki auf der Seite: [[Server Internes]]. |
| − | | |
| − | == Basic Vserver ==
| |
| − | Dieses Repository bildet die minimale Funktionalität eines Servers für Freifunk Dresden. Der Vserver arbeitet wie ein Freifunk Knoten und ist soweit konfiguriert, dass dieser eine Knotenwebseite anbietet, Backboneverbindungen (fastd2) akzeptiert und via Openvpn Internettunnel für den Internetverkehr aus dem Freifunknetz aufbauen kann.
| |
| − | | |
| − | <font color="red">HINWEIS</font>: Der Vserver ist auf Freifunk Dresden zugeschnitten. Soll dieses als Basis für andere Freifunk Communities verwendet werden, müssen Anpassungen gemacht werden.
| |
| − | | |
| − | * Es empfielt sich dringend für andere Communities, dieses Repository zu clonen, da hier generelle Umstellungen zusammen mit der passenden Firmware für Dresnder Anforderungen erfolgen.<br/>Communities sollten dann auf das geclonte Repository (gilt auch für das "firmware" Repository) aufbauen.<br/>Jede Community trägt die alleinige Verantwortung und Kontrolle über ihr Netz und sollte eigene Erfahrene Leute/Admins bereitstellen. Hilfe von Dresden ist aber jederzeit möglich,<br/>aber Administrative Aufgaben oder Garantien werden nicht übernommen, da das einfach den organisatorischen Aufwand sprengt.<br/>Wir wissen selber nicht, wie sich das Netz in Zukunft noch verhält, wenn dieses weiter wächst.
| |
| − | | |
| − | * Routingprotokoll BMXD: Diese Protokoll wurde anstelle von bmx6 oder bmx-advanced aus verschiedenen Gründen gewählt (siehe http://wiki.freifunk-dresden.de/).<br/>Es wird vom eigentlich Author nicht mehr weiterentwickelt oder gepflegt. Für die Dresdener-Firmware wurden einige Fehler behoben.
| |
| − | | |
| − | * Anpassungen: Speziell gilt das für den IP Bereich und der Knotenberechnung.<br/>Aus Knotennummern werden mit ddmesh-ipcalc.sh alle notwendigen IP Adressen berechnet. (siehe [http://wiki.freifunk-dresden.de/index.php/Technische_Information#Berechnung_IP_Adressen Technische Informationen])<br/><br/>Freifunk Dresden verwendet zwei IP Bereiche, eines für die Knoten selber (10.200.0.0/16) und eines für das Backbone (10.201.0.0/16). Dieses ist technisch bedingt.<br/>Wird bei freifunk.net nur ein solcher Bereich reserviert (z.b. 10.13.0.0/16), so muss das Script ddmesh-ipcalc.sh in der Berechnung angepasst werden, so dass zwei separate Bereich entstehen.<br/>Die Bereiche für 10.13.0.0/16 würden dann 10.13.0.0/17 und 10.128.0.0/17 sein.<br/><br/>Das Script ddmesh-ipcalc.sh wird ebenfalls in der Firmware verwendet, welches dort auch angepasst werden muss.<br/>In der Firmware gibt es zwei weitere Stellen, die dafür angepasst werden müssen. Das sind /www/nodes.cgi und /www/admin/nodes.cgi. Hier wurde auf den Aufruf von ddmesh-ipcalc.sh verzichtet<br/>und die Berechnung direkt gemacht, da die Ausgabe der Router-Webpage extrem lange dauern würde.<br/><br/>In /etc/nvram.conf werden die meisten Einstellungen für den Vserver hinterlegt.<br/>Evt. kann noch /etc/issuer.net angepasst werden, was beim Betreiben von mehreren Vservern hilfreich ist.
| |
| − | | |
| − | * Weiterhin verwendet das Freifunk Dresden Netz als Backbone-VPN Tool fastd2.<br/>fastd2 ist ein für Freifunk entwickeltes VPN, welches eine schnelle und zuverlässige Verbindung bereitstellt.<br/>Bei der aktuellen Installation werden alle Verbindungen von Freifunk-Router zum Server zugelassen, welche sich mit dem korrekten Public-Key des Servers verbinden. Dieser Public-Key kann über http:///sysinfo-json.cgi ausgelesen werden.<br/>Verbindet sich ein Router mit einem Server erfolgreich, so "lernt" der Server diese Verbindung und erzeugt ein entsprechendes Konfigurationsfile unterhalb von '/etc/fastd/peers2'<br/>Später kann der Server umgestellt werden, so dass nur noch dort abgelegte Konfigurationen (Verbindungen) akzeptiert werden. Gesteuert wird dieses durch das Konfigurationsfile von fastd (/etc/fastd/fastd2.conf).
| |
| − | | |
| − | * /etc/openvpn enthält ein Script, mit dem verschiede Openvpn Konfiguration von Tunnelanbietern so aufbereitet werden,<br/>das diese für Freifunk Dresden richtig arbeiten. Wie in der Firmware läuft per cron.d ein Internet-check, der in der ersten<br/>Stufe das lokale Internet testet und wenn dieses funktioniert, wird das Openvpn Internet<br/>geprüft. Ist das Openvpn Internet verfügbar, wird dieser Vserver als Internet-Gateway im Freifunknetz bekannt gegeben.
| |
| − | | |
| − | * Auch der Vserver arbeitet als DNS Server für die Knoten, die ihn als Gateway ausgewählt haben. Der Vserver leitet<br/>allerdings die DNS Anfragen nicht über den Openvpn Tunnel, sondern geht direkt über den VServer Anbieter raus.
| |
| − | | |
| − | * Da VServer Anbieter verschieden sind, kann die Installation abbrechen. Hier sollten erfahrene Leute die Installation<br/>anpassen und mir einen Hinweis geben. Als Vserver kann '''NICHT''' jeder Anbieter genutzt werden.
| |
| − | | |
| − | | |
| − | '''Wichtig''' ist, dass tun/tap devices und alle möglichen iptables module möglich sind. IPv6 ist nicht notwendig, da das Freifunk Netz in Dresden nur IPv4 unterstütz (Platzmangel auf Routern, bmxd unterstützt dieses nicht)
| |
| − | | |
| − | === Vorausetzungen ===
| |
| − | * Notwendig ist eine Ubuntu minimal (15.04/16.04) oder Debian (8/9) Installation.<br/>Wähle dafür aber die "Server-Variante" nicht Desktop!
| |
| − | * Speicher: mind. 1GByte RAM, 2GByte Swap
| |
| − | * Netzwerk: min. 100Mbit/s<br/>Wenn weniger so sollte man nicht soviele Tunnel aufbauen und die bekanntgegebene Gateway-Geschwindigkeit in<br/>/etc/nvram.conf reduzieren. Das sollte man einfach über einen längeren Zeitraum beobachten und den niedrigstens Wert verwenden. Dazu aber den Traffic von verschiedenen Knoten aus testen!
| |
| − | batman_gateway_class="4mbit/4mbit"
| |
| − | * Kernel Module: tun.ko muss vorhanden sein. Evt sollte man sich vorher beim VServer Anbieter informieren. Nicht alle Anbieter haben einen Support im Kernel. Genutzt wird es vom Routing Protokoll, Backbone, Openvpn
| |
| − | * Virtualisierung: Wird der Freifunk Server auf einem virtuellen Server aufgesetzt, so funktionieren als Virtualisierungen KVM, XEN und LXC sehr gut.
| |
| − | | |
| − | === Installation ===
| |
| − | | |
| − | * Bringe Ubuntu/Debian auf die aktuelle Version. Das geht bei Ubuntu Schrittweise von Version zu Version.<br/>(https://help.ubuntu.com/community/UpgradeNotes)
| |
| − | * Am Ende kann die Ubuntu-Version mit überprüft werden.<br/>lsb_release -a
| |
| − | No LSB modules are available.
| |
| − | Distributor ID: Ubuntu
| |
| − | Description: Ubuntu 16.04
| |
| − | Release: 16.04
| |
| − | Codename: vivid
| |
| − | | |
| − | '''Wichtig''':
| |
| − | * '''/etc/hostname''' ''(hostname.domainname.de)'' > Bitte versichert euch nun das euer Hostname korrekt gesetzt ist und der<br/>ensprechende DNS Eintrag mit der öffentlichen IP von euch hinterlegt wurde!<br/>Andernfalls wird '''kein''' SSL-Zertifikat von letsencrypt zur Verfügung gestellt.
| |
| − | * Habt ihr bereits einen Registrierten Gateway-Knoten und die dazugehörige /etc/nvram.conf solltet ihr diese jetzt auf dem<br/>Server hinterlegen! Anderen falls werden diese automatisch generiert und eine neue Knotennummer vergeben und registriert.
| |
| − | | |
| − | | |
| − | Folgends cloned und Installiert das Repository. (Bitte verwendet eurer eignes geclontes Repository.)<br/>
| |
| − | Es wird beim ersten Durchführen eine kurze Zeit in anspruch nehmen da einige Packages und ihre Abhängigkeiten installiert,<br/>Files kopiert und am Ende noch einige Tools compiliert werden müssen.
| |
| − | | |
| − | git:
| |
| − | git clone https://github.com/cremesk/ffdd-server.git /srv/ffdd-server
| |
| − | cd /srv/ffdd-server
| |
| − | git checkout T_RELEASE_latest && ./init-server.sh
| |
| − | | |
| − | Alternative Installations Möglichkeiten:
| |
| − | | |
| − | curl:
| |
| − | | |
| − | sh -c "$(curl -fsSL https://raw.githubusercontent.com/cremesk/ffdd-server/T_RELEASE_latest/init_server.sh)"
| |
| − | | |
| − | wget:
| |
| − | | |
| − | sh -c "$(wget https://raw.githubusercontent.com/cremesk/ffdd-server/T_RELEASE_latest/init_server.sh -O -)"
| |
| − | | |
| − | | |
| − | Nun ist es bei der ersten Initialisierung ganz normal wenn am Ende in der "Summary for local" noch Failed's angezeigt werden.
| |
| − | | |
| − | * Manuelle Anpassung der Variablen.
| |
| − | | |
| − | Es müssen noch Host- & Community- Spezifische Dinge angepasst werden:
| |
| − | */etc/hostname
| |
| − | */etc/issue.net
| |
| − | */etc/nvram.conf
| |
| − | *servername
| |
| − | *contact
| |
| − | */etc/openvpn/
| |
| − | # please creates openvpn.conf with:
| |
| − | ./genconfig.sh yourvpnclient.conf/.ovpn
| |
| − | # for vpn user and password use:
| |
| − | /etc/openvpn/openvpn.login
| |
| − | */etc/fastd/peers2/
| |
| − | # To Create a Fastd2 Connection use:
| |
| − | '/etc/init.d/S53backbone-fastd add_connect vpnX.freifunk-dresden.de 5002'
| |
| − | | |
| − | Im letzten Schritt müssen die Änderungen noch übernommen und überprüft werden. (Dies geschieht auch automatisch aller 10min per cronjob).
| |
| − | Wir wollen aber sehen ob alles läuft und auch alles erfolgreich initialisiert wird:
| |
| − | | |
| − | salt-call state.highstate --local
| |
| − |
| |
| − | # Debug Mode
| |
| − | salt-call state.highstate --local -l debug
| |
| − | | |
| − | Gibt es hier keinerlei Fehler mehr sollte der Server einmal sauber neugestartet werden.
| |
| − | | |
| − | '''Optional''':
| |
| − | * ''/etc/firewall.user''<br/>Kann verwendet werden um eigene Firewallregeln (iptables) zu definieren. Diese werden in '/etc/init.d/S41firewall'<br/>eingebunden und automatisch mitgeladen.
| |
| − | * ''Änderung des Installations Path''<br/>Dies sollte unbedingt '''vermieden''' werden da ansonsten '''kein''' Autoupdate mehr gewährleistet werden kann! Es sollte reichen sich einen Symlink zu erstellen.
| |
| − | | |
| − | === Hinweis ===
| |
| − | Sollte es dazu kommen dass es mit 'salt-call state.highstate --local' direkt am Beginn der Initialisierung zu fehlern kommt oder es generell Probleme mit Services auf dem Server gibt sollte unbedingt erneut die '/srv/ffdd-server/init_server.sh' ausgeführt werden. Um auf ganz sicher zu gehen auch die aktuelle Version zu nutzen:
| |
| − | | |
| − | rm -rf /srv/ffdd-server && sh -c "$(wget https://raw.githubusercontent.com/cremesk/ffdd-server/T_RELEASE_latest/init_server.sh -O -)"
| |
| − | | |
| − | == Wichtig ==
| |
| − | Im moment gibt es keinen Schutz, dass Routerfirmware einer Communitiy sich mit Servern oder Routern anderer Communities verbinden. Es ist Fatal wenn sich die Netze wegen gleicher WLAN BSSID oder via Backbone verbinden. Da überall das gleiche Routingprotokoll verwendet wird, würden Geräte von verschiedenen Communities miteinander reden können und das Netz würde gigantisch groß und die Router überlasten.
| |
| − | | |
| − | '''Bitte einhalten''':
| |
| − | | |
| − | * Ändern der BSSID auf eine eigenen!
| |
| − | * Keine Verwendung von Registratoren anderen Communities (Webserverdienst zum Verteilen von Knotennummern)
| |
| − | * Kein Aufbau von Brücken zwischen Routern/Vservern verschiedener Communities über Backboneverbindungen. (das wird in zukunft noch unterbunden, dazu ist aber eine Änderung am Routingprotokoll notwendig).<br/>Verbindungen von Communities dürfen nur über das ICVPN erfolgen.
| |
| − | * /usr/local/bin/ddmesh-ipcalc.sh muss angepasst werden!
| |
| − | | |
| − | == Development ==
| |
| − | | |
| − | Um eine andere Release-Version zu benutzen ist ein notwendig in der ''/etc/nvram.conf'' die Option "branch=" anzupassen.
| |
| − | | |
| − | Default (Stable):
| |
| − | branch=T_RELEASE_latest
| |
| − | Development:
| |
| − | branch=master
| |
| | | | |
| | == Server-Anbieter == | | == Server-Anbieter == |
| | Im Laufe der Zeit haben wir bei vielen Anbietern Server für den Freifunk Dresden gebucht. Einige unserer Erfahrungen mit den verschiedenen Produkten sammeln wir hier. | | Im Laufe der Zeit haben wir bei vielen Anbietern Server für den Freifunk Dresden gebucht. Einige unserer Erfahrungen mit den verschiedenen Produkten sammeln wir hier. |
| | | | |
| − | === Internet Tunnel (OpenVPN) === | + | === Internet Tunnel (OpenVPN & Wireguard) === |
| | Ein VPN Server kann ein Exitpoint (Übergang zum Internet) sein. Der Betreiber sollte sich aber gegen die Störerhaftung schützen und entweder als Provider offiziell auftreten oder | | Ein VPN Server kann ein Exitpoint (Übergang zum Internet) sein. Der Betreiber sollte sich aber gegen die Störerhaftung schützen und entweder als Provider offiziell auftreten oder |
| − | einen OPENVPN Dienst in anspruch nehmen. Ein OPENVPN Dienst stellt ein weiteres VPN zu anderen meist annonymisierten Servern her, bei denne keine Daten geloggt werden. | + | einen OPENVPN/Wireguard Dienst in Anspruch nehmen. Ein OPENVPN/Wireguard Dienst stellt ein weiteres VPN zu anderen meist annonymisierten Servern her, bei denen keine Daten geloggt werden. |
| | | | |
| | Aktuell werden in Dresden verschiedene Zugänge verwendet: | | Aktuell werden in Dresden verschiedene Zugänge verwendet: |
| | * Freie Netze e.V. (arbeitet noch als Provider) | | * Freie Netze e.V. (arbeitet noch als Provider) |
| − | * [https://airvpn.org/ AirVPN] (OPENVPN) | + | * [https://airvpn.org/ AirVPN] |
| | + | * [https://www.mullvad.net/ Mullvad] |
| | * [https://nordvpn.com/ NordVPN] | | * [https://nordvpn.com/ NordVPN] |
| − | * [https://www.mullvad.net/ Mullvad] (OPENVPN) | + | * [https://www.ovpn.com/de/ OVPN] |
| | + | |
| | + | Die Konfiguration erfolgt im Verzeichnis <code>/etc/openvpn</code> / <code>/etc/wireguard</code>, wo es ein Script gibt, mit dem die Konfiguration für einen Vserver angepasst werden kann. |
| | + | |
| | + | === delta-networks === |
| | + | * URL: https://www.delta-networks.de/root-server/ |
| | + | Getestet wurde der 4G-SSD-io (6,49€) (16.01.2022) |
| | + | * Standort: Frankfurt |
| | + | * Funktioniert prinzipiell das TUN Interface muss aber erst über den Support aktiviert werden. |
| | | | |
| − | Die Konfiguration erfolgt im Verzeichnis ''/etc/openvpn'', wo es ein Script gibt, mit dem die Konfiguration für einen Vserver angepasst werden kann.
| + | === Unesty === |
| | + | * URL: https://server.unesty.net/cart.php?gid=3 |
| | + | Getestet wurde der VPS 2GB (4,99€) (17.01.2022) |
| | + | * Anbindung im schnitt 700Mbit |
| | + | * Standort: Frankfurt |
| | | | |
| | === myLOC === | | === myLOC === |
| | * URL: https://www.myloc.de/server-hosting.html | | * URL: https://www.myloc.de/server-hosting.html |
| − | Server:<br>
| |
| − | LXC / VM / Root / Dedicated
| |
| | | | |
| | === OVH === | | === OVH === |
| | * URL: https://www.ovh.com/world/ | | * URL: https://www.ovh.com/world/ |
| | + | |
| | + | === 1blue === |
| | + | * URL: https://www.1blu.de/server/vserver/ |
| | + | |
| | + | Auf nachfrage hin drosseln sie in keinster weise die Anbindung der Server. (stand 12.2015) |
| | | | |
| | === 1&1 === | | === 1&1 === |
| | * URL: https://hosting.1und1.de/vserver-tarife | | * URL: https://hosting.1und1.de/vserver-tarife |
| | | | |
| − | ==== „Virtual Server Linux Student“ (nicht empfohlen) ====
| + | „Virtual Server Linux Student“ nicht empfohlen! |
| − | * Anbindung: 100 Mbit/s
| |
| − | * Preis: 1,00€ (monatlich kündbar)
| |
| − | * Besonderheitem: Prozessanzahl auf 128 limitiert
| |
| | | | |
| − | Im Rahmen des Studentenangebotes [https://www.campus-code.de „Campus-Code“] bot 1&1 einen Vserver für nur 1€ monatlich an. Dieser eignet sich allerdings nur für Testzwecke oder als Backbone-Server für eine sehr kleine Anzahl an Knoten, da die Anzahl der laufenden Prozesse auf nur 128 (''numproc'') [http://www.techdudes.de/1278/campus-code-11-vserver-l/ limitiert] ist. Durch das Erreichen des Prozesslimits läuft der Server regelmäßig fehlerhaft oder ist nicht mehr erreichbar und muss über das Vserver-Control-Panel neu gestartet werden. Ein halbwegs stabiler dauerhafter Betrieb ist nur bei 15-20 Backbone-Verbindungen möglich. (Stand 10/2015)
| + | === Signaltransmitter (nur für kleine Server empfohlen empfohlen) === |
| | + | * URL: https://signaltransmitter.de/server/ssd-kvm-rootserver |
| | + | Getestet wurde der SSD KVM New Year Special 2022 (4 vCores, 6GB RAM, 80GD SSD, 6,99€) (16.01.2022) |
| | + | * Standort: Frankfurt |
| | + | * Bandbreite: angegeben mit 1Gbit erreicht wurden bei Tests verteilt über einen Tag nur 200mbit |
| | | | |
| − | === Netcup (nicht empfohlen) === | + | === Netcup === |
| | * URL: https://www.netcup.de/vserver | | * URL: https://www.netcup.de/vserver |
| − | Verbindung wird gedrosselt teilweise bis auf 1,6Mbyte/s dauerhaft.
| |
| | | | |
| − | ==== „Root-Server S“ ====
| + | Update Juni 2022: Verbindung wird bei Erreichen eines Limits auf 100 MBit/s gedrosselt. |
| − | * Virtualisierung: KVM
| + | @Mwyraz hat bei Netcup zu dem Thema nach dem aktuellen Stand gefragt. Gedrosselt wird ausschließlich bei erreichen des Fair-Use-Limits. Dieses liegt bei "vServern" der Generation 10 bei 80 TB/Monat. Bei Erreichen des Limits wird auf 100 MBit/s gedrosselt. Eine Drosselung bei Peak-Traffic findet keine Drosselung statt. Bei "Root-Servern" liegen die Limits bei 120 TB/Monat, die Drosselung bei 200 MBit/s. Die Drosselung auf 200 MBit/s findet hier auch statt, wenn mehr als 1h lang mehr als 1000 GBit/s übertragen werden. Der Betrieb eines Freifunk-Knotens (bei Ausleitung des VPN) ist mit den AGB voll vereinbar, es stehen auch keine anderen Gründe seitens Netcup entgegen. |
| − | * Anbindung: 100 Mbit/s
| |
| − | * Preis: 4,99€ (monatlich kündbar)
| |
| − | * Besonderheiten: Drosselung bei Überschreitung von 80 Mbit/s Bandbreite
| |
| | | | |
| | + | Stand 10/2015: Verbindung wird gedrosselt teilweise bis auf 1,6Mbyte/s dauerhaft. |
| | Netcup [https://forum.netcup.de/administration-eines-server-vserver/vserver-server-kvm-server/7471-fragen-zur-traffic-bremse/ drosselt Vserver], wenn diese über einen Zeitraum von 15 Minuten eine durchschnittliche Bandbreite von über 80 Mbit/s belegen. Die Drosselung erfolgt ohne Vorwarnung auf ca. 50KB/s, wodurch der Server praktisch unbenutzbar wird. Erst auf Nachfrage erfährt man vom Support von der Drosselung, die zumindest bei uns auf Bitte wieder rückgängig gemacht wurde. Falls man diesen Server für Freifunk sinnvoll nutzen möchte, sollte man selbst sicherstellen, dass die beanspruchte Bandbreite stets unter 80 Mbit/s bleibt. (Stand 10/2015) | | Netcup [https://forum.netcup.de/administration-eines-server-vserver/vserver-server-kvm-server/7471-fragen-zur-traffic-bremse/ drosselt Vserver], wenn diese über einen Zeitraum von 15 Minuten eine durchschnittliche Bandbreite von über 80 Mbit/s belegen. Die Drosselung erfolgt ohne Vorwarnung auf ca. 50KB/s, wodurch der Server praktisch unbenutzbar wird. Erst auf Nachfrage erfährt man vom Support von der Drosselung, die zumindest bei uns auf Bitte wieder rückgängig gemacht wurde. Falls man diesen Server für Freifunk sinnvoll nutzen möchte, sollte man selbst sicherstellen, dass die beanspruchte Bandbreite stets unter 80 Mbit/s bleibt. (Stand 10/2015) |
| − |
| |
| − | ==== „Root-Server L“ ====
| |
| − | * Virtualisierung: KVM
| |
| − | * Anbindung: 1 Gbit/s
| |
| − | * Preis: 18,99€ (monatlich kündbar)
| |
| − | * Besonderheiten: Drosselung bei Überschreitung von 80 Mbit/s Bandbreite
| |
| − |
| |
| − | Laut Netcup liegt bei den Gigabit-Servern eine durchschnittliche Bandbreite von nur 200 Mbit/s an. Wie beim [[Freifunk_Server_Handbuch#.E2.80.9ERoot-Server_S.E2.80.9C|„Root-Server S“]] gilt außerdem die selbe Regelung für die Überschreitung der 80-Mbit/s-Grenze. (Stand 10/2015)
| |
| | | | |
| | === ispOne business (nicht empfohlen) === | | === ispOne business (nicht empfohlen) === |
| | * URL: http://www.ispone-business.de | | * URL: http://www.ispone-business.de |
| | Trotz Internetflat werden Server abgeschaltet, gedrosselt oder sind drei Tage überhaupt nicht erreichbar (Traffic < 5TB/Monat). Der Support war anfänglich okay, aber seitdem vermutlich die Serverlast und der Datenverkehr zugenommen hat, wird nicht mehr auf Supportanfragen reagiert und behauptet, dass der Server gehackt wurde. Fragen nach Begrenzungen (um diese eventuell selber zuzusichern) bleiben unbeantwortet. Monatsverträge werden von Seiten ispOne ohne Begründung gekündigt. Man erfährt dies nur durch eine "Kündigungsbestätigung". | | Trotz Internetflat werden Server abgeschaltet, gedrosselt oder sind drei Tage überhaupt nicht erreichbar (Traffic < 5TB/Monat). Der Support war anfänglich okay, aber seitdem vermutlich die Serverlast und der Datenverkehr zugenommen hat, wird nicht mehr auf Supportanfragen reagiert und behauptet, dass der Server gehackt wurde. Fragen nach Begrenzungen (um diese eventuell selber zuzusichern) bleiben unbeantwortet. Monatsverträge werden von Seiten ispOne ohne Begründung gekündigt. Man erfährt dies nur durch eine "Kündigungsbestätigung". |
| − |
| |
| − | === 1blue ===
| |
| − | * URL: https://www.1blu.de/server/vserver/
| |
| − | * Traffic inclusive - bis jetzt keine Drosselung
| |
| − | * Preis: 7,90€ (monatlich kündbar)
| |
| − | * Laufzeit 1/12 Monate
| |
| − | * Anbindung vermutlich 100MBit/s
| |
| − | * 4GB garantierter RAM
| |
| − |
| |
| − | Auf nachfrage hin drosseln sie in keinster weise die Anbindung der Server. (stand 12.2015)
| |
Git-Repositories
Für den Betreiber eines Freifunk Servers gibt es ein GIT Repository. Dieses erlaubt das fast automatische Aufsetzen eines Freifunk Servers (für Internet-Gateway).
https://github.com/Freifunk-Dresden/ffdd-server
Freifunk Dresden Server (ffdd-server)
Bitte siehe dazu für Allgemeine Informationen sowie für eine Installations-Anweisung auf die aktuelle Github README.md.
Eine weiterführende Dokumentation findest du hier im Wiki auf der Seite: Server Internes.
Server-Anbieter
Im Laufe der Zeit haben wir bei vielen Anbietern Server für den Freifunk Dresden gebucht. Einige unserer Erfahrungen mit den verschiedenen Produkten sammeln wir hier.
Internet Tunnel (OpenVPN & Wireguard)
Ein VPN Server kann ein Exitpoint (Übergang zum Internet) sein. Der Betreiber sollte sich aber gegen die Störerhaftung schützen und entweder als Provider offiziell auftreten oder
einen OPENVPN/Wireguard Dienst in Anspruch nehmen. Ein OPENVPN/Wireguard Dienst stellt ein weiteres VPN zu anderen meist annonymisierten Servern her, bei denen keine Daten geloggt werden.
Aktuell werden in Dresden verschiedene Zugänge verwendet:
Die Konfiguration erfolgt im Verzeichnis /etc/openvpn / /etc/wireguard, wo es ein Script gibt, mit dem die Konfiguration für einen Vserver angepasst werden kann.
delta-networks
Getestet wurde der 4G-SSD-io (6,49€) (16.01.2022)
- Standort: Frankfurt
- Funktioniert prinzipiell das TUN Interface muss aber erst über den Support aktiviert werden.
Unesty
Getestet wurde der VPS 2GB (4,99€) (17.01.2022)
- Anbindung im schnitt 700Mbit
- Standort: Frankfurt
myLOC
OVH
1blue
Auf nachfrage hin drosseln sie in keinster weise die Anbindung der Server. (stand 12.2015)
1&1
„Virtual Server Linux Student“ nicht empfohlen!
Signaltransmitter (nur für kleine Server empfohlen empfohlen)
Getestet wurde der SSD KVM New Year Special 2022 (4 vCores, 6GB RAM, 80GD SSD, 6,99€) (16.01.2022)
- Standort: Frankfurt
- Bandbreite: angegeben mit 1Gbit erreicht wurden bei Tests verteilt über einen Tag nur 200mbit
Netcup
Update Juni 2022: Verbindung wird bei Erreichen eines Limits auf 100 MBit/s gedrosselt.
@Mwyraz hat bei Netcup zu dem Thema nach dem aktuellen Stand gefragt. Gedrosselt wird ausschließlich bei erreichen des Fair-Use-Limits. Dieses liegt bei "vServern" der Generation 10 bei 80 TB/Monat. Bei Erreichen des Limits wird auf 100 MBit/s gedrosselt. Eine Drosselung bei Peak-Traffic findet keine Drosselung statt. Bei "Root-Servern" liegen die Limits bei 120 TB/Monat, die Drosselung bei 200 MBit/s. Die Drosselung auf 200 MBit/s findet hier auch statt, wenn mehr als 1h lang mehr als 1000 GBit/s übertragen werden. Der Betrieb eines Freifunk-Knotens (bei Ausleitung des VPN) ist mit den AGB voll vereinbar, es stehen auch keine anderen Gründe seitens Netcup entgegen.
Stand 10/2015: Verbindung wird gedrosselt teilweise bis auf 1,6Mbyte/s dauerhaft.
Netcup drosselt Vserver, wenn diese über einen Zeitraum von 15 Minuten eine durchschnittliche Bandbreite von über 80 Mbit/s belegen. Die Drosselung erfolgt ohne Vorwarnung auf ca. 50KB/s, wodurch der Server praktisch unbenutzbar wird. Erst auf Nachfrage erfährt man vom Support von der Drosselung, die zumindest bei uns auf Bitte wieder rückgängig gemacht wurde. Falls man diesen Server für Freifunk sinnvoll nutzen möchte, sollte man selbst sicherstellen, dass die beanspruchte Bandbreite stets unter 80 Mbit/s bleibt. (Stand 10/2015)
ispOne business (nicht empfohlen)
Trotz Internetflat werden Server abgeschaltet, gedrosselt oder sind drei Tage überhaupt nicht erreichbar (Traffic < 5TB/Monat). Der Support war anfänglich okay, aber seitdem vermutlich die Serverlast und der Datenverkehr zugenommen hat, wird nicht mehr auf Supportanfragen reagiert und behauptet, dass der Server gehackt wurde. Fragen nach Begrenzungen (um diese eventuell selber zuzusichern) bleiben unbeantwortet. Monatsverträge werden von Seiten ispOne ohne Begründung gekündigt. Man erfährt dies nur durch eine "Kündigungsbestätigung".
