>Скорее это не фаерволл, а сам сервер....
>Вот логи pptpd при подключении windows клиента:
>
>Feb 4 17:18:24 stud pptpd[1129]: CTRL: PTY read or GRE write
>failed (pty,gre)=(8,9)
>Feb 4 17:18:51 stud pppd[1138]: In file /etc/ppp/options.pptpd: unrecognized option 'plugin'
>
>Feb 4 17:18:51 stud pppd[1138]: In file /etc/ppp/options.pptpd: unrecognized option 'plugin'
>
>Feb 4 17:18:51 stud pptpd[1137]: GRE: read(fd=8,buffer=804db80,len=8196) from PTY failed: status
>
>= 0 error = No error
>Feb 4 17:18:51 stud pptpd[1137]: GRE: read(fd=8,buffer=804db80,len=8196) from PTY failed: status
>
>= 0 error = No error
>Feb 4 17:18:51 stud pptpd[1137]: CTRL: PTY read or GRE write
>failed (pty,gre)=(8,9)
>Feb 4 17:18:51 stud pptpd[1137]: CTRL: PTY read or GRE write
>failed (pty,gre)=(8,9)
>Feb 4 17:20:23 stud pppd[1149]: peer authentication required but no suitable
>secret(s) found
>Feb 4 17:20:23 stud pppd[1149]: peer authentication required but no suitable
>secret(s) found
>Feb 4 17:20:23 stud pppd[1149]: for authenticating any peer to us
>(pptp)
>Feb 4 17:20:23 stud pppd[1149]: for authenticating any peer to us
>(pptp)
>
>
>Сначала ругался на опции в options.pptpd, на такие как
>+pap
>+mschap
>Исправил на
>require-mschap-v2
>require-mppe-128
>Всё равно на них ругается,плюс на
>plugin radius.so
>тоже ругается....
>
>Вот мой options.pptpd c исправлениями, оставил только pap аутентификацию:
>
>name pptp
>ipparam pptp
>lock
>debug
>mtu 1490
>mru 1490
>proxyarp
>nodefaultroute
>require-pap
>ipcp-accept-local
>ipcp-accept-remote
>lcp-echo-failure 3
>lcp-echo-interval 30
>ms-dns 192.168.55.3
>nobsdcomp
>
>
>Не понятно, что это
>CTRL: PTY read or GRE write failed (pty,gre)=(8,9) (в логах)
>
>Что делать?
work in progress - not sure if this is all right yet...
install kernel-source rpm
install ppp-2.4.1-7 rpm
This is a weird one. I think you really need a ppp with the microsoft stuff built in. Use this one: ppp-2.4.2 rpm or this one: ppp 2.4.1-mppe. I used the latter.
ppp version 2.4.2 and later includes the microsoft auth/encryption parts by default.
The failure if you forget to install a good ppp is something like this in your syslog:
pptpd[2418]: GRE: read(fd=5,buffer=804d720,len=8196) from PTY failed: status = -1 error = Input/output error
pptpd[2418]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
key troubleshooting tip: start pptpd with the -f switch to keep it in the foreground, then try making your vpn connection. You will see messages from pppd like "unknown protocol chapms-v2". That seems to be the only way to catch this screwup.
install pptp-1.1.3-4 rpm from www.poptop.org
download kernelmod-0.6.tar.gz from http://www.poptop.org
run kernelmod to build a patched ppp module w/ ms encryption stuff:
# kernelmod.sh -k /usr/src/linux-2.4
modprobe new ppp_generic, ppp_async, and ppp_mppe modules to test them, they should load w/o errors.
Add the following to /etc/modules:
alias ppp ppp_generic
alias char-major-108 ppp_generic
alias tty-ldisc-3 ppp_async
alias tty-ldisc-14 ppp_synctty
alias ppp-compress-18 ppp_mppe
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
alias net-pf-47 ip_gre
troubleshooting tip: I found that one VPN I set up worked fine when the modules were loaded by hand. However, it failed if you rebooted the system and it tried to load them automatically. The problem was that the kernelmod script puts something in there that turns ppp off. Remove the following:
alias char-major-108 off
at the bottom. This actually prevented ppp from loading. The log error messages were the same as for the case of having an incorrect version of ppp installed - GRE read from PTY failed. That message generally just means that pppd failed to load. Running pptpd with the -f switch will quickly pinpoint these sorts of problems.
edit /etc/pptpd.conf:
option /etc/ppp/options.pptpd
debug
localip 192.168.14.100
remoteip 192.168.14.101-120
edit /etc/ppp/options.pppd:
lock
debug
nobsdcomp
proxyarp
chapms-strip-domain patch
chapms-strip-domain
-chap
-chapms
+chapms-v2
mppe-40
mppe-128
mppe-stateless
ms-wins 192.168.14.1
ms-dns 192.168.14.1
note the ms-wins and ms-dns entries send the wins and dns server config info to windows client systems, so you don't have to type it in manually on each client.
edit /etc/ppp/chap-secrets:
# client server secret IP addresses
user1 * password 192.168.14.101
user2 * password 192.168.14.102
Add firewall rules to allow gre and pptp control traffic for the vpn:
iptables -t filter -P FORWARD DROP
iptables -A OUTPUT -p 47 -j ACCEPT
iptables -A INPUT -p 47 -j ACCEPT
iptables -A FORWARD -s 192.168.14.0/24 -d 192.168.14.0/24 -j ACCECPT
iptables -A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
I had to add the following, not sure if it's just due to my specific setup:
iptables -A INPUT -s 192.168.14.0/24 -d 192.168.14.0/24 -j ACCEPT
Save firewall rules (not sure if this is right)
# /sbin/iptables-save >/etc/sysconfig/iptables
Start pptp server
# service pptpd start
Configure your windows client by reading these instructions.
I think you have to disable NetBEUI on the Windows client machine, otherwise it will report "error 733". TCP/IP still works fine, this is just a cosmetic issue. You also need to go into the advanced properties for the vpn on the client and change the TCP/IP settings - go to the WINS tab and put the server address in for WINS server (in this case 192.168.14.100). This allows you to reference remote systems by name instead of IP address.
This link looks like a great RedHat 8.0 pptpd howto doc.
Also, add 'ppp' to the pkgSkipList in /etc/sysconfig/rhn/up2date, so up2date won't mess up your ppp.
another troubleshooting tip: I found that on one client, vpn performance was terrible. You could perform actions like make an ssh connection over the vpn, but things like copying files across the vpn would time out. The problem was tcp fragmentation. The default mru (maximum receive unit) on the ppp connection was 1500. For some reason, this was too big for the particular network the vpn was on. The result was massive fragmentation and really, really poor performance. I edited /etc/ppp/options on the pptp server and added the following:
mru 900
mtu 900
and performance immediately improved to the point of usability. I use 900 because it works, Jeff Jones found info indicating 552 might be the right number. Moral of the story: if the vpn works but large file copies stink, drop your mru to avoid fragmentation (if you drop it too far, you won't be able to connect!).
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
(??) on
04-Фев-05, 10:37 (MSK)
