Tunnelserver 2018


#1

Hallo liebe Mitfunker,

nach einer längeren Vorbereitungsphase und einem mehrwöchigen Testbetrieb gehe ich davon aus, dass unser neuer Tunnelserver soweit ist, dass wir mit der Migration der bestehenden Tunnel beginnen können.

Der ursprüngliche Plan, die 78.41.115.228 auf den neuen Server zu portieren, wurde aus verschiedenen Gründen verworfen. Es wird also Eure Mithilfe erforderlich sein.

Die meisten Tunnel, die es auf dem alten Tunnelserver 78.41.115.228 gab, wurden bereits portiert, wer möchte, kann also anstelle des Endpunkt „remote 78.41.115.228“ die IP 78.41.118.150 als Gegenstelle verwenden.
Diese IP-Adresse wird redundant über nessus und krypta sowie zusätzlich auch per OLSR angekündigt und sollte so stets erreichbar sein.

Zur Verfügung stehen zwei Betriebsmodi mit den Namen br-641 und br-642. Voreingestellt ist br-641. br-641 bedeutet, es steht auf einer Bridge (br) IPv6 (6) und IPv4 (4) mit jeweils OLSRv1 zur Verfügung. Dies wird mit den meisten Funkinseln -auch mit älterer Hard- und Firmware- kompatibel sein. Für IPv4 ändert sich nichts. Wer bisher einen statischen SIT-Tunnel betrieben hat, kann diesen jetzt einmotten und auf natives IPv6+OLSRv1 wechseln.

Für alle Besitzer eines EdgeRouters mit Funkfeuer-Paketen wird der Modus br-642 (Bridge mit IPv6, IPv4, gemischter Betrieb OLSRv1 für IPv4 sowie OLSRv2 für IPv6) empfohlen.

Anleitungen sind unter https://wiki.funkfeuer.at/wiki/OpenVPN-Tunnel_zu_Funkfeuer zu finden.

IPv6 kann in beiden Varianten eventuell noch von Routingumstellungen betroffen sein. Schlimmstenfalls wird ein Hop mehr als notwendig aufscheinen.

Noch ein Hinweis: Das aktuelle Ubuntu 18.04 und das aktuelle Debian 9.0 kommen mit OpenVPN 2.4. In dieser Version wurde die Option “comp-lzo” durch “compress” ersetzt. Als Parameter stehen “lzo” und “lz4” zur Verfügung. Voreingestellt ist bei uns, lzo. lz4 soll performanter sein. Gerne stelle ich das auf Anfrage individuell um. Die bisher häufigste Fehlerursache sind nicht übereinstimmende Kompressionseinstellungen, gefolgt von MTU-Problemen.

[Update: unter http://78.41.118.150/ kann man den Statusseiten einsehen, wobei die Scripts wegen geändertem Output noch ein paar Fehler haben (IPv6-Routen, Quelladresse, …) @pocki wird sich das demnächst dankenswerterweise anschauen.]


#2

Die Anzeige der IPv6-Routen ist mal gefixt.
Sonst noch was?


#3

Danke für’s richten via cl_ip6.


#4

Aufruf:

Die Inhaber der folgenden Tunnel/Nodes mögen bitte bei nächster Gelegenheit auf den neuen Tunnelserver umsteigen:

ley21
goldegg26
marburg (hier fehlen konkrete Angaben und Daten; der Knoten heisst „marburg“, der Tunnel „fon1“, Standort unbekannt, Tech-C Petr ohne E-Mailadresse - dieser Tunnel wird erst angelegt, wenn die zum Betrieb erforderlichen un d zweckmäßigen Daten eingemeldet wurden. Der Tunnel wurde zudem bisher von einem -laut whois- deutschen Anschluss aus genützt - da sich das eventuell nicht mit dem Vereinszweck deckt, bitte um Argumente, wieso wir diesen Tunnel brauchen. Kontaktaufnahme via Forum, da individueller Kontakt bisher gescheitert ist.)
hofj
rosen2
wmg64

Danke, LG
Erich


#5

Kritische Rückfrage dazu:

Also beim Tunnel marburg hast du’s erklärt, aber warum pobierst du’s bei den anderen nicht zunächst mal mit anschreiben des Tech-Contacts und oder des Knotenbesitzer, anstatt einen öffentlichen Aufruf zu machen, den vermutlich sehr viele aber nicht die jenigen die’s betrifft lesen werden?

Oder ist das bereits passiert und nachdem bei all diesen keine Reaktion gekommen ist versuchst du’s jetzt mit “public shaming”? :wink:


#6

@kaefert stell Dir vor, ich habe tatsächlich jeden einzeln angeschrieben - zum Teil mehrfach und habe meistens auch Antworten erhalten. Die nun gelisteten Tunnel sind noch in Betrieb zum Teil hat es in der Vergangenheit mit der Kommunikation geklappt.
Ich habe mir erlaubt, den Aufruf ins Forum zu stellen, weil a) die Abschaltung mit Beginn der Sommerferien ein eingetretener Fakt sein wird und b) Leute, die Knoten hinter diesen Tunneln haben, es rechtzeitig wissen sollten und c) man vielleicht so doch noch vor der Abschaltung den Maintainer erreicht. d) Und, weil der alte Vorstand mir keine Mailingliste für Tunneluser zugeteilt hat, obwohl wohl nicht alle auf Wien mitlesen e) und damit es nachher nicht heisst, ich hätte das nirgendwo angekündigt :wink:

Die Tunnel, die nicht verwendet wurden und, wo der Kontakt nicht herstellbar war, sind zum Großteil ohnehin schon deaktiviert oder wurden erst gar nicht übersiedelt.

Vielleicht weiss auch jemand, was mit Petr ist, und wieso er sich nicht meldet?


#7

Der Tunnelserver hat nun eine Bridge br-64a. Das „a“ steht für „all“. Sie spricht IPv4+OLSRv1, IPv6+OLSRv1 und IPv6+OLSRv2. Sie ist für erfahrene Nutzer gedacht, die alle Dual-Stack+Dual-Protokoll aus Kompatibilitätsgründen einsetzen möchten.

Wer auf br-64a umstellen möchte und sicher ist, dass er mit Policy Routing oder IP-Spoofing und manipulierten OLSR-Metriken umgehen kann, darf mir ein E-Mail schreiben, damit ich seine OpenVPN-Konfiguration entsprechend anpasse.


#8

Der alte Tunnelserver wird zusehends abgebaut. Es sind noch fünf Tunnel aktiv, die am 30.06.2018 abgeschaltet werden. Der alte Tunnelserver 78.41.115.228 hat seit gerade eben auch keine OSPF-Connectivity mehr, sondern ist nur noch via VLAN10 und Mesh angebunden. Die Links zum Knoten „brenner“ wurden bereits vor einigen Wochen migriert, und auch der Map-Server ist nicht mehr über den “Tunnelserver alt“ angebunden.
Für Diejenigen, die noch Tunnel bei der alten VM benützen, wird das Routing jetzt ein oder zwei Hops mehr haben. Die Lösung heisst ehebaldigst zu migrieren! Am 30.06.2018 ist Schluss.

Außerdem hat der neue Tunnelserver jetzt eine IP-Adresse von alten Tunnelserver übernommen: 78.41.115.16/32. Diese wird langfristig der Tunnelendpunkt sein, da sie anders als 78.41.118.150 nicht dem Mesh-Range entstammt. Durch die IP aus dem Mesh in Verbindung mit einer statischen Route gab es bei Clients hinter einigen Tunnelclients nämlich kleinere Routingprobleme: sie konnten den Tunnelserver auf 78.41.118.150 wegen der statischen Route auf diesen logischerweise nicht erreichen, was für mich kein Problem dargestellt hat. Auf vielfachen Wunsch behebe ich es aber gerne.

Danke an Pocki für das Koordinieren, Dokumentieren und Debuggen!

Für alle jene, die das Problem mit der Nichterreichbarkeit von 78.41.118.150 hinter einem Tunnelknoten stört: Schreibt mir hier oder schickt mir eine PN, dann stelle ich Euren Tunnel hier auf „local 78.41.115.16“ um - ihr müsstet anschließend dasselbe tun: remote 78.41.115.16.


#9

Es sind jetzt nur noch drei Tunnel zu migrieren. Danke für Eure Mitarbeit!
Wenn zu den schon migrierten Tunneln Wünsche gibt, bitte lasst sie mich hören.