Nun wurde von Stefan Deil gefragt, ob es einen Workaround gibt. Zwei Varianten möchte ich hier kurz vorstellen:

1. Proxy-Server

Die Sperre von Userfriendly geschieht auf Basis der IP-Adresse. Anfragen, die nicht aus dem Arcor-Netz kommen, werden ohne Probleme beantwortet. Die einfachste Möglichkeit ist daher, die Anfrage über einen Proxy zu senden, der diese dann an Userfriendly weiterleitet und die Antwort wiederum an den Browser durchreicht. Dieser Proxy muss in den Optionen des verwendeten Browsers eingetragen werden.

In einem Beitrag im Heiseforum wird z.B. ein Proxy der Piratenpartei vorgeschlagen (porn.piratenpartei.de:3128). Angeblich funktioniert selbst der Arcor-eigene Proxy (proxy.arcor-ip.de:8080), was ich aber nicht getestet habe.

Der Nachteil an diesem Ansatz ist, dass der gesamte »Surf-Traffic« nun über einen fremden Rechner geleitet wird, was man aus Gründen der Sicherheit, der eigenen Privatsphäre und/oder der Übertragungsrate nicht unbedingt möchte. Daher möchte ich noch eine zweite Möglichkeit aufzeigen.

2. ssh-Tunnel

Voraussetzung hier ist ein ssh-Zugang auf einen anderen Rechner oder Server, der außerhalb des Adressbereichs von Arcor liegt. ssh ermöglicht es, einen »Tunnel« aufzubauen und einen Port des eigenen Rechners mit diesem zu verbinden. Das Ganze hört sich komplizierter an als es ist. Unter Unix realisiert man den Tunnel mit diesem Befehl:

ssh -L 80:www.userfriendly.org:80 USER@SOME_HOST

Port 80 des eigenen (lokalen) Computers wird an den ssh-Tunnel gebunden, dessen anderes Ende mit Port 80 von www.userfriendly.org verbunden wird. Da es sich dabei um einen so genannten priviligierten Port handelt, benötigt dieser Befehl root-Rechte. USER ist natürlich durch die entsprechende Nutzerkennung zu ersetzen, mit der man sich auf dem entfernten Rechner SOME_HOST anmelden kann. Für Windows-User existiert der ssh-Client PuTTY, der das gleiche leisten sollte, mit dem ich mich aber nicht auskenne — wenn jemand mehr weiß, würde ich mich über einen entsprechenden Kommentar freuen.

Nun muss man noch dafür sorgen, dass Anfragen für Userfriendly auch an localhost und damit über den Tunnel gesendet werden. Das erreicht man am einfachsten mit folgender Zeile in der Datei /etc/hosts (unter Windows heißt die Datei auch »hosts«, ich weiß aber nicht wo sie liegt):

127.0.0.1 www.userfriendly.org

Diese sorgt dafür, dass die Adresse www.userfriendly.org auf die lokale IP des eigenen Rechners aufglöst wird. Jetzt genügt es, eben diese Adresse im Browser der Wahl aufzurufen. Eine Einschränkung gibt es aber leider dennoch: userfriendly ist über die Hosts »www« und »ars« verteilt. Da wir nur einen von beiden umleiten können, ist die Navigation auf der Seite nur eingeschränkt möglich. Prinzipiell kann man auch das in den Griff kriegen, es wird dann nur ein wenig aufwändiger.

Die zweite Variante hat den Vorteil, dass wirlich nur der Traffic von und zu Userfriendly umgeleitet wird; alle anderen Verbindungen bleiben unverändert.

PS. Dilbert und xkcd existieren auch noch… ;-)

Das GNOME-Environment bringt zwar schon eine entsprechende Funktion mit, die den eigenen Desktop für einen Zugriff von außen freigibt, diese basiert aber leider auf »reinem« VNC, d.h. die Daten der Verbindung werden unverschlüsselt übertragen. In einem LAN mag das gehen, für die Übertragung im Internet habe ich nach einer verschlüsselten Variante gesucht.

Letztlich habe ich mich dafür entschieden, eine VNC-Verbindung über ssh zu tunneln. NX habe ich mir zwar auch angesehen, der Client unterstützt aber leider keine Pubkey-Authentifizierung und war auch sonst in der Bedienung eher umständlich. Das System auf beiden Seiten ist jeweils Debian GNU/Linux »Etch« und so geht es:

