TigerVNC (ab 1.11.0)

Es gibt viele Wege, wie man aus der Ferne, oder wie es sich ja mittlerweile eingedeutscht hat, Remote auf einen Rechner zugreifen lässt.

Das Erste, was ich dabei benutze, ist SSH. Im Terminal geht es einfach super schnell, man kann die GUIs bei sich anzeigen lassen usw. Da gibt es nur den kleinen, unschönen Nebeneffekt, mittels ssh wird nicht komprimiert. Das heisst, wenn die Verbindung etwas langsam ist, ist es nicht schön damit zu arbeiten.

Es gibt aber auch noch andere Gründe, VNC (Virtual-Network-Computing) einzusetzen.

Gründe für VNC

Neben der Tatsache, dass die Meisten VNC-Umsetzungen mittels einer Komprimierung auch bei langsamen Verbindungen deutlich bessere Ergebnisse liefern als ssh, ist für mich ein bestimmtes Argument schlagend. Man kann auch auf schwachen Rechnern noch sehr gut arbeiten!

Als Beispiel. Sagen wir, man hat einen ordentlich schnellen Rechner auf, unter, oder wo auch immer stehen. Der hat Power und mit dem kann man gut arbeiten. Der Rechner vom Ehepartner hingegen ist in die Jahre gekommen. 4GB DDR2 Speicher, Singlecore, da funktioniert nicht mehr so viel.

Jetzt die Frage. Ein neuer Rechner kaufen? Da sind so um die 300€ futsch, würde ich mal sagen. Oder aber, man macht es clever!

In der Regel jammert der normale Benutzer eines PCs dann, wenn die Browser zu langsam werden. Ja, irgendwie scheint das die einzige Anwendung zu sein, die wirklich noch genutzt wird. Aber egal. Wenn ja sonst noch alles funktioniert, warum dem Partner dann nicht einen eigenen VNC auf dem eigenen Rechner einrichten? Auf dem kann er sich dann im Vollbildmodus einloggen und damit arbeiten, als wäre es die Kiste unter dem Tisch. Oder darauf, oder wo auch immer.

Oder eben auch, man ist mit einem Laptop, oder NetBook unterwegs und würde gerne arbeiten. Dann kann man das ganze Gerümpel dann auch auf dem tragbaren Gerät installieren, wobei natürlich die zu bearbeitenden Dateien aktuell sein müssen, oder man nutzt ebenfalls einen VNC. Hier ist tatsächlich VNC SSH vorzuziehen, da ich es bislang nur selten erlebt habe, dass ich unterwegs ausreichend schnelles Internet hatte, um mit einer getunnelten Anwendung arbeiten zu können.

Okay. Es gibt noch viele andere Gründe, aber die behandele ich hier jetzt nicht.

Der Server

Ich persönlich bevorzuge TigerVNC. Da kann man sicherlich drüber streiten, da ich den jedoch benutze, beschreibe ich jetzt auch seine Einrichtung. Wie man für die jeweilige Distribution TigerVNC installiert, müsst ihr aber selbst herausfinden. Wie immer, da es viele Unterschiede gibt und ich niemanden bevorzugen will, bleibt das euch überlassen. Aber ich gehe mal stark davon aus, ihr kriegt das hin.

Ist alles installiert, geht es um die Einrichtung. Da fange ich mal mit dem Passwort an.

vncpasswd

Man wird nach dem zu setzenden Passwort gefragt. Wie so oft im Terminal. werden keine Zeichen gedruckt, man muss also schon wissen, an welcher Stelle man ist. Dann wird das Passwort wiederholt und am Ende wird man gefragt, ob man ein “view-only” Passwort setzen möchte. Also eins, mit dem man dann nur zuschauen kann, was im VNC passiert. Ich beantworte das immer mit “n”, da es in meinen Augen keinen Sinn macht.

So. Weiter. Nun braucht man noch eine Konfiguration. Diese findet sich im Home-Verzeichnis im Unterverzeichnis .vnc/.

~/.vnc/config

oder

/home/benutzer/.vnc/config

Dort kann man mehrere Dinge einstellen. Ganz simpel reicht es aber schon, wenn man die zu startende Session angibt. Benutzen wir dafür doch einfach mal ganz banal FVWM. Grade so zum Spass. Das muss natürlich vorher installiert worden sein! Welche Window- oder Desktop-Manager verfügbar sind, sieht man im Verzeichnis “/usr/share/xsessions/”.

In die Datei kommt also:

session=fvwm

Was man nun noch tun muss, ist dem Display einen Benutzer zuordnen. Ich will also, dass mein Benutzer (diabolus) Display “:1” verwenden kann. Dafür wird die Datei “vncserver.users” editiert.

sudo nano /etc/tigervnc/vncserver.users

Die sieht am Anfang so aus:

 TigerVNC User assignment
#
# This file assigns users to specific VNC display numbers.
# The syntax is <display>=<username>. E.g.:
#
# :2=andrew
# :3=lisa

Da muss jetzt also “:1=diabolus” rein.

 TigerVNC User assignment
#
# This file assigns users to specific VNC display numbers.
# The syntax is <display>=<username>. E.g.:
#
# :2=andrew
# :3=lisa

:1=diabolus

Das finde ich persönlich nicht wirklich elegant. Aber gut, ist nun mal eben so.

Fertig. Jetzt schaut man mal, ob es so schon klappt. Ich will einen neuen VNC auf dem Display “:1” haben.

sudo systemctl start vncserver@:1

Hat das nun geklappt? Kommt keine Fehlermeldung, dann sieht es danach aus. Man kann sich aber auch vergewissern:

sudo systemctl status vncserver@:1

● vncserver@:1.service - Remote desktop service (VNC)
     Loaded: loaded (/usr/lib/systemd/system/vncserver@.service; disabled; vend>
     Active: active (running) since Sat 2020-09-26 19:02:00 CEST; 2s ago
    Process: 1154 ExecStart=/usr/bin/vncsession-start :1 (code=exited, status=0>
   Main PID: 1160 (vncsession)
      Tasks: 1 (limit: 2350)
     Memory: 1.1M
     CGroup: /system.slice/system-vncserver.slice/vncserver@:1.service
             ‣ 1160 /usr/bin/vncsession diabolus :1

Sep 26 19:02:00 mini-horst systemd[1]: Starting Remote desktop service (VNC)...
Sep 26 19:02:00 mini-horst systemd[1]: Started Remote desktop service (VNC).

Yes, läuft!

Will man den VNC jetzt wieder stoppen, reicht einfach:

sudo systemctl stop vncserver@:1

Soll der Server aber jedes Mal beim booten gestartet werden, kommt folgendes zum Einsatz:

sudo systemctl enable vncserver@:1

Fertig mit dem Server!

Der Client

TigerVNC bringt bei der Installation freundlicherweise gleich beides mit. Server und Client. So ist es denkbar einfach, auf einen VNC zuzugreifen.

Um es zu testen, kann man es auch auf dem gleichen Rechner machen, auf dem auch der Server läuft. In diesem Fall lautet der Befehl dafür:

vncviewer :1

Erst wird man nach dem Passwort gefragt, dann erscheint der VNC.

Natürlich kann man auch ferne Rechner damit erreichen. Einfach eine IP, oder ein Alias vor das Display und fertig.

vncviewer xxx.xxx.xxx.xxx:1

Wobei die ganzen “x” natürlich durch die IP, oder das Alias ersetzt werden muss. IPs eines VPN funktionieren dabei natürlich auch!

Das war auch schon alles! Zumindest, um ganz simpel einen VNC zu starten und zu benutzen. Es gibt noch diverse Zusatzoptionen, aber um die kümmere ich mich ein anderes Mal!

Tinc auf Linux einrichten

Beitragsbild aus Wikipedia (Ludovic.ferre)

Ich fühle mich mal wieder gezwungen, ein VPN, also ein Virtuelles-Privates-Netzwerk einzurichten. Was das ist, erkläre ich gleich noch. Wobei eigentlich, die, die hier her gelangt sind, wissen es mit Sicherheit. Egal, eine kurze Erklärung kann ja nicht schaden.

Ich fühle mich deshalb genötigt, ein VPN aufzubauen, weil ich ein Linux in einer virtuellen Box laufen habe und mir nicht den Stress machen will, mit Brücken und was weiss ich zu arbeiten, nur um auf meine realen Rechner zugreifen zu können. Warum auch immer Android das einfach so kann, Linux, Windows und auch AROS finden keinen Weg zueinander.

Was ist ein VPN?

Eigentlich ist es ein Router, wie man ihn normalerweise ja auch für sein heimisches Netzwerk verwendet. Eine Stelle, über die sich Rechner miteinander verbinden können. Das heisst, die Rechner bekommen eine IP zugewiesen, über die sie sich miteinander verbinden können. Auch quer durch das Internet, hinter einen heimischen Router!

Als Beispiel, sagen wir man hat einen Desktop-PC zuhause und einen Laptop für unterwegs. Man sitzt irgendwo und denkt sich, eine Datei auf dem Desktop könnte man jetzt aber sowas von gut gebrauchen!

Wie war das noch? Der Desktop hat die IP 192.180.0.12. Also versucht man, diese IP zu erreichen und scheitert. Warum? Weil das die IP im eigenen Netzwerk ist und nicht im Internet. Dort hat das heimische Netzwerk vielleicht eine Adresse wie 80.76.21.12.

Gut, dann muss es ja mit dieser IP klappen, oder? Nö. Tut es nicht! Denn damit erreicht man quasi den heimischen Router und nicht den Desktop-PC. Man könnte den Router nun so konfigurieren, dass er Anfragen über einen bestimmten Port direkt an den Desktop schickt usw. Es geht aber eben auch mit einem VPN.

Hat man das korrekt eingerichtet, bekommt jeder Rechner eine eigene IP zugewiesen. Sagen wir der Desktop hat die Adresse 4.7.11.1 und der Laptop 4.7.11.2. Schon spielt es keine Rolle mehr, wo man ist. Ist das VPN aktiv, kann man IMMER mit diesen IPs den jeweiligen Rechner erreichen!

Das ist aber nur eine Fähigkeit von VPN, aber um die soll es hier jetzt gehen.

Warum Tinc?

Ich sehe es direkt vor mir, wie die Frage gestellt wird. Es gibt garantiert viele, die für ein VPN direkt an OpenVPN denken und genau das ist auch das Problem. OpenVPN ist quasi Mainstream!

Das macht es jedoch keines Wegs schlecht und ich will auch niemandem davon abraten, ganz sicher nicht! Ich habe sogar selbst ein VPN mit OpenVPN laufen und denke auch, ich werde auch dazu noch eine Hilfestellung wie diese hier schreiben. Aber derzeit ist es eben so, ich benutze Tinc. Das ist der ganze Grund!

Installation

Wie immer sage ich dazu nichts. Wieder aus dem einfachen Grund, es gibt so viele Distributionen von Linux, ich kann und will nicht jede einzelne davon berücksichtigen und denke auch, wer sich mit VPN befasst, der sollte auch von sich aus dazu in der Lage sein, Tinc zu installieren.

Der Server

Beitragsbild von Ludovic.ferre

Also quasi den ersten Rechner, auf dem man Tinc einrichtet. Soweit ich weiss kann Tinc auch ganz ohne einen Server auskommen, aber wie das gehen soll ist mir noch nicht ganz klar. Wenn ich es mal herausgefunden habe, werde ich dazu auch was schreiben. Solange benutze ich einen Server als Vermittlungsstelle für die Knoten.

In Tinc kann man netterweise Profile verwenden. Das tut man einfach, indem man in dem Ordner

/etc/tinc

ein neues Verzeichnis einfügt. Um dem Projekt hier Rechnung zu tragen nenne ich es einfach hinfrei.

So. Da kommt jetzt alles rein, was man zur Einrichtung so braucht. Angefangen mit der tinc.conf Datei.

Name = server
AddressFamily = ipv4
Device = /dev/net/tun

In der Tat, genau das reicht schon! Klar, damit bekommt man nur die rudimentärste Form zustande, aber das reicht mir im Moment absolut aus.

Dann kommt als nächstes die Datei tinc-up.

#!/bin/sh
ip link set $INTERFACE up
ip addr add  4.7.11.1/32 dev $INTERFACE
ip route add 4.7.11.0/24 dev $INTERFACE

Das kann man einfach so kopieren. Wichtig ist nur die “4.7.11.1/32”. Damit legt man fest, unter welcher IP der Server im VPN erreichbar sein wird. Für die Route nimmt man einfach die IP und lässt diese mit 0 enden. Bei der IP kann man natürlich auch gängigere Dinge nehmen, beispielsweise “192.168.1.1”, oder so. Das ist dem eigenen Geschmack überlassen. Für dieses Beispiel nehme ich eben 4.7.1.11.1.

Weiter zur Datei tinc-down.

#!/bin/sh
ip addr del 4.7.11.1/32 dev $INTERFACE
ip link set $INTERFACE down

Hier ist eigentlich auch nur wichtig, dass man die selbe IP verwendet, wie bei tinc-up.

Die beiden Dateien tinc-up und tinc-down müssen ausführbar sein. Deshalb noch schnell ein

sudo chmod 0755 tinc-*

und fertig. Da kriege ich jetzt bestimmt wieder Kritik, da man es doch nicht mit 0755 machen soll. Funktioniert aber!

Soweit wäre die Konfiguration dann abgeschlossen. Aber nützen tut sie nichts, denn man muss Tinc noch erklären, welche Geräte alle so in dem Netz herumhängen. Dafür wird erst das Verzeichnis hosts erstellt. Da kommen die ganzen Geräte dann rein.

Da rein kommt jetzt der Server selbst. Ja, den muss man da auch einbauen. Also einfach eine Datei mit dem bezeichnenden Namen server erstellen und das einfügen:

Address = xxx.xxx.xxx.xxx
Port = 655
Subnet = 4.7.11.1/32

Anstelle der xxx.xxx.xxx.xxx muss man natürlich die echte IP des Servers angeben.

Prima. Damit ist der Server soweit fertig konfiguriert. Aber, er soll ja auch noch verschlüsseln! Dafür brauchen wir auch Schlüssel! Einen öffentlichen und einen privaten. Die generiert man so:

sudo tincd -n hirnfrei -K4096

anstelle von hirnfrei muss man natürlich den Namen angeben, den man für das Profil verwendet hat.

Die Schlüssel werden erstellt und man wird gefragt, wo man sie gerne hätte. Das kann man bedenkenlos durchwinkeln, also einfach Enter drücken.

Damit ist die Konfiguration des Servers abgeschlossen.

Ein Knoten

Ja, EIN Knoten. Denn auf genau die Art, wie dieser Knoten eingerichtet wird, werden auch alles anderen eingerichtet!

Hier muss zunächst wieder in das Verzeichnis /etc/tinc/ das Verzeichnis hirnfrei angelegt werden. Man könnte da auch einen anderen Namen wählen, oder auf ein Profil verzichten, es macht aber durchaus Sinn, diese zu nutzen und die Profile gleich zu benennen.

Ist das erledigt, kommt wieder die Datei tinc.conf

Name = knoten1
AddressFamily = ipv4
Device = /dev/net/tun
ConnectTo = server

Wie beim Server. Jedoch ist hier eine neue Zeile: “ConnectTo = server”. Die besagt nichts anderes, als wohin der Knoten sich verbinden soll. Dabei bezieht sich der Name auf die entsprechende Datei in hosts/.

Natürlich geht es dann weiter mit tinc-up und tinc-down in dieser Reihenfolge!

#!/bin/sh
ip link set $INTERFACE up
ip addr add  4.7.11.2/32 dev $INTERFACE
ip route add 4.7.11.0/24 dev $INTERFACE
#!/bin/sh
ip addr del 4.7.11.2/32 dev $INTERFACE
ip link set $INTERFACE down

Da ist aber jetzt was anders! Die IP ist natürlich die IP, die der Knoten im VPN haben soll. 4.7.11.1 ist ja schon vom Server belegt, also bekommt der erste Knoten die Adresse 4.7.11.2. Der nächste Knoten würde die 4.7.11.3 bekommen usw.

Jetzt muss wieder das Verzeichnis /hosts erstellt werden und da muss nun die Datei knoten1 rein.

Subnet = 4.7.11.2/32

Kaum zu glauben, aber mehr braucht man da nicht! Die IP muss natürlich die Gleiche sein, wie auch in tinc-up!

Dann muss wieder ein Schlüsselpaar erstellt werden. Das ist genau das Gleiche wie beim Server!

sudo tincd -n hirnfrei -K4096

Damit wäre die Konfiguration von knoten1 abgeschlossen!

Bekannt machen

Würde man nun so versuchen, Tinc zu starten, würde man nicht weit kommen! Vielleicht startet Tinc sogar, aber da ist nichts mit einem VPN!

Das hat auch seinen Grund. Server und knoten sind zwar konfiguriert, die kennen sich aber noch nicht! Denn, auf allen Rechnern, die mit Tinc verbunden werden sollen, müssen ALLE dazugehörogen Knoten im Verzeichnis hosts/ vorhanden sein!

Warum das so ist, sieht man in meinen Augen dann am eindrucksvollsten, wenn man sich mal in hosts/ zum Beispiel die Datei server anschaut!

Address = xxx.xxx.xxx.xxx
Port = 655
Subnet = 4.7.11.1/32

-----BEGIN RSA PUBLIC KEY-----
.
.
.
-----END RSA PUBLIC KEY-----

Krass, oder? Als die Schlüssel generiert wurden, wurde der private Schlüsse ins Verzeichnis des Profils gespeichert und der Öffentliche direkt in die Datei des Servers! Aus diesem Grund müssen auch alle Rechner die gleichen Dateien in hosts/ haben, um die entsprechenden öffentlichen Schlüssel und IPs zu kennen! Logisch, oder?

Also. Die Dateien müssen nun kopiert werden. Nur wie?

Ich weiss jetzt nicht, ob das ein kluger Weg ist, oder ob man auf diese Weise Risiken eingeht. Echt, ich habe keine Ahnung. Aber, ich für meinen Teil habe einen Weg für mich gefunden, der super einfach ist!

Dazu sei gesagt, ich konfiguriere meine Rechner immer im heimischen Netzwerk mittels ssh. Hat was mit Bequemlichkeit zu tun. Sprich, ich habe in dem einen Terminal den einen Rechner, in dem anderen ein anderer Rechner. Öffne ich nun zum Beispiel mit Nano auf dem Server die Datei server, kann ich einfach den Inhalt markieren, kopieren und auf knoten1 einfügen.

Natürlich geht das auch über ssh, sshfs, ftp, mittels einem USB-Stick, man könnte es auch von Hand abtippen. Es gibt viele Wege, ich nutze den.

Ist nun die Datei server auf knoten1 und die Datei knoten1 auf dem Server, ist die Geschichte abgeschlossen!

Starten

Jetzt kann man einfach mal sein Glück versuchen und folgendes auf dem Server eintippen:

sudo systemctl start tinc@hirnfrei

ACHTUNG: Auf verschiedenen Distributionen scheint es da verschiedene Schreibweisen zu geben! So kann es auch durchaus sein, dass man folgendes eingeben muss:

sudo systemctl start tincd@hirnfrei

Also tincd und nicht tinc. Ich weiss jetzt aber nicht, wo es wie ist. Muss man ausprobieren!

Wenn keine Fehlermeldung kommt, kann man ja mal nachschauen:

ip addr

24: hirnfrei: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 4.7.11.1/32 scope global hirnfrei
       valid_lft forever preferred_lft forever
    inet6 fe80::16f2:d108:a777:5736/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Tada! Läuft. Jetzt auf knoten1 das selbe Spiel. Also einfach noch einmal von oben nach unten und dann sagt ip addr folgendes auf knoten1:

7: hirnfrei: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 4.7.11.2/32 scope global hirnfrei
       valid_lft forever preferred_lft forever
    inet6 fe80::ec5:c9c5:da94:1008/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Jetzt kann man mal schauen, ob man den Server anpingen kann. Hat alles geklappt, sollte das ja kein Problem sein.

ping 4.7.11.1

PING 4.7.11.1 (4.7.11.1) 56(84) bytes of data.
64 Bytes von 4.7.11.1: icmp_seq=1 ttl=64 Zeit=36.9 ms
64 Bytes von 4.7.11.1: icmp_seq=2 ttl=64 Zeit=36.4 ms
64 Bytes von 4.7.11.1: icmp_seq=3 ttl=64 Zeit=36.6 ms
64 Bytes von 4.7.11.1: icmp_seq=4 ttl=64 Zeit=35.7 ms
64 Bytes von 4.7.11.1: icmp_seq=5 ttl=64 Zeit=36.1 ms
64 Bytes von 4.7.11.1: icmp_seq=6 ttl=64 Zeit=36.2 ms

Ich doch prima! Der Server lässt sich über die vorgegebene IP anpingen. Es hat also alles funktioniert!

Will man jetzt bei jedem Start das VPN automatisch mitstarten, muss man folgendes eingeben:

sudo systemctl enable tinc
sudo systemctl enable tinc@hirnfrei

Ja, man muss wirklich auch tinc auf diese Weise beim booten aktivieren! Nun sollte das VPN bei jedem Start automatisch mitgestartet werden und von nun an hat man auch, egal wo man ist, immer direkten und verschlüsselten Zugriff auf seine Rechner!