Set up VPN Server _ PPTP configuration and troubleshooting in CentOS6

Set up VPN Server _ PPTP configuration and troubleshooting in CentOS6

1. Pre-configuration operations
Previously, due to the redecoration of the company, the company's network was redeployed. The network is divided into multiple VLANs. The public network is also divided into several IP outlets. Because I am not a windows professional. I am not very familiar with the network, so I am not very familiar with it (now I am studying network knowledge ). After the company's network is deployed, the VPN service is required. This is a security concern. However, the specific configuration of the network is operated by the device provider, and the routing is specific to how it is implemented, which cannot be communicated in a timely manner. At that time, the VPN Server was not configured properly. It was also depressing, and finally it was implemented on hardware devices.

After this period of time, I decided to study the problem at the time.
So I reconfigured it again. The installation environment is CentOS 6.2 64-bit. Some development package groups are fully installed. Pptp these are all installed by yum using the epel Source:
1 # yum-y install dkms ppp pptpd

After installing these three packages, check whether the mppe module is loaded.
[Root @ localhost ppp] # lsmod | grep mppe
Ppp_mppe 6404 0
Ppp_generic 25379 2 ppp_async, ppp_mppe
# If no load is available, run the command to load
# Modprobe ppp-compress-18
# Lsmod | grep mppe # view again

After the above loading is complete, enable the kernel forwarding function:
# Grep "^ [^ #]"/etc/sysctl. conf
Net. ipv4.ip _ forward = 1 # change the value to 1.
Net. ipv4.conf. default. rp_filter = 1
Net. ipv4.conf. default. accept_source_route = 0
Kernel. sysrq = 0
Kernel. core_uses_pid = 1
Net. ipv4.tcp _ syncookies = 1
Net. bridge. bridge-nf-call-ip6tables = 0
Net. bridge. bridge-nf-call-iptables = 0
Net. bridge. bridge-nf-call-arptables = 0
Kernel. msgmnb = 65536
Kernel. msgmax = 65536
Kernel. shmmax = 68719476736
Kernel. shmall = 4294967296

# Execute the following command to take effect
# Sysctl-p

Ii. Configure PPTP
1. Install pptp to generate the following files:
# Rpm-ql pptpd
/Etc/ppp/options.ppt pd # configuration file
/Etc/pptpd. conf # configuration file
/Etc/rc. d/init. d/pptpd # Start the script
/Etc/sysconfig/pptpd # script configuration file
/Usr/bin/vpnstats. pl
/Usr/bin/vpnuser
/Usr/lib64/pptpd
/Usr/lib64/pptpd/pptpd-logwtmp.so
/Usr/sbin/bcrelay
/Usr/sbin/pptp-portslave
/Usr/sbin/pptpctrl
/Usr/sbin/pptpd
......

# Install the following files generated by ppp
# Rpm-ql ppp
/Etc/logrotate. d/ppp
/Etc/pam. d/ppp
/Etc/ppp
/Etc/ppp/chap-secrets # This is the pptpd account authentication file.
/Etc/ppp/options
/Etc/ppp/pap-secrets
.......

2. With the above, we can directly configure:
1. Configure pptpd. conf
# Grep "^ [^ #]"/etc/pptpd. conf
Option/etc/ppp/options.ppt pd
Localip 192.168.0.1
Remoteip 192.168.0.2-20

2. Configure options.ppt pd
# Grep "^ [^ #]"/etc/ppp/options.ppt pd
Name pptpd
Refuse-pap
Refuse-chap
Refuse-mschap
Require-mschap-v2
Require-mppe-128
Proxyarp
Debug # These two options are used to debug and enable troubleshooting.
Dump #
Lock
Nobsdcomp
Novj
Novjccomp
Nologfd
Idle 2592000
Ms-dns 114.114.114.114 # DNS
Ms-dns 8.8.8.8

3. authenticated account
# Cat/etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# Client server secret IP addresses
Test pptpd test *

# The configuration is simple.
# Start the service
# Service pptpd start
# Ss-tunl | grep 1723
Tcp 0 3 *: 1723 *:*

3. Configure iptables to allow pptpd
# Cat/etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Wed Jan 21 11:25:45 2015
* Nat
: Prerouting accept [5:539]
: Postrouting accept [0: 0]
: Output accept [0: 0]
-A postrouting-s 192.168.0.0/24-o eth0-j SNAT -- to-source 10.95.10.105 # address conversion
COMMIT
# Completed on Wed Jan 21 11:25:45 2015
# Generated by iptables-save v1.4.7 on Wed Jan 21 11:25:45 2015
* Filter
: Input accept [0: 0]
: Forward accept [0: 0]
: Output accept [223: 27476]
-A input-m state -- state RELATED, ESTABLISHED-j ACCEPT
-A input-p icmp-j ACCEPT
-A input-I lo-j ACCEPT
-A input-p gre-j ACCEPT # port 47 is allowed
-A input-p tcp-m state -- state NEW-m tcp -- dport 22-j ACCEPT
-A input-p tcp-m state -- state NEW-m tcp -- dport 80-j ACCEPT
-A input-p tcp -- dport 1723-j ACCEPT # Allow port 1723
-A input-p tcp-m state -- state NEW-m tcp -- dport 3306-j ACCEPT
-A input-p tcp-m state -- state NEW-m tcp -- dport 9000-j ACCEPT
-A input-j REJECT -- reject-with icmp-host-prohibited
#-A forward-j REJECT -- reject-with icmp-host-prohibited
COMMIT
# Completed on Wed Jan 21 11:25:45 2015
# Because I use the Default policy, the default rule for non-compliance is DROP. In this case, the FORWARD chain needs to place the behavior ACCEPT. By default, all rules that do not comply with the rule are DROP.

Now you can test the connection in windows.

Iii. Connection and troubleshooting
After configuring the VPN connection in windows, you can obtain the IP address for the test connection, and QQ and other services are normal. However, other web pages except Baidu can be accessed. Baidu domain names alone cannot be accessed. Then the second problem occurs, that is, the VPN is automatically disconnected after the end time of the VPN connection. The following error is reported repeatedly when the connection is reconnected after disconnection:
Jan 22 14:04:24 localhost pppd [22168]: nobsdcomp #011 #011 # (from/etc/ppp/options.ppt pd)
Jan 22 14:04:24 localhost pppd [22168]: require-mppe-128 #011 #011 # (from/etc/ppp/options.ppt pd)
Jan 22 14:04:24 localhost pppd [22168]: pppd 2.4.5 started by root, uid 0
Jan 22 14:04:24 localhost pppd [22168]: Using interface ppp0
Jan 22 14:04:24 localhost pppd [22168]: Connect: ppp0 <-->/dev/pts/3
Jan 22 14:04:24 localhost pptpd [22167]: GRE: read (fd = 7, buffer = 60a400, len = 8260) from network failed: status =-1 error = Protocol not available
Jan 22 14:04:24 localhost pptpd [22167]: CTRL: GRE read or PTY write failed (gre, pty) =)
Jan 22 14:04:24 localhost pppd [1, 22168]: Modem hangup
Jan 22 14:04:24 localhost pppd [22168]: Connection terminated.
Jan 22 14:04:25 localhost pppd [22168]: Exit.
Jan 22 14:04:25 localhost pptpd [22167]: CTRL: Client 10.95.11.7 control connection finished
Jan 22 14:04:25 localhost pptpd [22176]: CTRL: Client 10.95.11.7 control connection started
Jan 22 14:04:25 localhost pptpd [22176]: CTRL: Starting call (launching pppd, opening GRE)
Jan 22 14:04:25 localhost pppd [22177]: pppd options in effect:
#......
# Some debug information in the middle
#......
Jan 22 14:04:25 localhost pppd [22177]: 192.168.0.1: 192.168.0.2 #011 #011 # (from command line)
Jan 22 14:04:25 localhost pppd [22177]: nobsdcomp #011 #011 # (from/etc/ppp/options.ppt pd)
Jan 22 14:04:25 localhost pppd [22177]: require-mppe-128 #011 #011 # (from/etc/ppp/options.ppt pd)
Jan 22 14:04:25 localhost pppd [22177]: pppd 2.4.5 started by root, uid 0
Jan 22 14:04:25 localhost pppd [22177]: Using interface ppp0
Jan 22 14:04:25 localhost pppd [22177]: Connect: ppp0 <-->/dev/pts/3
Jan 22 14:04:25 localhost pptpd [22176]: GRE: read (fd = 7, buffer = 60a400, len = 8260) from network failed: status =-1 error = Protocol not available
Jan 22 14:04:25 localhost pptpd [22176]: CTRL: GRE read or PTY write failed (gre, pty) =)
Jan 22 14:04:25 localhost pppd [1, 22177]: Modem hangup
Jan 22 14:04:25 localhost pppd [22177]: Connection terminated.
Jan 22 14:04:25 localhost pppd [22177]: Exit.

According to the prompt, It is a GRE problem, but the above has opened the GRE port. So baidu and google have been talking about version problems for a long time, and some about Kernel patches (not tested), iptables, and gre kernel modules. I couldn't do it after I tried it one by one, so I asked the gods. In the past, it may be about the MTU size. After the connection, check the MTU of ppp0 and find that the MTU of ppp0 is 1396, which is indeed different from that of eth0 and gre. Then the MTU test is changed dynamically:
1. View mtu:
# Ip a | grep mtu
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
2: eth0: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
254: gre0: <NOARP> mtu 1472 qdisc noop state DOWN
# You can view the mtu value of all NICs. Here, we can see that eth0 is 1500, and gre0 is 1472.

2. view the MTU of a NIC. You can view the MTU of ppp0 only after connecting to the VPN.
# Cat/sys/class/net/ppp0/mtu
#
# Change its value
# Echo "1472">/sys/class/net/ppp0/mtu
# Access Baidu immediately after the test is completed. It seems that this is really the problem. Add it to the connection and set its value automatically.

3. Configure the VPN connection to automatically set the MTU Value
#1. I have mentioned it on the Internet in the options.ppt pd configuration file, but it still does not take effect in the test writing, but I also wrote it.
# Add the following content to DNS:
Ms-dns 114.114.114.114
Ms-dns 8.8.8.8
Mtu 1472
Mru 1472

#2. Write to/etc/ppp/ip-up
# Vim/etc/ppp/ip-up
#! /Bin/bash
# This file shoshould not be modified -- make local changes
#/Etc/ppp/ip-up.local instead

PATH =/sbin:/usr/sbin:/bin:/usr/bin
Export PATH

LOGDEVICE = $6
REALDEVICE = $1

[-F/etc/sysconfig/network-scripts/ifcfg-$ {LOGDEVICE}] &/etc/sysconfig/network-scripts/ifup-post -- realdevice $ {REALDEVICE} ifcfg -$ {LOGDEVICE}

/Etc/ppp/ip-up.ipv6to4 $ {LOGDEVICE}

[-X/etc/ppp/ip-up.local] & amp;/etc/ppp/ip-up.local "$ @"

/Sbin/ifconfig ppp0 mtu 1472 # Add it here
Exit 0

# Disconnect the VPN and test the connection again. Everything is normal.

The tests are normal till now. If there are still problems, we will add more ......

Install an open-source VPN Server on CentOS 7

Use PPTP to build a VPN

PPTPD for RHEL5.4 VPN service configuration

The problem of configuring NAT forwarding in PPTPd on Ubuntu VPS

Install pptp vpn under CentOS

Linux VPN (PPTPD) + Windows AD unified authentication