1. ddclient

Zunächst muss dafür gesorgt werden, dass man den zu betreuenden Rechner auch erreichen kann. Sofern dieser keine statische IP-Adresse hat, muss man auf Dienste wie z.B. DynDNS oder easyDNS ausweichen.

Ist der betreffende Rechner direkt mit dem Internet (ohne Router) verbunden, gibt es hier keine Hürden:

# aptitude install ddclient

installiert ddclient, das sich mit einer ganzen Reihe von Diensten verwenden lässt. Debconf fragt direkt nach allen relevanten Konfigurationsparametern, die man später wie gewohnt durch den Aufruf von dpkg-reconfigure ddclient noch ändern kann. ddclient meldet dann die aktuelle IP-Adresse an den jeweiligen Dienst, sobald eine Internetverbindung hergestellt wird.

Ein wenig komplizierter wird es, wenn ein Router ins Spiel kommt. In diesem Fall muss sich nämlich dieser um das Update beim DNS-Dienst kümmern — ob der jeweilige Router dies kann, ist der entsprechenden Dokumentation zu entnehmen. Darüber hinaus muss noch ein Port Forwarding eingerichtet werden, d.h. alle Verbindungen auf einen Port am Router werden zu einem Port eines der angeschlossenen Rechner weitergeleitet. Auch hierfür sei auf die Dokumentation des Herstellers verwiesen.

2. ssh

Sofern noch nicht vorhanden, muss auf dem Zielrechner ein ssh-Server installiert werden:

# aptitude install openssh-server

Aus Sicherheitsgründen sollte auf jeden Fall der Login für root gesperrt und auch Passwort-Logins deaktiviert werden. Diese Zeilen müssen dafür in /etc/ssh/sshd_config stehen:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

Als nächstes ist ein Schlüsselpaar zu erzeugen und dessen öffenlicher Teil den autorisierten Schlüsseln des zu betreuenden Benutzerkontos hinzuzufügen:

$ ssh-keygen -t dsa -f /path/to/id_file
# cat /path/to/id_file >> /home/username/.ssh/authorized_keys

Den geheimen Teil des Schlüssels sollte man auf keinen Fall auf dem PC des Anwenders zurücklassen! Die Gefahr, dass der Schlüssel und damit der Zugang zu dem Rechner in Hände gerät, in die er nicht gehört, ist groß. Am besten erzeugt man sich ein entsprechendes »Support«-Schlüsselpaar zu Hause und nimmt es auf einem USB-Stick mit.

3. VNC

Als letztes muss noch der VNC-Server installiert werden:

# aptitude install x11vnc

Als letztes muss noch ein Passwort für diesen vergeben werden. Dazu füht man im Kontext des zu betreuenden Nutzers folgenden Befehl aus:

$ x11vnc -storepasswd ~/.vnc/passwd

Das Passwort ist wichtig, da sonst ein Zugriff auf den VNC-Server durch andere Benutzer, die auf dem gleichen PC angemeldet sind, möglich wäre.

Damit ist die Konfiguration abgeschlossen und man kann sich mit dem Rechner verbinden.

4. Eine Verbindung aufbauen

Wir befinden uns jetzt wieder am eigenen PC und möchten den Desktop unseres Nutzers auf unseren Monitor holen. Dazu wird zunächst der VNC-Server auf dem entfernten Rechner gestartet und dessen Port (5900) auf (den eigenen) localhost umgeleitet:

$ ssh -C -i /path/to/id_file -L 5900:localhost:5900 USER@HOST "x11vnc -localhost -display :0 -rfbauth ~/.vnc/passwd"

Zur Erklärung:

• -C komprimiert die übertragenen Daten
• /path/to/id_file muss ersetzt werden durch den Pfad zum privatekey
• -L 5900:localhost:5900 leitet Port 5900 des entfernten Rechners auf Port 5900 von localhost um
• USER und HOST sind durch den Benutzernamen und den (dynamischen) Hostnamen zu ersetzen
• Der Rest der Zeile ist das Kommando, das auf dem entfernten Rechner ausgeführt werden soll: starten des VNC-Servers und Bereitstellung des Displays :0 auf localhost

