Adventskalender 2. Dezember 2022 - Mein Netzwerk, überall, voll einfach

[TRex]

tinc!

Was ist tinc? Schonmal zu faul gewesen, sich openvpn anzuschauen? Eigentlich nur ne Verbindung zwischen zwei Hosts gebraucht und die restliche Topologie war eher zweitrangig? Wenig Ansprüche an Verbindungsgeschwindigkeit?

tinc ist ein Mesh-Netzwerk, d.h. jeder verbindet sich mit irgendeinem anderen (definierten) Knoten. Oder mehreren. Und dann kann man über diese Knoten navigieren, ohne die exakte Verbindung zu kennen. Braucht man zugegeben nicht oft, aber so kann ich quasi eine Art "Roaming" implementieren, bei der mein Notebook mal über die NAS verbunden ist und mal über den VPS. In beiden Fällen bin ich transparent "zuhause", ohne jedoch notwendigerweise immer über die Internetleitung gehen zu müssen.

Das alleine wäre mir nicht wichtig, aber die Konfiguration ist so schön leichtgewichtig.
Über alle Hosts hinweg sollte man die public keys austauschen - optimalerweise in jeweils einer Datei zusammen mit den restlichen Daten zum Host - Adresse (mit welcher der Host angesprochen werden soll), Subnet und bei Bedarf weiteren Parametern. Dazu eine tinc.conf mit den Anweisungen, wo es hingehen soll (ConnectTo, gerne mehrfach) und ein paar wenigen weiteren Zeilen. Optional kann man Scripte als Hooks hinterlegen, die zb bei eingehendem Verbindungsaufbau ausgeführt werden. So krieg ich ne Mail, wenn meine NAS sich an-/abmeldet. Oder Hosts, die nicht "bekannt" sind (neue Pi, neue IP - erspart mir die Suche).

Ich hab das dann irgendwann in eine ansible-Rolle gegossen, die das Paket installiert und die Hostfiles verteilt. Kürzlich hab ich dann ein paar meiner Satelliten (=Support beziehende Rechner) ausgesperrt, weil ich den VPS gewechselt hab. Hätte ich _vorher_ daran gedacht, da einfach noch den zweiten VPS als weiteren ConnectTo einzutragen, wäre nichts passiert. Naja, komme an Weihnachten eh dran vorbei.

Einzig nervig ist die Neukonfiguration, wenn man zb. das Notebook und nen Pi irgendwo mobil hat - klar kann man über den zentralen Knoten gehen, aber entweder man etabliert Standards und eine feste IP-Range für mobile Netze oder man frickelt ständig weitere ConnectTo-Anweisungen in seine Konfigurationen. Auch ist der noise vermutlich etwas höher als mit openvpn (je nach Konfiguration, nehme ich an). Aber das ist bei meinen Szenarien nicht so wild.


Ich hoffe mal, dass das Thema von paedubucher nicht genau das gleiche ist - so sicher weiß man das ja nie

[schorsch_76]

Wie ist das? Geht der Verkehr dann immer über einen zentralen Knoten oder auch von Host zu Host? Ist das so ähnlich wie wireguard?

https://wiki.debian.org/WireGuard

Code: Alles auswählen

[Interface]
Address = 192.168.11.1/24
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = YOUR_SERVER_PRIVATE KEY

[Peer]
PublicKey = YOUR_CLIENT_PUBLIC_KEY
AllowedIPs = 192.168.11.2/32

[Peer]
PublicKey = OTHER_CLIENT_PUBLIC_KEY
AllowedIPs = ...

[Meillo]

@TRex: Kannst du noch etwas genauer erklaeren, wie das technisch geht. Ich bin kein Netzwerkspezialist und manche anderen sicher auch nicht. (Fuer diejenigen, die sich auskennen, ist dein Beitrag bestimmt auch so schon hilfreich.)

Also das tinc Paket enthaelt einen Daemon, den ich konfiguriere (ConnectTo) und starte. Auf dem entfernten Rechner genau so. Wie verbinde ich mich dann aber dorthin? Worin liegt der Unterschied, ob ich mich direkt per SSH auf den anderen Rechner einwaehle oder das ueber tinc mache? Vielleicht kannst du uns noch einen kleinen Crashkurs zur Netzwerktechnik geben.

[mn77de]

Mittlerweile bin ich raus aus dem Geschäft, habe früher allerdings auch einige Kunden und verschiedene Server betreut. Bei mir lief alles über eine 1:1 Client-Server OpenVPN-Verbindung. Wenn man sich in OpenVPN einmal eingearbeitet hat ist es wirklich nicht schwer. Für einen neuen Kunden-Server dann einfach Schlüssel erzeugen, config kopieren, kurz anpassen ... fertig.
Vorteil, die Verbindung wird direkt und z.B. nur bei Bedarf aufgebaut. Zudem können sich die Kunden natürlich nicht untereinander im Netz finden.

Ich glaub, tinc dürfte sich gut dafür eignen, um relativ schnell ein virtuelles Netzwerk mit Freunden oder der Familie aufzubauen.

[TRex]

tinc arbeitet auf Netzwerkebene, ich verbinde mich also nicht "via tinc oder via SSH", sondern allenfalls direkt zu einer lokalen IP via SSH oder über einen Umweg über das tinc-Netzwerk (via SSH). Ich habe einen weiteren Netzwerkadapter (wie bei anderen VPN-Lösungen auf Layer 3 tun0) und ein Subnet dafür.

Ich bin zu faul für was anständiges, weswegen ihr jetzt damit leben müsst:



Jeder blaue Pfeil steht für eine ConnectTo-Angabe in der jeweiligen tinc-Konfiguration. Jeder dieser Hosts ist ein tinc-Client (man könnte natürlich auch einen designierten Router als Tinc-Client hinstellen, DHCP, Routing usw, aber das schreit für mich dann nach nem anderen Anwendungszweck).

PC 1 springt zwischen den Netzwerken, ist aber an den jeweiligen Standorten lokal mit den anderen PCs vernetzt. In einem klassischen VPN-Szenario wäre PC 3 der (Open)VPN-Server und fällt er aus, funktioniert zwischen den Standorten nichts mehr (und auch die VPN-IPs sind untereinander nicht mehr erreichbar). Bei tinc ist das nicht unbedingt so. PC 1 verbindet sich zu PC 2 und zu PC 3, und ist er an Standort B, erreicht er PC 2 nicht direkt, aber über die Verbindung zu PC 3. Auch erreicht PC 4 PC 2 über die Verbindung zu PC 3. Ohne das jetzt ausprobiert zu haben - ich denke, dass tinc schlau genug ist, nicht über PC 1 zu routen, wenn der auch gerade da ist.

Edit: man könnte sich auch noch einen weiteren PC 6 irgendwo anders vorstellen, der zwischen den Netzen Redundanz für PC 3 herstellt.

Was ist jetzt besser als OpenVPN hier? Ich kann PC 2 mit der gleichen IP-Adresse ansprechen, egal wo ich bin und auch, wenn das Netzwerk am Standort gerade unter einem unzuverlässigen ISP leidet.

[Meillo]

Ich will in meinen Worten nochmal wiederholen wie ich das mit dem Tunneln und VPN verstanden habe: Der tinc Daemon legt ein zuaetzliches Netzwerkinterface und ein Subnetz an IP-Adressen an. Die ihm bekannten tinc-Maschinen sind in dem Subnetz mit (lokalen) IP-Adressen hinterlegt. Wenn ich also den entfernten Server ansprechen will, dann mache ich das nicht ueber dessen oeffentliche IP-Adresse, die normal ueber das Internet geroutet werden wuerde, sondern ueber seine tinc-IP-Adresse, die dann ueber das tinc-Interface und von tinc getunnelt zum Ziel geroutet wird.

Damit laeuft aller Datentransfer, bei dem ich die lokale tinc-Adresse des entfernten Servers verwende, an tinc, das es verschluesselt zum Ziel bringt. Folglich kann ich auch Klartextprotokolle verwenden, weil der Tunnel verschluesselt ist.

Der Vorteil gegenueber einem SSH-Tunnel ist, dass die Programme nichts davon mitbekommen, weil ich nur eine andere IP-Adresse verwende, sonst aber nichts tun muss.


Ist es denn ueblich, dass die Maschinen ringfoermig vernetzt sind oder ist das nur zufaellig bei dir so? Koennte man die auch alle mit allen vernetzen oder sternfoermig?

Verstanden habe ich, dass sich tinc gut eignet, wenn man sowas mal schnell ad hoc aufbauen will, weil man nur jeweils einen tinc-Daemon installieren und die IP-Adresse des anderen Rechners eintragen muss, dann hat man den Tunnel schon.

[paedubucher]

Interessantes Werkzeug, dass ich gerne einmal im Freundeskreis ausprobieren werde! Im Moment fehlt mir dafür aber etwas das Netzwerk.

Mein Thema wird nicht genau das gleiche sein.

Aber dieses Thema erinnert mich daran, dass ich mich wieder einmal etwas tiefer als mit Layer 7 beschäftigen sollte

[TRex]

Ich will in meinen Worten nochmal wiederholen wie ich das mit dem Tunneln und VPN verstanden habe

Jupp, das trifft so zu Die Frage nach der Topologie lässt sich klar mit https://de.wikipedia.org/wiki/Vermaschtes_Netz beantworten.

Zu ad-hoc: ja, das stimmt ebenfalls - man muss aber die Schlüssel untereinander austauschen. Irgendeine Form des Datentransfers braucht man also vorab.

Mein Thema wird nicht genau das gleiche sein.

Puh, nochmal Glück gehabt

[Meillo]

Ich will in meinen Worten nochmal wiederholen wie ich das mit dem Tunneln und VPN verstanden habe

Jupp, das trifft so zu Die Frage nach der Topologie lässt sich klar mit https://de.wikipedia.org/wiki/Vermaschtes_Netz beantworten.

Zu ad-hoc: ja, das stimmt ebenfalls - man muss aber die Schlüssel untereinander austauschen. Irgendeine Form des Datentransfers braucht man also vorab.

Danke, ich habe einiges gelernt und besser verstanden.

[wanne]

Also lasst es mich mal so beschreiben für Leute, die vor allem OpenVPN oder Anyconnect kennen:

• Es ist einfacher zu konfigurieren, da die die Konfigurationsfilets einen Bruchteil der Länge haben.
  Die Konfiguration ist einfacher zu lernen weil man großteils einfach die normalen ip/ifconfig-Befehle die man von jeder anderen Netzwerkkonfiguration kennt verwenden kann.
• Es ist meist deutlich flotter, das nicht der gesamte Traffic über einen Server läuft sondern immer den direktesten Weg nimmt und allenfalls einmalig beim aufbauen zur Frirewallumgehung (damit es keine eingehenden Verbindungen gibt) umgeleitet wird.
• Da jeder Client seine eigene Konfiguration haben kann, ist es weit weniger invasiv und flexibler. Es gibt keinen Server der dir dein(e) internen Netzwerke kaputt schießen kann.