[- gelöst -] Debian - VPN-Zugriff

iYassin

Well-known member
Themenstarter
Registriert
15 Mai 2009
Beiträge
10.197
So, nachdem mein Seagate Dockstar jetzt schonmal im internen Netzwerk als Dateiserver funktioniert, würde ich gerne auch extern per VPN auf ihn zugreifen können.

Auf meinem "großen" Windows XP-Server hatte ich eine PP2P-VPN-Verbindung eingerichtet. Der Zugriff von außen läuft per DynDNS und eine Portweiterleitung im Router (der selbst aber nur VPN-Passthrough unterstützt). Mit dem Server konnte ich mich dann nach Eingabe von Username und Passwort über den in Windows oder Mac OS X integrierten VPN-Client verbinden. Das hat auch immer super funktioniert.

Die Nachteile des großen Servers sind aber:
- Datenübertragungsrate
- Stromverbrauch
- Lautstärke (die HDDs sind eben einfach immer noch laut)
- Größe

Daher fände ich es gut, komplett auf den Dockstar umsteigen zu können. VPN zwecks Zugriff auf den Server von unterwegs ist aber zwingend nötig.
Daher meine Frage: Lässt sich so ein VPN auch unter Debian Squeeze auf dem Dockstar einrichten?

Es wäre super, wenn ihr mir helfen könntet, das einzurichten.

Viele Grüße,

iYassin
 
So, ich habe es jetzt immerhin eingerichtet bekommen ;)
Diese Anleitung hier habe ich verwendet: http://sysadmingeek.com/articles/setting-up-a-vpn-pptp-server-on-debian/

Nur: Sobald ich im Router das Portforwarding für TCP1723 auf die Dockstar-IP umstelle, bekommt mein Macpad (mit dem ich gerade per UMTS teste) keine Verbindung und sagt gleich wieder "Verbindung getrennt", nicht mal irgendwie "Passwort falsch" oder so was. Er bekommt anscheinend überhaupt keine Verbindung.

netstat -nlp auf dem Dockstar sagt mir, dass sich pptpd auf Port 1723 im LISTEN-Modus befindet. Insofern sollte es daran ja auch nicht hängen... hätte jemand noch einen Tipp, was falsch sein kann?
 
OpenVPN

Hi,

schau dir mal diese Anleitung an http://webcache.googleusercontent.c...N+site:wiki.ubuntuusers.de&cd=1&hl=de&ct=clnk . Die müßte 1:1 auch unter Debian gehen.

Noch ein Hinweis: der Server horcht standardmäig an Port 1194/udp. Du mußt dafür am Router eine entsprechende Weiterleitung einrichten.

Die ausführliche Doku gibt's auf der Homepage (vom Howto dort hat der Artikelschreiber erkennbar abgepinnt):
http://openvpn.net/index.php/open-source/documentation.html

Vorteile von OpenVPN sind
- durchaus einsteigertaugliche Konfiguration (solide Linux- und TCP/IP-Kenntnisse braucht es aber trotzdem)
- aussagekräftige Meldungen im Logfile (sowas hat man heute nur noch sehr selten)

EDITH: von PPTP hab ich leider keine Ahnung.
EDITH2: PPTP gilt als unsicher: http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security_of_the_PPTP_protocol
 
OpenVPN scheint auf den ersten Blick aber deutlich komplizierter als PPTP mit den Zertifikaten etc...
Sehe ich das richtig, dass ich dafür dann unter Windows noch was installieren muss?

Ich hab in der Zwischenzeit nochmal mit PPTP rumprobiert und mal versucht, mit Windows eine Verbindung herzustellen - da gibts sogar eine geeignete Fehlermeldung ;)
Er kommt immerhin den Router rein, versucht User und Passwort zu übertragen, dann kommt aber "Fehler 619, Verbindung konnte nicht hergestellt werden". Sieht ganz so aus, als wäre der Port doch nicht freigegeben. Ich werde gleich mal mit nmap den Dockstar scannen.
Hat Debian eine integrierte Firewall, in der man den Port erst noch freischalten muss?
 
iptables gibts nicht (soll ich das dann nachinstallieren?), netstat -lntp habe ich ausgeführt.
Anhang anzeigen 35729

Die Einwahl aus dem lokalen Netz geht auch nicht, daher liegt das Problem wohl beim Debian selbst. Von daher sollte GRE (noch) nicht das Problem sein ;)

Der nmap-Scan ergab, dass Port 1723 offen ist.

EDIT: Wenn das mit dem OpenVPN nur mit Zusatzsoftware geht, wäre mir PPTP vorerst doch lieber...
 

Anhänge

  • putty.PNG
    putty.PNG
    59 KB · Aufrufe: 10
Hast Du PPTP schon auf anderen Systemen laufen?

