6.1 Unterschiede zwischen VPN und Proxy

Bis zur Einführung von neuen VPN-Servern bei SES Astra Anfang August 2002 gab es einen entscheidenden Nachteil für den VPN-Zugang im Vergleich zu der im bisherigen Teil dieses HowTo's dargestellten Zugangsweise über den Tellique-Proxy: Beim VPN-Zugang wurde das Link-Sharing nicht eingesetzt. Dadurch wurde im Gegensatz zum Proxy die Telefonverbindung nur für den Hinweg der Daten in's Netz genutzt und alle Pakete kamen über den Satelliten zurück. Die Nichtberücksichtigung der Telefonleitung für den Rückkanal sorgte für subjetive Geschwindigkeitseinbußen beim Surfen und konnte sogar zu Übertragungsraten unterhalb der normalen Telefonverbindung führen. Da die Satelliten-Verbindung der einzige Übertragungsweg beim VPN war, wurde die Übertragungsgeschwindigkeit natürlich auch ausschließlich durch den Satelliten und dessen verfügbare Bandbreite definiert, während bei der Proxy-Lösung minimal die Performance der Telefonverbindung erreicht wurde, da die Pakete bei einem überlasteten Satelliten einfach über die terrestrische Verbindung zurückgeschickt wurden. Seit dem mit den neuen VPN-Servern bei SES Astra nun auch das Link-Sharing für den VPN-Zugang funktioniert, reduzieren sich die Unterschiede zwischen dem Proxy- und VPN-Zugang auf die Tatsache das der Proxy mit Multicasting arbeitet, während beim VPN die Datenpakete per Unicast versendet werden. Eine direkte Auswirkung für den täglichen Einsatz hat dieser Unterschied allerdings nicht. Gegenüber dem Proxy-Zugang hat der VPN-Zugang auch einige Vorteile. So wird mittels VPN jeglicher Datenverkehr mit dem Internet beschleunigt, während beim Proxy standardmässig nur das HTTP- und FTP-Protokoll beschleunigt wird. Desweiteren erhalten durch den Verzicht auf Multicasting auch Nutzer von vollwertigen DVB-s Karten (mit MPEG2-Decoder) die Möglichkeit einen stabilen Netzwerk-Zugang über den Satelliten zu verwirklichen. Außerdem ist der VPN-Zugang komplett mit Open-Source Software zu realisieren, während der Proxy nur als closed-source verfügbar ist und es zu diesem keine Open-Source Alternative gibt. Nach meinen bisherigen Erfahrungen gibt es keinen Unterschied beim Datendurchsatz zwischen dem Proxy und VPN. Die Übertragungsgeschwindigkeit variiert bei beiden Lösungen in Abhängigkeit von der aktuellen Belegung des Transponders.

6.2 Installation pptp-Client

Unter  http://pptpclient.sourceforge.net/ befindet sich die Projektseite des pptp-Clients für Linux. Dieses Programm ist in der Lage über den Linux-pppd eine VPN-Verbindung zu einem Windows-VPN-Server aufzubauen. Der pppd muß dabei mindestens Version 2.4.0 oder höher sein, ansonsten muß man einen Patch dafür einspielen (Nähere Details im SAT-HowTo). Man kann dort das Ganze als vorkompiliertes RPM-Paket oder Source-Tarball herunterladen. Beide Varianten funktionierten bei meinen Versuchen einwandfrei. Nachdem man das RPM installiert bzw. die Source mit make kompiliert hat, kann man auch fast schon loslegen. Es fehlt allerdings noch ein Kernel-Modul, welches vor der Verwendung von pptp geladen werden muß. Das Modul heißt ipgre.o und befindet sich bei den Kernel-Modulen, normalerweise im Verzeichnis /lib/modules//kernel/net/ipv4. Dieses Modul wird (zumindest bei meiner Linux-Distribution) nicht automatisch geladen. Es muß daher entweder mit in den Kernel kompiliert werden oder als Modul manuell geladen werden. Letzteres geschieht am einfachsten mit modprobe, da auf diese Weise das Modul nur geladen wird, wenn dies vorher noch nicht geschehen ist. Das das Modul ipgre noch nicht geladen wurde, merkt man spätestens, wenn die VPN-Verbindung mit der folgenden Fehlermeldung abbricht:

Um diesen Fehler auszuschließen, empfiehlt es sich, beim automatisierten VPN-Verbindungsaufbau vor dem Aufruf von pptp ein modprobe ipgre einzubauen. Auf diese Weise kann man sicher sein, daß das Modul tatsächlich geladen ist.

6.3 Benutzerkennung in /etc/ppp/pap-secrets und /etc/ppp/chap-secrets

