Servidor Debian + VPN PPTP - conexão não está funcionando

2

Eu configurei um Seagate DockStar com o Debian Squeeze como um pequeno servidor na minha rede doméstica. Eu gostaria de acessá-lo de fora da minha própria rede agora, então eu preciso de uma conexão VPN. BTW, eu não tenho um roteador com um servidor VPN integrado. Já tenho um servidor "grande" do Windows XP em execução, o qual posso acessar por meio de um túnel VPN PPTP. Isso foi muito fácil, mas agora com o Debian, tenho alguns problemas para configurar a conexão VPN.

Eu instalei o pptpd via

apt-get install pptpd 

já. Este é o meu pptpd.conf:

# TAG: ppp
#    Path to the pppd program, default '/usr/sbin/pppd' on Linux
#
#ppp /usr/sbin/pppd

# TAG: option
#    Specifies the location of the PPP options file.
#    By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/pptpd-options

# TAG: debug
#    Turns on (more) debugging to syslog
#
#debug

# TAG: stimeout
#    Specifies timeout (in seconds) on starting ctrl connection
#
# stimeout 10

# TAG: noipparam
#       Suppress the passing of the client's IP address to PPP, which is
#       done by default otherwise.
#
#noipparam

# TAG: logwtmp
#    Use wtmp(5) to record client connections and disconnections.
#
logwtmp

# TAG: bcrelay <if>
#    Turns on broadcast relay to clients from interface <if>
#
#bcrelay eth1

# TAG: localip
# TAG: remoteip
#    Specifies the local and remote IP address ranges.
#
#       Any addresses work as long as the local machine takes care of the
#       routing.  But if you want to use MS-Windows networking, you should
#       use IP addresses out of the LAN address space and use the proxyarp
#       option in the pppd options file, or run bcrelay.
#
#    You can specify single IP addresses seperated by commas or you can
#    specify ranges, or both. For example:
#
#        192.168.0.234,192.168.0.245-249,192.168.0.254
#
#    IMPORTANT RESTRICTIONS:
#
#    1. No spaces are permitted between commas or within addresses.
#
#    2. If you give more IP addresses than MAX_CONNECTIONS, it will
#       start at the beginning of the list and go until it gets 
#       MAX_CONNECTIONS IPs. Others will be ignored.
#
#    3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#       you must type 234-238 if you mean this.
#
#    4. If you give a single localIP, that's ok - all local IPs will
#       be set to the given one. You MUST still give at least one remote
#       IP for each simultaneous client.
#
# (Recommended)
localip 192.168.0.120
remoteip 192.168.0.121-129
# or
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245

Meu servidor DHCP no roteador está distribuindo IPs começando com 192.168.0.2. Meu grande servidor distribuiu IPs começando em 192.168.0.121 para clientes VPN (o servidor em si tinha o xxx120 TP) - como eu já escrevi, no servidor grande VPN funciona, então eu apenas configurei o localip e o remoteip range para aqueles de o grande servidor.

As minhas opções pptpd são assim:

# Authentication

# Name of the local system for authentication purposes 
# (must match the second field in /etc/ppp/chap-secrets entries)
name pptpd

# Optional: domain name to use for authentication
# domain mydomain.net

# Strip the domain prefix from the username before authentication.
# (applies if you use pppd with chapms-strip-domain patch)
#chapms-strip-domain


# Encryption
# Debian: on systems with a kernel built with the package
# kernel-patch-mppe >= 2.4.2 and using ppp >= 2.4.2, ...
# {{{
refuse-pap
refuse-chap
refuse-mschap
# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
# Challenge Handshake Authentication Protocol, Version 2] authentication.
require-mschap-v2
# Require MPPE 128-bit encryption
# (note that MPPE requires the use of MSCHAP-V2 during authentication)
#require-mppe-128
# }}}




# Network and Routing

# If pppd is acting as a server for Microsoft Windows clients, this
# option allows pppd to supply one or two DNS (Domain Name Server)
# addresses to the clients.  The first instance of this option
# specifies the primary DNS address; the second instance (if given)
# specifies the secondary DNS address.
# Attention! This information may not be taken into account by a Windows
# client. See KB311218 in Microsoft's knowledge base for more information.
#ms-dns 10.0.0.1
#ms-dns 10.0.0.2

# If pppd is acting as a server for Microsoft Windows or "Samba"
# clients, this option allows pppd to supply one or two WINS (Windows
# Internet Name Services) server addresses to the clients.  The first
# instance of this option specifies the primary WINS address; the
# second instance (if given) specifies the secondary WINS address.
#ms-wins 10.0.0.3
#ms-wins 10.0.0.4

# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system.  This will have the effect of making the peer appear to other
# systems to be on the local ethernet.
# (you do not need this if your PPTP server is responsible for routing
# packets to the clients -- James Cameron)
proxyarp

# Debian: do not replace the default route
nodefaultroute


# Logging

# Enable connection debugging facilities.
# (see your syslog configuration for where pppd sends to)
#debug

# Print out all the option values which have been set.
# (often requested by mailing list to verify options)
#dump


# Miscellaneous

# Create a UUCP-style lock file for the pseudo-tty to ensure exclusive
# access.
lock

# Disable BSD-Compress compression
nobsdcomp 

ms-dns 192.168.0.1
netmask 255.255.255.0
noipx
mtu 1490
mru 1490

No arquivo chap-secrets, registrei um usuário. (como o seguinte: - isto está certo?)

netstat me diz que a porta 1723 está aberta e ouvida pelo pptpd, bem como uma varredura de porta nmap de outro computador. O iptables não está instalado no DockStar. No meu roteador, estou encaminhando todas as conexões TCP ou UDP para a porta 1723 para o IP do DockStar.

Eu tentei me conectar com um cliente Windoows XP, Windows 7 e Mac OS X. Todos não conseguem estabelecer uma conexão. O Mac OS X mostra apenas uma mensagem de erro geral, os clientes do Windows mostram "Erro 619 - Não foi possível estabelecer uma conexão com o computador remoto". Os clientes estão configurados para usar o MSCHAPv2 com o nome de usuário e a senha configurados no arquivo chap-secrets.

Não importa se eu tento conectar-me ao servidor do meu notebook na mesma rede ou por meio da minha conexão WWAN (enquanto o WiFi está desativado) - ele não funciona toda vez que tento me conectar.

Alguém tem uma ideia do que há de errado com a configuração do servidor e sabe como posso fazê-lo funcionar?

Agradecemos antecipadamente

iYassin

    
por iYassin 13.10.2010 / 23:09

2 respostas

0

Bem, eu realmente não tinha nenhum serviço de log instalado na minha instalação Debian. Agora eu instalei o rsyslog, então aqui está o log escrito em / var / log / syslog quando tento me conectar ao servidor VPN via PPTP com meu computador com Windows 7:

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

Parece que algo está errado com o GRE ... mas, como eu já disse, uma conexão PPTP para meu servidor Windows está funcionando (se eu definir o encaminhamento de porta no meu roteador de volta para o servidor Windows). Os servidores Windows usam GRE para conexões VPN PPTP? Se sim, acho que posso supor que meu roteador tenha suporte a GRE. Eu talvez tenha que configurar o suporte GRE no sistema Debian?

    
por 17.10.2010 / 20:13
0

Não está totalmente claro para mim como o PPTP funcionou para o servidor Windows XP quando você encaminhou todo o tráfego da porta 1723 para o servidor Debian Squeeze. Você provavelmente só pode "VPN" para o servidor WinXP de dentro de sua LAN local, o que parece ser de utilidade limitada.

Independentemente disso, o PPTP requer não apenas o tráfego da porta TCP 1723, mas também o protocolo GRE. Seu roteador é capaz de manipular túneis GRE corretamente? Se é um roteador comum ao consumidor, suspeito que não. E mesmo que seja, GRE é suficientemente esotérico para que encontrar ajuda seja difícil.

No seu caso, eu recomendo tentar uma solução VPN que use apenas transportes TCP e / ou UDP, já que esses protocolos são onipresentes e bem conhecidos. O OpenVPN é uma dessas soluções de VPN e está disponível para todos os principais sistemas operacionais (Win, Mac, Linux, * BSD).

Dependendo do que você está tentando realizar, outra possibilidade é executar o sshd no servidor Debian, por exemplo:

apt-get install openssh-server

Todos os principais sistemas operacionais têm clientes ssh livres capazes de criar túneis através de uma conexão ssh.

    
por 14.10.2010 / 00:39