Als ich es das letzte mal versucht habe kam ich nicht am Router vorbei. Wahrscheinlich mit ein Grund warum es überhaupt immer noch so viel Wirrwarr bei VPN gibt obwohl MS ein funktionierendes Paket mitbringt. Erinnert mich an den ersten Wildwuchs bei TCP/IP der sich sofort lichtete als MS ein funktionierendes Paket integrierte aber bei VPN scheint MS die Routerhersteller nicht genug bearbeitet zu haben.

Zumindest die Grundkonfiguration fand ich bei OpenVPN trivial. Key generieren, diese auf Client und Server kopieren und die Beispielkonfiguration auf Server und Client vom FAQ abschreiben, fertig. Dann nur noch Namensauflösung mit z.B. DynDNS und Portforwarding konfigurieren. Leicht problematisch finde ich dabei, dass man den Schlüssel in einer Datei hat und gewährleisten muss, dass sie nicht gestohlen werden. Ok wenn Du beide Rechner unter Kontrolle hast aber wenn es ein Kundenrechner ist in das man alle paar Jahre reinschaut wenn er schreit es würde nichts mehr richtig funktionieren...

Andererseits würde ich für Administration IMMER ssh vorziehen. VNC oder Remote Desktop ist nett wenn man schnelle Leitung hat aber bei ADSL Leitungen mit schmalen Uplink empfand ich es leider immer als eine Notlösung. Und ja, ich nutze selbst beim Server im Nebenraum der mit GBIT angebunden ist, am liebsten ssh.
 
Für die Fehlersuche solltest Du auf jeden Fall in die serverseitigen Logs schauen. Nur dort kannst Du sehen ob der Client tatsächlich Kontakt bekommt und warum ihn ggf. der Server-Dämon nicht reinläßt.
 
So, hab mal versucht, in die Logs zu schauen - das Problem ist, ich habe keine /var/log/messages, bzw. bekomme die nicht geöffnet. Eine syslogd.conf existiert bei mir aber ebenfalls nicht... von daher gehe ich eher davon aus, dass bei meinem Debian kein Logging aktiviert ist.

Wie kann ich das denn aktivieren?
 
iYassin' schrieb:
So, hab mal versucht, in die Logs zu schauen - das Problem ist, ich habe keine /var/log/messages, bzw. bekomme die nicht geöffnet. Eine syslogd.conf existiert bei mir aber ebenfalls nicht... von daher gehe ich eher davon aus, dass bei meinem Debian kein Logging aktiviert ist.

Wie kann ich das denn aktivieren?
In dem Fall ist wohl Syslogd nicht installiert.

Welchen Router hast Du im Einsatz? Als ich noch wegen PPTP recherchiert habe waren Draytek und AVM die einzigen die zu halbwegs Consumer-Preisen das notwendige GRE unterstützten. Gibt es mittlerweile auch andere preiswerte Router mit GRE Unterstützung?
 
Ich habe einen Netgear DG834NBv2. Preiswert war der nicht gerade :D aber natürlich trotzdem ein Consumer-Gerät.
Ich bin mir nicht sicher, ob er GRE kann. Wird GRE denn auch genutzt, wenn von einem Mac OS X- oder auch Windows-Client eine PPTP-VPN-Verbindung zu einem Windows-XP-Server aufgebaut wird? Wen dem so ist, dann muss der Router GRE können, weil ich nämlich ohne Probleme mit allen meinen Rechnern eine PPTP-VPN-Verbindung zu meinem Windows-Server aufbauen kann.
Oder wird GRE nur bei Linux-VPN-Servern genutzt?

Wie kann man syslogd denn nachinstallieren? Wenn ich
Code:
apt-get install syslogd
eingebe, kommt nämlich nur so eine - mir jetzt nicht besonders viel sagende - Meldung:
Anhang anzeigen 35896
Muss man da noch etwas extra angeben? Oder wird syslogd nicht über apt-get installiert?
 
Debian seit Lenny verwendet den rsyslogd. Konfiguriert wird dieser in /etc/rsyslog.conf bzw. unterhalb von /etc/rsyslog.d/. Eventuell muß auch zuerst am pptpd der Loglevel eingestellt/erhöht werden.
 
Auch der ist leider nicht installiert.
Nachinstallieren klappt hier über apt-get auch nicht:
Code:
root@debian:~# apt-get install rsyslogd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package rsyslogd is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'rsyslogd' has no installation candidate

EDIT: So, apt-get install rsyslog hat geklappt. :thumbup:
 