Das Ergebnis sollte eine Meldung sein, dass der VNC-Server erfolgreich gestartet wurde und auf Verbindungen wartet.

Nun kann man sich mit einem VNC-Client der Wahl (z.B. vncviewer) am Server anmelden:

$ vncviewer localhost

Nach Eingabe des Passwortes ist man nun mit dem Desktop des entfernten PCs verbunden.

Noch ein Hinweis

Ich möchte ausdrücklich darauf hinweisen, dass selbstverständlich das Einverständnis des jeweiligen Benutzers vorliegen muss, bevor man sich mit dessen Computer verbindet!

Diese Liste soll weder die Info-Seiten des URZ ersetzen, noch erhebt sie einen Anspruch auf Vollständigkeit. Es ist lediglich eine Zusammenstellung von Tipps, die sich für mich als nützlich erwiesen haben. Ergänzungen sind jederzeit willkommen.

Alle Zugänge setzen selbstverständlich einen Account im Rechenzentrum voraus. Von diesem hängt auch ab, welche Dienste du in der Uni nutzen kannst.

Fileserver

Für Studenten von Network Computing stehen zwei Fileserver für eigene Daten zur Verfügung:

1. f100.mathe.tu-freiberg.de

   Hier finden sich neben dem obligatorischen ‘Eigene Dateien’ noch ein Verzeichnis ‘public_html’, das über http://www.informatik.tu-freiberg.de/~username erreichbar ist. Außerdem liegen hier noch Vorlesungs- und Übungsunterlagen der IfI-Lehrveranstaltungen.

2. znlserv.hrz.tu-freiberg.de

   Hier liegt das eMail-Verzeichnis, das per POP3, IMAP oder Web-Interface abgerufen werden kann.

ssh

Am bequemsten ist der Zugang zum privaten Verzeichnis auf dem zentralen Fileserver znlserv. Auf dieses kann man nämlich einfach per ssh mit

ssh username@sshproxy.hrz.tu-freiberg.de

zugreifen. (Siehe auch die entsprechende Anleitung des URZ zu ssh)

Der Datenaustausch klappt dementsprechend einfach mit scp oder auch sftp entweder in der Shell

sftp username@sshproxy.hrz.tu-freiberg.de

oder natürlich auch mit einem graphischen Client der Wahl (gFTP, o.ä.)

Der Zugriff auf die smb-Freigaben des Uni-Netzes (z.B. des Instituts für Informatik) klappt dagegen nur über eine VPN-Verbindung.

VPN

Zum Aufbau einer VPN-Verbindung zum Uni-Netz empfiehlt es sich, entgegen der Beschreibung des URZ, statt des Cisco eigenen Clients vpnc zu verwenden, da man sich so das Kompilieren von Kernelmodulen sparen kann.

Um vpnc verwenden zu können, wird die Konfigurationsdatei /etc/vpnc/default.conf mit folgendem Inhalt angelegt:

IPSec gateway 139.20.201.100
IPSec ID world
IPSec secret world
Xauth username DEIN_USERNAME
Xauth password DEIN_PASSWORT

# If Target networks is defined here, the default route is not replaced!
Target networks 139.20.0.0/16

# Don't update resolv.conf though resolvconf is installed
DNSUpdate no

Da diese Datei das Uni-Passwort im Klartext enthält, sollte man die Rechte mit

chmod go-rw /etc/vpnc/default.conf

setzen. Um dann das VPN ohne root-Rechte starten zu können, benutzt man das Tool sudo, das ggf. noch zu installieren ist.

Mit visudo werden die Befehle vpnc-connect und vpnc-disconnect in /etc/sudoers eingetragen:

Host_Alias  LOCAL = localhost, 127.0.0.1
User_Alias  STUDENT = LOKALER_BENUTZERNAME
Cmnd_Alias  VPNCONN = /usr/sbin/vpnc-*connect
STUDENT     LOCAL = NOPASSWD: VPNCONN

Dabei ist LOKALER_BENUTZERNAME der lokale Benutzer, der die Verbindung aufbauen darf.

Anschließend kann die Verbindung mit

sudo vpnc-connect

gestartet werden.

Man kann auf das hinterlegen des Passwortes auch verzichten und Xauth interactive anstelle von Xauth password ... verwenden. Dann fragt vpnc beim Aufbau der Verbindung nach dem Passwort.

WLAN

Der Zugang ins WLAN funktioniert im Wesentlichen wie der externe Zugang über VPN. Für die eigentliche Funkverbindung reicht es, als essid tubafun zu verwenden und eine IP-Adresse per DHCP zu beziehen. WEP- u.a. Verschlüsselungen sind abzuschalten – das VPN sorgt für die nötige Sicherheit.

Der Unterschied liegt allein in der Konfigurationsdatei für vpnc. Sollen auf einem Rechner beide Möglichkeiten genutzt werden können, bietet es sich an, eine zweite Konfigurationsdatei zu erstellen.

Inhalt von /etc/vpnc/wlan.conf:

IPSec gateway 172.17.1.100
IPSec ID wlan
IPSec secret wlan
Xauth username DEIN_USERNAME
Xauth password DEIN_PASSWORT

Der Zugang kann jetzt mit

sudo vpnc-connect wlan

gestartet werden.

Windows-Freigaben (smb)

Sobald das VPN einmal steht, kann man bequem die verfügbaren Freigaben mounten. Dazu erstellt man sich die passenden Mountpunkte (z.B. /mnt/f100/lehre usw.) und testet das ganze zunächst am besten auf der Konsole:

# mount -t smbfs -o username=DEIN_USERNAME,password=DEIN_PASSWORT //f100.mathe.tu-freiberg.de/lehre /mnt/f100/lehre

Hat das geklappt, kann man sich das Leben etwas vereinfachen, und entsprechende Einträge in der /etc/fstab vornehmen, damit man den ganzen Sermon nicht jedesmal neu eintippen muss.

Dabei empfiehlt es sich, den Benutzernamen und das Passwort in einer separaten Datei abzulegen, auf die nur root zugriff hat. Der Pfad und der Name der Datei sind dabei beliebig, der Username oder das Passwort dürfen allerdings nicht mit einem Leerzeichen beginnen.

Inhalt von /etc/tubaf.cred:

username = DEIN_USERNAME
password = DEIN_PASSWORT

Diese Datei kann man jetzt mit dem Parameter credentials an smbmount übergeben. Die Parameter uid und gid legen den Benutzer und die Gruppe fest, dem die eingebunde Freigabe gehört. fmask und dmask schließlich setzen noch die Rechtemaske für Dateien und Verzeichnisse.

Auszug aus /etc/fstab:

//f100.mathe.tu-freiberg.de/username /mnt/f100/home smbfs noauto,credentials=/etc/tubaf.cred,uid=1000,gid=1000,fmask=640,dmask=750 0 0

//f100.mathe.tu-freiberg.de/lehre /mnt/f100/lehre  smbfs noauto,credentials=/etc/tubaf.cred,uid=1000,gid=1000,fmask=444,dmask=555 0 0

//znlserv.hrz.tu-freiberg.de/username /mnt/znlserv smbfs noauto,credentials=/etc/tubaf.cred,uid=1000,gid=1000,fmask=640,dmask=750 0 0

Leider funktioniert das Mounten dieser Verzeichnisse nur mit root-Rechten. (Falls jemand etwas anderes weiß: Bitte mailen!) Also kommt auch hier wieder sudo zum Zuge. Dazu ergänzt man mit visudo die Zeilen

Cmnd_Alias UNI_SRV = /bin/*mount /mnt/f100/*, /bin/*mount /mnt/znlserv/
STUDENT    LOCAL = NOPASSWD: UNI_SRV

Die Mountpunkte sind natürlich ggf. anzupassen. Der Asterisk (’*') als Wildcard sorgt dafür, dass sowohl /bin/mount als auch /bin/umount zugelassen werden.

Wenn alles zur Zufriedenheit läuft, spricht nichts dagegen, alles zusammen mit dem Aufbau des VPNs in ein Script zu schreiben und nach Belieben auf ein Icon o.ä. zu legen:

#!/bin/sh
#
# uniconnect.sh
# Connect to vpn and mount server shares

sudo vpnc-connect && (
    sudo mount /mnt/f100/home/
    sudo mount /mnt/f100/lehre/
    sudo mount /mnt/znlserv/
)

Weitere Tipps

Die Freiberger Linux User Group (FluX) bietet auf ihrer Homepage weitere Tipps zum Thema an.