Um eine Verbindung zu einem VPN-Server aufzubauen, wird ein Benutzername und ein Passwort benötigt. Für das T-DSLvS-VPN handelt es sich hierbei um den Nutzernamen und das Passwort, welches Sie bei der Registrierung von der Telekom übermittelt bekamen bzw. und die von Ihnen entsprechend geänderten Angaben. Da der VPN-Tunnel im Grunde genommen nichts anderes als eine zusätzliche, virtuelle ppp-Verbindung mit dem VPN-Server als Einwahlserver darstellt, müssen die Angaben in /etc/ppp/pap-secrets und /etc/ppp/chap-secrets eingetragen werden. Fügen Sie zu den bestehenden Dateien einfach jeweils eine weitere Zeile im Format
nutzername passwort
ein. Da nur der Superuser eine Berechtigung für diese sensible Dateien hat, müssen natürlich auch alle Änderungen mit SU-Rechten durchgeführt werden. Beim Aufbau der VPN-Verbindung wird der pppd nach dem von Ihnen spezifizierten Benutzernamen entweder in pap-secrets oder chap-secrets suchen und das dort vorgefundene Passwort beim Verbindungsaufbau verschlüsselt an den VPN-Server übermitteln. Denken Sie bitte daran, dass der Zugang über VPN nur funktioniert, wenn sie diesen in Ihrem Registrierungsdaten angegeben haben. Ist dies nicht der Fall, wird der Verbindungsaufbau wegen unbekanntem Usernamen abgelehnt, auch wenn Sie in den Secret-Dateien vielleicht alles korrekt eingetragen haben.

6.4 Erster Verbindungstest

Nun kann man einen ersten Verbindungstest machen, ob der VPN-Tunnel zum Astra-Server auch korrekt aufgebaut wird. Der VPN-Server von TDSLvS heißt ses.hsi.astra-net.com (mehrere IP-Adressen im Subnetz 212.56.240.0). Ist dies geschehen, kann man mit dem Befehl

prüfen, ob der Verbindungsaufbau funktioniert. Wer kein dial-on-demand benutzt, sollte natürlich zuvor die herkömmliche Verbindung in's Internet aufgebaut haben. Die Ausgabe von pptp sollte in etwa so aussehen:

Wichtig ist vor allem die Angabe des mru/mtu-Wertes von 1452 (MRU = Max. Receiving Unit; MTU = Max. Transfer Unit, sprich die maximale Blockgröße für den Datenversand und -empfang). Standardmässig werden diese Parameter vom pppd nicht gesetzt und der Defaultwert von 1500 verwendet. Mit dieser Größe funktioniert jedoch der Datentransfer mit den VPN-Servern nicht. Sollte alles soweit korrekt gelaufen sein, weiß man schonmal, dass die technische Verbindung zum VPN-Server funktioniert und der VPN-Tunnel aufgebaut wird. Ein Blick auf das Routing (route -n) zeigt, dass ein zusätzliches ppp-Device (ppp0) mit einer Route zum VPN-Server aufgemacht wurde, die eigentliche Internet-Verbindung wird bei mir vom ISDN-Device ippp0 aufgebaut, das VPN-Device ist dann ppp0:

Mit diesem Routing läuft aber noch kein Paket durch den Tunnel sondern es wird weiterhin die "normale" Leitung benutzt, weil die Default-Route auf das ISDN-Device zeigt und nicht auf den Tunnel. Außerdem muß das Tuning der DVB-Karte ja auch noch gegenüber dem Multicast/Proxy-Einsatz verändert werden.

6.5 Konfiguration DVB-Device

Zwischen der Konfiguration des DVB-Devices beim Proxy-Zugang und der VPN-Lösung gibt es nur einen Unterschied, und das ist die PID, die bei dvbtune, Parameter -n, angegeben werden muß. Folgen Sie also den Anweisungen in den Abschnitten 5.2 bis 5.4, statt der Multicast-PID 251 verwenden Sie nun aber die Unicast-Pid 253. Ich habe festgestellt, daß es nicht ausreicht, bei bestehendem Tuning für die Proxy-Lösung einfach dvbtune mit -n 253 nochmal aufzurufen um dann mit Unicast arbeiten zu können. Wenn man vorher über den Proxy gearbeitet hat, sollte man die dvb-Treiber erst neu laden und dann mit dvbtune auf Unicast tunen.

6.6 Verändern des Routings

Um nun auch die in's Internet zu versendenden Pakete tatsächlich durch den Tunnel zu schicken, muß die Default-Route vom eigentlichen Verbindungsdevice (bei mir ippp0) auf das VPN-Device (ppp0) gelegt werden. Dies alleine reicht aber noch nicht aus da dadurch auch die Encap-Pakete an den VPN-Server, die eigentlich über das ippp0-Device laufen sollten, über das VPN-Device geroutet werden, was so nicht funktioniert. Außerdem braucht man ja für die Nameserver-Anfragen gar keine hohe Übertragungsrate, sondern eher eine schnelle Reaktionszeit. Am Routing werden jetzt also folgende Veränderungen vorgenommen: Nameserver explizit über ISDN-Device routen (optional)

Route zu VPN-Servern über ISDN-Device legen

Löschen der Default-Route

neue Default-Route auf VPN-Device

Die Änderungen des Routings müssen natürlich bei bestehender Internet-und VPN-Verbindung durchgeführt werden, da ansonsten z.B. das Device ppp0 gar nicht verfügbar ist. Das neue Routing sieht dann in etwa so aus:

6.7 Zweiter Test

Der bislang an dieser Stelle darstellte Test mittels Ping auf einen externen Rechner funktioniert aufgrund des Link-Sharings nicht mehr. Die beim Ping versendeten Datenmengen sind in der Regel zu klein, um tatsächlich über den Satelliten geroutet zu werden. Statt dessen sollten Sie versuchen per ftp oder wget eine größere Datei aus dem Internet zu laden und dabei die Performance und Datenpakete auf den beteiligten Devices mittels tcpdump oder iptraf kontrollieren. Wenn dies bei Ihnen funktioniert, haben Sie Ihren VPN-Zugang über T-DSL via Satellit erfolgreich eingerichtet. Herzlichen Glückwunsch.