Wow, es funktioniert :D
Der Server bekommt wohl was vom VPN-Client mit. Hier das serverseitige Log des Verbindungsversuchs:
Code:
Oct 17 20:05:57 debian pptpd[769]: MGR: Launching /usr/sbin/pptpctrl to handle client
Oct 17 20:05:57 debian pptpd[769]: CTRL: local address = 192.168.1.1
Oct 17 20:05:57 debian pptpd[769]: CTRL: remote address = 192.168.2.1
Oct 17 20:05:57 debian pptpd[769]: CTRL: pppd options file = /etc/ppp/pptpd-options
Oct 17 20:05:57 debian pptpd[769]: CTRL: Client 192.168.0.7 control connection started
Oct 17 20:05:57 debian pptpd[769]: CTRL: Received PPTP Control Message (type: 1)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Made a START CTRL CONN RPLY packet
Oct 17 20:05:57 debian pptpd[769]: CTRL: I wrote 156 bytes to the client.
Oct 17 20:05:57 debian pptpd[769]: CTRL: Sent packet to client
Oct 17 20:05:57 debian pptpd[769]: CTRL: Received PPTP Control Message (type: 7)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Set parameters to 100000000 maxbps, 64 window size
Oct 17 20:05:57 debian pptpd[769]: CTRL: Made a OUT CALL RPLY packet
Oct 17 20:05:57 debian pptpd[769]: CTRL: Starting call (launching pppd, opening GRE)
Oct 17 20:05:57 debian pptpd[769]: CTRL: pty_fd = 6
Oct 17 20:05:57 debian pptpd[769]: CTRL: tty_fd = 7
Oct 17 20:05:57 debian pptpd[769]: CTRL: I wrote 32 bytes to the client.
Oct 17 20:05:57 debian pptpd[769]: CTRL: Sent packet to client
Oct 17 20:05:57 debian pptpd[771]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
Oct 17 20:05:57 debian pptpd[771]: CTRL (PPPD Launcher): local address = 192.168.1.1
Oct 17 20:05:57 debian pptpd[771]: CTRL (PPPD Launcher): remote address = 192.168.2.1
Oct 17 20:05:57 debian pptpd[769]: CTRL: Received PPTP Control Message (type: 15)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Oct 17 20:05:57 debian pppd[771]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so is for pppd version 2.4.4, this is 2.4.5
Oct 17 20:05:57 debian pptpd[769]: GRE: read(fd=6,buffer=1fb40,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Oct 17 20:05:57 debian pptpd[769]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Oct 17 20:05:57 debian pptpd[769]: CTRL: Reaping child PPP[771]
Oct 17 20:05:57 debian pptpd[769]: CTRL: Client 192.168.0.7 control connection finished
Oct 17 20:05:57 debian pptpd[769]: CTRL: Exiting now
Oct 17 20:05:57 debian pptpd[507]: MGR: Reaped child 769
 
Das sieht wie von Gummiente prophezeit nach einem GRE-Problem aus:
Code:
Oct 17 20:05:57 debian pptpd[769]: GRE: read(fd=6,buffer=1fb40,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Vielleicht sagt er noch was dazu, ich kann nur OpenVPN...
 
Das Problem lag eine Zeile obendrüber. Dieses longwtmp-Modul hat dafür gesorgt, dass ppp abgestürzt ist, daher kam die Verbindung nicht zustande. longwtmp auskommentiert und schon geht es ;)
Ich bin jetzt erfolgreich im VPN eingeloggt. Problem ist nur, dass ich den Router und die anderen Rechner im Netz nicht anpingen kann (das ist aber auch nicht wichtig), aber auch nicht den Dockstar selbst, weshalb ich auch die Samba-Freigabe nicht einbinden kann - was mich viel mehr stört.

Wie muss ich denn die localip und die remoteip in der pptpd.conf setzen? Müssen die aus demselben Adressbereich sein? Oder sogar aus dem IP-Bereich meines eigenen Netzwerks? Kann das Kommunikationsproblem daran liegen?

PS: Welchen Sinn hat es eigentlich, mehr als eine IP bei "localip" anzugeben (das ist im Beispiel so)? Wenn ich nach Verbindungsherstellung die Verbindungseigenschaften aufrufe, dann habe ich selbst eine IP aus dem Bereich, den ich bei remoteip angegeben habe, und der VPN-Server hat die erste IP aus dem Bereich, der bei localip angegeben ist.

EDIT: So, hab jetzt die remoteip-IPs in den selben Adressraum gesetzt wie die localips, jetzt geht es.
Ich denke mal, ich werde dann jetzt komplett vom großen XP-Server auf den Dockstar umsteigen.
 
Vielen Dank für Deine Ausdauer. :)

Ich werde meinen Gerätepool durchforsten ob sich das eine oder andere Netgear DG834NBv2 findet. OpenVPN wird wohl nach wie vor für die meisten Fälle in Einsatz kommen weil er immer funktioniert aber PPTP dürfte, obwohl als unsicherer gebrandmarkt, von Windows Nutzern weniger als Fremdkörper empfunden werden.

Nochmals vielen Dank. :)
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben