A Point-To-Point Tunneling Protocol (PPTP) allows you to implement your own VPN very quickly, and is compatible with most mobile devices. Even though PPTP is less secure than OpenVPN, it is also faster and uses less CPU resources.
Set up pptp vpn
- Select one server to be responsible for handling out IPs to others and authenticating all of your servers into your VPN. This will become your PPTP Server.
- edit /etc/pptpd.conf (for more on it, use "man pptpd.conf") and add the following lines:
Where localip is IP address of your server and remoteip are IPs that will be assigned to clients that connect to it.
- Adding users and passwords. Simply add them to /etc/ppp/chap-secrets. Client is the username, server is type of service - pptpd for our example, secret is the password, and IP addresses specifies which IP address may authenticate. By setting '*' in IP addresses field, you specify that you would accept username/password pair for any IP.
- Add DNS servers to /etc/ppp/pptpd-options ("man pppd" for commands help) to provide primary and secondary DNS's to windows clients
- Now you can start PPTP daemon:
service pptpd restart.
- It is important to enable IP forwarding on your PPTP server. This will allow you to forward packets between public IP and private IPs that you setup with PPTP. Simply edit /etc/sysctl.conf and add the following line if it doesn't exist there already:
net.ipv4.ip_forward = 1. To make changes active, run
- Create a NAT rule for iptables:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE && iptables-save
- If you would also like your PPTP clients to talk to each other, add the following iptables rules: (Arch wiki ref.)
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -I INPUT -s 10.0.0.0/8 -i ppp0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
# The following from Arch Wiki.
# Accept all packets via ppp* interfaces (for example, ppp0)
iptables -A INPUT -i ppp+ -j ACCEPT
iptables -A OUTPUT -o ppp+ -j ACCEPT
# Accept incoming connections to port 1723 (PPTP)
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
# Accept GRE packets
iptables -A INPUT -p 47 -j ACCEPT
iptables -A OUTPUT -p 47 -j ACCEPT
# Enable IP forwarding
iptables -F FORWARD
iptables -A FORWARD -j ACCEPT
# Enable NAT for eth0 и ppp* interfaces
iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
iptables -A POSTROUTING -t nat -o ppp+ -j MASQUERADE
sudo iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -s 192.168.200.2-100 -j TCPMSS --clamp-mss-to-pmtu
Now your PPTP server also acts as a router.
sudo iptables -t nat -A POSTROUTING -s 192.168.200.0/24 ! -d 192.168.200.0/24 -j SNAT -to-source 188.8.131.52
Your interface ppp0 should come up on PPTP client. Now you can ping your PPTP server and any other clients that are connected to this network.
- On your client servers,
# Install PPTP client:
yum -y install pptp
# Add necessary Kernel module
- Create a new file /etc/ppp/peers/pptpserver and add the following lines, replacing name and password with your own values:
pty "pptp 184.108.40.206 --nolaunchpppd"
- called our file pptpserver:
pppd call pptpserver.
- On your PPTP client, setup routing to your private network via ppp0 interface:
ip route add 10.0.0.0/8 dev ppp0.
Set up CA (Certificate Authority)
Establish PKI (public key infrastructure), which consists of
Both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).
- a separate certificate (public key) and private key for the server and each client
- a master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates.
For PKI management, we will use easy-rsa, a set of scripts which is bundled with OpenVPN 2.2.x and earlier. If you're using OpenVPN 2.3.x, you need to download easy-rsa separately from here.
# On CA:
# On the system that is requesting a certificate
./easyrsa gen-req EntityName
# Req file will be in pki/reqs, and key in pki/private.
# Transport the request (.req file) to the CA system and import it.
./easyrsa import-req /tmp/path/to/import.req EntityName
# CA sign the request as the correct type. This example uses a client type:
./easyrsa sign-req client EntityName
# Other types are: server, ca. See easyrsa3/x509-types/.
# Signed crt will be in pki/issued.
# Transport the newly signed certificate to the requesting entity. This entity may also need the CA cert.
# The entity now has its own keypair, and signed cert, and the CA.
After initializing a PKI, any entity can create DH params that needs them. This is normally only used by a TLS server. While the CA PKI can generate this, it makes more sense to do it on the server itself to avoid the need to send the files to another system after generation.
DH params can be generated with:
# Usually generated as pki/dh.pem.
Showing details of requests or certs
To show the details of a request or certificate by referencing the short EntityName, use one of the following commands. It is an error to call these without a matching file.
./easyrsa show-req EntityName
./easyrsa show-cert EntityName
Changing private key passphrases
RSA and EC private keys can be re-encrypted so a new passphrase can be supplied with one of the following commands depending on the key type:
./easyrsa set-rsa-pass EntityName
./easyrsa set-ec-pass EntityName
The example config of openvpn is under /usr/share/doc/openvpn/sample/sample-config-files. server.conf will be a good start.
- Edit the ca, cert, key, and dh parameters to point to the files you generated in the PKI section above.
- If you are using Ethernet bridging, you must use server-bridge and dev tap instead of server and dev tun. A TAP device is a virtual ethernet adapter, while a TUN device is a virtual point-to-point IP link.
- If you want to use a virtual IP address range other than 10.8.0.0/24, you should modify the server directive.
- Uncomment out the client-to-client directive if you would like connecting clients to be able to reach each other over the VPN. By default, clients will only be able to reach the server.
- If you are using Linux, BSD, or a Unix-like OS, you can improve security by uncommenting out the user nobody and group nobody directives.
- Edit the ca, cert, and key parameters to point to the files you generated in the PKI section above. Note that each client should have its own cert/key pair. Only the cafile is universal across the OpenVPN server and all clients.
- Edit the remotedirective to point to the hostname/IP address and port number of the OpenVPN server.
- Finally, ensure that the client configuration file is consistent with the directives used in the server configuration. The major thing to check for is that the dev (tun or tap) and proto (udp or tcp) directives are consistent. Also make sure that comp-lzo and fragment, if used, are present in both client and server config files.
Bridging vs Routing
In short, routing is more efficient and scalable, allows for better tuning of MTU. But routing doesn't support broadcasts traverse the VPN.
Log in ppp/pptpd
执行：servie syslog restart
sudo iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -j SNAT --to-source 172.31.14.215
sudo iptables -t nat -A POSTROUTING -p all -o eth0 -s 172.16.0.0/24 -j SNAT -to $ETH0IP
iptables -t nat -I POSTROUTING 1 -j SNAT -s 192.168.10.0/24 --to-destination 192.168.10.108
iptables -t nat -I POSTROUTING 1 -j SNAT -s 192.168.200.101-200 --to-destination 172.31.14.215