[Fedora-users-br] VPN PPTP
Cristiano Furtado
jasonnfedora em gmail.com
Ter Dez 5 17:29:01 UTC 2006
ficou faltando o:
[root em fedora ppp]# cat ../pptpd.conf
option /etc/ppp/options.pptpd
logwtmp
stimeout 400
#bcrelay eth1
localip 192.168.0.240
remoteip 192.168.0.241-250
2006/12/5, Cristiano Furtado <jasonnfedora em gmail.com>:
>
> Segue o meu arquivo de configuração:
>
> ******************************************************************************
> [root em fedora ppp]# cat chap-secrets
> # Secrets for authentication using CHAP
> # client server secret IP addresses
> jasonn * jasonn01 *
>
> ******************************************************************************
> [root em fedora ppp]# cat pap-secrets
> # Secrets for authentication using PAP
> # client server secret IP addresses
> jasonn * jasonn01 *
>
> ******************************************************************************
> [root em fedora ppp]# cat options.pptpd
>
> ###############################################################################
> # $Id: options.pptpd,v 1.9 2005/08/02 11:33:32 quozl Exp $
> #
> # Sample Poptop PPP options file /etc/ppp/options.pptpd
> # Options used by PPP when a connection arrives from a client.
> # This file is pointed to by /etc/pptpd.conf option keyword.
> # Changes are effective on the next connection. See "man pppd".
> #
> # You are expected to change this file to suit your system. As
> # packaged, it requires PPP 2.4.2 and the kernel MPPE module.
>
> ###############################################################################
>
>
> # Authentication
>
> # Name of the local system for authentication purposes
> # (must match the second field in /etc/ppp/chap-secrets entries)
> name pptpd
>
> # Strip the domain prefix from the username before authentication.
> # (applies if you use pppd with chapms-strip-domain patch)
> #chapms-strip-domain
>
>
> # Encryption
> # (There have been multiple versions of PPP with encryption support,
> # choose with of the following sections you will use.)
>
>
> # BSD licensed ppp-2.4.2 upstream with MPPE only, kernel module ppp_mppe.o
>
> # {{{
> 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
> # }}}
>
>
> # OpenSSL licensed ppp-2.4.1 fork with MPPE only, kernel module mppe.o
> # {{{
> #-chap
> #-chapms
> # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
> # Challenge Handshake Authentication Protocol, Version 2] authentication.
> #+chapms-v2
> # Require MPPE encryption
> # (note that MPPE requires the use of MSCHAP-V2 during authentication)
> #mppe-40 # enable either 40-bit or 128-bit, not both
> #mppe-128
> #mppe-stateless
> # }}}
>
>
> # 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.
> #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
>
>
> # 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
>
> # Disable Van Jacobson compression
> # (needed on some networks with Windows 9x/ME/XP clients, see posting to
> # poptop-server on 14th April 2005 by Pawel Pokrywka and followups,
> # http://marc.theaimsgroup.com/?t=111343175400006&r=1&w=2 )
> novj
> novjccomp
>
> # turn off logging to stderr, since this may be redirected to pptpd,
> # which may trigger a loopback
> nologfd
>
> # put plugins here
> # (putting them higher up may cause them to sent messages to the pty)
>
> ******************************************************************************
>
> Esse ae é minha vpn em produção, teste por favor ok?
>
> Outra coisa, lembre-se que no windows 98 é necessário instalar um suporte
> a vpn, de uma procurada na net ok?
>
> Abraços.
>
>
>
>
>
>
>
>
> 2006/12/5, Leonardo Korndorfer < leokorndorfer em gmail.com>:
> >
> > Pois bem...
> > Estou tendo um problema com um tunel pptp em um sistema embarado. Seguem
> > alguns pedaços de log:
> >
> > Servidor:
> > Dec 5 09:05:48 Digistar daemon.err pppd[12475]: Received bad
> > configure-ack: 1a 04 78 00 18 04 78 00
> > Dec 5 09:05:51 Digistar daemon.debug pppd[12475]: sent [CCP ConfReq
> > id=0x2 <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:51 Digistar daemon.debug pptpd[12474]: GRE: accepting
> > packet #24
> > Dec 5 09:05:51 Digistar daemon.debug pptpd[12474]: GRE: accepting
> > packet #25
> > Dec 5 09:05:51 Digistar daemon.debug pppd[12475]: rcvd [CCP ConfReq
> > id=0x9 <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:51 Digistar daemon.debug pppd[12475]: sent [CCP ConfAck
> > id=0x9 <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:51 Digistar daemon.debug pppd[12475]: rcvd [CCP ConfAck
> > id=0x2 <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:51 Digistar daemon.err pppd[12475]: Received bad
> > configure-ack: 1a 04 78 00 18 04 78 00
> > Dec 5 09:05:52 Digistar syslog.info -- MARK --
> > Dec 5 09:05:54 Digistar daemon.debug pppd[12475]: sent [CCP ConfReq
> > id=0x2 <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:54 Digistar daemon.debug pptpd[12474]: GRE: accepting
> > packet #26
> > Dec 5 09:05:54 Digistar daemon.debug pptpd[12474]: GRE: accepting
> > packet #27
> > Dec 5 09:05:54 Digistar daemon.debug pppd[12475]: rcvd [CCP ConfReq
> > id=0xa <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:54 Digistar daemon.debug pppd[12475]: sent [CCP ConfAck
> > id=0xa <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:54 Digistar daemon.debug pppd[12475]: rcvd [CCP ConfAck
> > id=0x2 <deflate 15> <deflate(old#) 15>]
> > Dec 5 09:05:54 Digistar daemon.err pppd[12475]: Received bad
> > configure-ack: 1a 04 78 00 18 04 78 00
> > Dec 5 09:05:57 Digistar daemon.warn pppd[12475]: CCP: timeout sending
> > Config-Requests
> > Dec 5 09:06:25 Digistar daemon.debug pptpd[12474]: CTRL: Received PPTP
> > Control Message (type: 5)
> > Dec 5 09:06:25 Digistar daemon.debug pptpd[12474]: CTRL: Made a ECHO
> > RPLY packet
> > Dec 5 09:06:25 Digistar daemon.debug pptpd[12474]: CTRL: I wrote 20
> > bytes to the client.
> > Dec 5 09:06:25 Digistar daemon.debug pptpd[12474]: CTRL: Sent packet to
> > client
> > Dec 5 09:07:25 Digistar daemon.debug pptpd[12474]: CTRL: Sending ECHO
> > REQ id 1
> > Dec 5 09:07:25 Digistar daemon.debug pptpd[12474]: CTRL: Made a ECHO
> > REQ packet
> > Dec 5 09:07:25 Digistar daemon.debug pptpd[12474]: CTRL: I wrote 16
> > bytes to the client.
> > Dec 5 09:07:25 Digistar daemon.debug pptpd[12474]: CTRL: Sent packet to
> > client
> >
> >
> > Cliente:
> > Dec 5 12:01:14 eng-4 pptp[7083]: anon log[main: pptp.c:276]: The
> > synchronous pptp option is NOT activated
> > Dec 5 12:01:14 eng-4 pptp[7086]: anon log[ctrlp_rep:pptp_ctrl.c:251]:
> > Sent control packet type is 1 'Start-Control-Connection-Request'
> > Dec 5 12:01:14 eng-4 pptp[7086]: anon log[ctrlp_disp:pptp_ctrl.c:738]:
> > Received Start Control Connection Reply
> > Dec 5 12:01:14 eng-4 pptp[7086]: anon log[ctrlp_disp:pptp_ctrl.c:772]:
> > Client connection established.
> > Dec 5 12:01:15 eng-4 pptp[7086]: anon log[ctrlp_rep:pptp_ctrl.c:251]:
> > Sent control packet type is 7 'Outgoing-Call-Request'
> > Dec 5 12:01:15 eng-4 pptp[7086]: anon log[ctrlp_disp:pptp_ctrl.c:857]:
> > Received Outgoing Call Reply.
> > Dec 5 12:01:15 eng-4 pptp[7086]: anon log[ctrlp_disp:pptp_ctrl.c:896]:
> > Outgoing call established (call ID 0, peer's call ID 1408).
> > Dec 5 12:01:15 eng-4 pppd[7088]: pppd 2.4.3 started by root, uid 0
> > Dec 5 12:01:15 eng-4 pppd[7088]: Using interface ppp0
> > Dec 5 12:01:15 eng-4 pppd[7088]: Connect: ppp0 <--> /dev/pts/5
> > Dec 5 12:01:15 eng-4 pppd[7088]: Warning - secret file
> > /etc/ppp/pap-secrets has world and/or group access
> > Dec 5 12:01:17 eng-4 pppd[7088]: Warning - secret file
> > /etc/ppp/pap-secrets has world and/or group access
> > Dec 5 12:01:17 eng-4 pppd[7088]: Remote message: Login ok
> > Dec 5 12:01:17 eng-4 pppd[7088]: PAP authentication succeeded
> > Dec 5 12:01:17 eng-4 kernel: PPP Deflate Compression module registered
> > Dec 5 12:01:17 eng-4 pppd[7088]: Deflate (15) compression enabled
> > Dec 5 12:01:17 eng-4 pppd[7088]: local IP address 192.168.10.51
> > Dec 5 12:01:17 eng-4 pppd[7088]: remote IP address 192.168.10.1
> > Dec 5 12:01:20 eng-4 pppd[7088]: Deflate (15) compression enabled
> >
> > Este é o pedaço de codigo onde o erro é gerado.
> > if( !(f->callbacks->ackci? (*f->callbacks->ackci)(f, inp, len):
> > (len == 0)) ){
> > /* Ack is bad - ignore it */
> > error("Received bad configure-ack: %P", inp, len);
> > return;
> > }
> >
> >
> > Eu estou com uma grande tendencia a acreditar que nao é bug no codigo.
> > Meus arquivos de configuraçao tambem acredito que nao tenham problemas.
> > Ele fica recebendo esses "bad configure-ack" desde o pacote #1.
> >
> > Interessante, nao?
> >
> > Se alguem tiver alguma ideia sera bem vinda.
> >
> >
> >
> >
> > --
> > Leonardo Korndorfer
> > x50/x6F/x72/x20/x66/x61/x76/x6F/x72/x21/x20/x4E/x61/x6F/x20/x61/x63/x72/x65/x64/x69/x74/x6F/x20/x71/x75/x65/x20/x74/x75/x20/x74/x65/x20/x64/x65/x73/x74/x65/x20/x6F/x20/x74/x72/x61/x62/x61/x6C/x68/x6F/x20/x64/x65/x20/x74/x72/x61/x64/x75/x7A/x69/x72/x20/x69/x73/x73/x6F/x21/x20
> >
> >
> > alt.not.root.coffe.coffe.coffe
> >
> > A monk asked Joshu, "Does a dog have the Buddha nature?
> > Joshu retorted, "Mu!"
> >
> > MSN: leokorndorfer em hotmail.com
> > ICQ: 102788426
> > Slack + Gentoo
> > --
> > Fedora-users-br mailing list
> > Fedora-users-br em redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-users-br
> >
> >
> >
>
>
> --
> Cristiano Furtado dos Santos
> Administrador de Sistemas Linux
> http://jasonnfedora.no-ip.org/repositorio
> http://fedora.org.br
--
Cristiano Furtado dos Santos
Administrador de Sistemas Linux
http://jasonnfedora.no-ip.org/repositorio
http://fedora.org.br
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listman.redhat.com/archives/fedora-users-br/attachments/20061205/2407e6d4/attachment.htm>
Mais detalhes sobre a lista de discussão Fedora-users-br