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.
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 ip_gre.o und befindet sich bei den Kernel-Modulen, normalerweise im Verzeichnis /lib/modules/
Das das Modul ip_gre noch nicht geladen wurde, merkt man spätestens, wenn die VPN-Verbindung mit der folgenden Fehlermeldung abbricht:
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
Denken Sie bitte daran, daß 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.
Sollte alles soweit korrekt gelaufen sein, weiß man schonmal, daß die technische Verbindung zum VPN-Server funktioniert und der VPN-Tunnel aufgebaut wird. Ein Blick auf das Routing (route -n) zeigt, daß 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:
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:
Wenn dies bei Ihnen funktioniert, haben Sie Ihren VPN-Zugang über T-DSL via Satellit erfolgreich eingerichtet. Herzlichen Glückwunsch.
Aug 4 22:49:34 athlon pptp[11434]: log[decaps_gre:pptp_gre.c:215]: short read (4294967295): Protocol not available
Aug 4 22:49:34 athlon pppd[11433]: Terminating on signal 15.
Um diesen Fehler auszuschließen, empfiehlt es sich, beim automatisierten VPN-Verbindungsaufbau vor dem Aufruf von pptp ein "modprobe ip_gre" 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.
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.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
somebody@localhost:~ # pptp ses.hsi.astra-net.com debug user
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:
Aug 21 07:47:00 athlon pptp[15982]: log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:708]: Outgoing call established (call ID 0, peer's call ID 0).
Aug 21 07:47:00 athlon pppd[15979]: pppd 2.4.1 started by root, uid 0
Aug 21 07:47:00 athlon pppd[15979]: using channel 68
Aug 21 07:47:00 athlon pppd[15979]: Using interface ppp0
Aug 21 07:47:00 athlon pppd[15979]: Connect: ppp0 <--> /dev/pts/4
Aug 21 07:47:00 athlon pppd[15979]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x778161fe> <pcomp> <accomp>]
Aug 21 07:47:02 athlon pppd[15979]: sent [LCP ConfReq id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x778161fe> <pcomp> <accomp>]
Aug 21 07:47:02 athlon pppd[15979]: rcvd [LCP ConfAck id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x778161fe> <pcomp> <accomp>]
Aug 21 07:47:02 athlon pppd[15979]: rcvd [LCP ConfAck id=0x1 <mru 1452> <asyncmap 0x0> <magic 0x778161fe> <pcomp> <accomp>]
Aug 21 07:47:03 athlon pppd[15979]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap m$oft> <magic 0xdcf8f6a8> <pcomp> <accomp>]
Aug 21 07:47:03 athlon pppd[15979]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap m$oft> <magic 0xdcf8f6a8> <pcomp> <accomp>]
Aug 21 07:47:03 athlon pppd[15979]: sent [LCP EchoReq id=0x0 magic=0x778161fe]
Aug 21 07:47:03 athlon pppd[15979]: cbcp_lowerup
Aug 21 07:47:03 athlon pppd[15979]: want: 2
Aug 21 07:47:03 athlon pppd[15979]: rcvd [CHAP Challenge id=0x1 <b10fb56dc43aaa07>, name = "g2hsig04"]
Aug 21 07:47:03 athlon pppd[15979]: sent [CHAP Response id=0x1 <000000000000000000000000000000000000000000000000dc6bb6118209d1f5b3295fbff525951e2a5652cc217daab701>, name = "<username>"]
Aug 21 07:47:03 athlon pppd[15979]: rcvd [LCP EchoRep id=0x0 magic=0xdcf8f6a8]
Aug 21 07:47:04 athlon pppd[15979]: rcvd [CHAP Success id=0x1 "Welcome to g2hsig04."]
Aug 21 07:47:04 athlon pppd[15979]: Remote message: Welcome to g2hsig04.
Aug 21 07:47:04 athlon pppd[15979]: sent [IPCP ConfReq id=0x1 <addr 192.168.97.2> <compress VJ 0f 01>]
Aug 21 07:47:04 athlon pppd[15979]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Aug 21 07:47:04 athlon pppd[15979]: rcvd [IPCP ConfReq id=0x1 <addr 212.56.240.60> <compress VJ 0f 01>]
Aug 21 07:47:04 athlon pppd[15979]: sent [IPCP ConfAck id=0x1 <addr 212.56.240.60> <compress VJ 0f 01>]
Aug 21 07:47:04 athlon pppd[15979]: rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Aug 21 07:47:04 athlon pppd[15979]: sent [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Aug 21 07:47:04 athlon pppd[15979]: rcvd [IPCP ConfNak id=0x1 <addr 172.24.9.xxx>]
Aug 21 07:47:04 athlon pppd[15979]: sent [IPCP ConfReq id=0x2 <addr 172.24.9.xxx> <compress VJ 0f 01>]
Aug 21 07:47:04 athlon pppd[15979]: rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Aug 21 07:47:04 athlon pppd[15979]: Deflate (15) compression enabled
Aug 21 07:47:06 athlon pppd[15979]: rcvd [IPCP ConfAck id=0x2 <addr 172.24.9.xxx> <compress VJ 0f 01>]
Aug 21 07:47:06 athlon pppd[15979]: local IP address 172.24.9.xxx
Aug 21 07:47:06 athlon pppd[15979]: remote IP address 212.56.240.60
Aug 21 07:47:06 athlon pppd[15979]: Script /etc/ppp/ip-up started (pid 15991)
Aug 21 07:47:06 athlon pppd[15979]: Script /etc/ppp/ip-up finished (pid 15991), status = 0x0
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.
Ziel Router Genmask Flags Metric Ref Use Iface
212.56.240.60 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
62.180.158.3 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0
192.168.213.0 0.0.0.0 255.255.255.0 U 0 0 0 dvb0_0
192.168.97.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 62.180.158.3 0.0.0.0 UG 0 0 0 ippp0
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:
somebody@localhost:~ # su -c "route add
somebody@localhost:~ # su -c "route add ses.hsi.astra-net.com dev ippp0"
somebody@localhost:~ # su -c "route del default"
somebody@localhost:~ # su -c "route add default dev ppp0"
Ziel Router Genmask Flags Metric Ref Use Iface
212.56.240.60 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 (VPN)
62.134.11.4 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0
62.180.158.1 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 (DNS)
195.182.110.132 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 (DNS)
192.168.213.0 0.0.0.0 255.255.255.0 U 0 0 0 dvb0_0
192.168.97.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
212.56.240.62 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 (VPN)
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 (Default)
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.
Next
Previous
Contents