Take out the local server to the network using another external server
Good afternoon, habrovchane! The story is this: for as long as I can remember, there was always some server at home that really wanted to bring our favorite Internet to us.
“So what's so complicated? Almost any provider provides a static white IP for a small fee! ”, Say you and you will be absolutely right. But it is paid, and in general I wanted to try something more original. The main problem with accessing my server is NAT. If suddenly someone does not know what it is, below left an explanation from Wikipedia.
If in your own words, it is an external router that allows you to send requests to the Internet, but does not allow you to receive them. You get the answer from the Internet, which means that all is not lost. I remembered the old program LogMeIn Hamach, it also allowed us to exchange data packets, while ALL clients were in a network closed by NAT. And what if you implement something like this:
What is drawn here? OPI is my Orange Pi PC, which acts as a server, NAT is, as you can guess, my operator’s router (it can be more than one, but it doesn’t change the essence), KVM is the external server of a friend, CLI is a client. Perhaps you have a question: "For what reason could you not just throw all your services on the server of a friend?". The answer is simple: I do not want. In the end, and disk space would have to use someone else's, but it does not suit me. Not to mention the increasing complexity of server administration and maintenance ...
OPI connects to KVM and a VPN channel is established between them. And then the client connects to KVM, and this machine in turn sends the request via VPN to OPI.
Why KVM? Comrade server is a regular VDS (Virtual Dedicated Server). This is usually either KVM (Kernel-based Virtual Machine) or OVZ (OpenVZ). OVZ is not suitable in our case, since iptables doesn’t work there, and the whole thing is very strange.
In theory, it all sounds great, but now you need to put it into practice. Need to choose a protocol for VPN. Initially, I was prone to OpenVPN, but after a series of trials, errors, failures, I came to the conclusion that this is not the best protocol for such actions. In the end, it uses sophisticated encryption algorithms, which also will not weakly load the OPI processor and the external server, so my choice fell on PPTP.
First you need to install the PPTP daemon on the server itself:
The next step is to configure it. Open its config file /etc/pptpd.conf and specify the IP address of the server and the range of IP addresses of clients:
Now you need to create VPN accounts for clients. Their list is in the file / etc / ppp / chap-secrets
We created an orange client with the password pass123 and the IP address 10.0.0.100. If instead of the IP address you specify * , the client will receive any free IP address from the range specified in remoteip. We obviously do not need a random house. Now just a couple of touches with the PPTPD settings. Add DNS servers in the / etc / ppp / pptpd-options file
And reload PPTPD:
A very important step is the inclusion of IP forwarding. This will allow you to forward packets between public IP and private IP that you have configured using PPTP. Edit the /etc/sysctl.conf file and uncomment the line:
Great, now you can start conjuring with ipatables. First, let's find out the name of our network interface:
I have it called ens3 . However, most often it is called eth0 .
Create an iptables rule:
Do not forget to replace the interface with your own. If you plan to use VPN for your needs in the future, you can write down the rules so that the VPN network clients can interact:
ppp0 is a virtual network interface.
Next you need to connect our first client - Orange PI. At this moment I sat down for a long time, since all the instructions on the Internet said the same thing, and they all did not work.
First, install the PPTP client on Orange PI:
Create a file / etc / ppp / peers / pptpserver and enter the following:
Do not forget to change the server's IP address and other data to your own.
Next, we comment out all the lines in the / etc / ppp / options file by inserting the # character
The /etc/ppp/options.pptp file should be converted to the following form:
And finally, we try to connect:
If everything worked out, try to look at our virtual interface:
Let's try to ping Orange PI from an external server:
Works!
Now just a little: redirect packets from the server to the Orange PI. Here the methods may be different, but since port 80 and 443 are not used at all on this server, we can simply ask the server to redirect all packages for these ports to OPI
Remember to change the IP addresses to your own. Check that everything works:
Great! The goal is reached!
But suddenly, in the building where the Orange PI is located, the lights are turned off and ... After the restart, no one can again access our orange. Why? Because by itself Orange PI will not connect to VPN. Let's write a simple bash script that will be looped through, checking if the connection is established:
Now add it to autoload. In the file /etc/rc.local we enter the line with the location of the script. In my case it is:
Do not forget to give the script execution rights:
An attentive user may have noticed that there are echo commands in the script, but they have nowhere to draw a conclusion! Initially, I planned to do it in the form of a service, so that the withdrawal would conveniently drop there, but in the end it was corny, it works the same. By the way, does it work? Reboot our orange and see that the ppp0 interface has successfully risen, and our services are accessible from the Internet. The goal is achieved, gentlemen!
All this is done solely for entertainment and educational purposes. It almost does not carry any practical benefits, since we still need an external server, and the load does not double its network, because it has to accept packets and immediately transfer them further. However, this method has advantages, since the real IP of our server will be hidden, this external server will be able to better withstand DDoS attacks, and will also be able to display a technical work page to restless users if Orange PI is not available. Of course, it will still have to seriously try to do this, but isn't it all pleasure in the path to the goal, comrades?
1. How to configure VPN using PPTP
2. Port forwarding through NAT
“So what's so complicated? Almost any provider provides a static white IP for a small fee! ”, Say you and you will be absolutely right. But it is paid, and in general I wanted to try something more original. The main problem with accessing my server is NAT. If suddenly someone does not know what it is, below left an explanation from Wikipedia.
NAT
NAT (from the English. Network Address Translation - "Network Address Translation") is a mechanism in TCP / IP networks that allows you to convert the IP addresses of transit packets. Also known as IP Masquerading, Network Masquerading and Native Address Translation.
Address translation using the NAT method can be performed by almost any routing device — a router, an access server, or a firewall. The most popular is SNAT, the essence of the mechanism of which is to replace the source address (eng. Source) when passing a packet in one direction and reverse replacing the destination address (eng. Destination) in the reply packet. Along with the source / destination addresses, the port numbers of the source and destination ports can also be replaced.
')
Taking the packet from the local computer, the router looks at the destination IP address. If it is a local address, the packet is forwarded to another local computer. If not, then the packet must be sent out to the Internet. But the return address in the package indicates the local address of the computer, which will not be available from the Internet. Therefore, the router “on the fly” transmits (replaces) the return IP address of the packet to its external (visible from the Internet) IP address and changes the port number (to distinguish response packets addressed to different local computers). The combination required for the inverse substitution is kept by the router in its temporary table. Some time after the client and server finish exchanging packets, the router will erase the entry for the nth port in the table for the statute of limitations.
Address translation using the NAT method can be performed by almost any routing device — a router, an access server, or a firewall. The most popular is SNAT, the essence of the mechanism of which is to replace the source address (eng. Source) when passing a packet in one direction and reverse replacing the destination address (eng. Destination) in the reply packet. Along with the source / destination addresses, the port numbers of the source and destination ports can also be replaced.
')
Taking the packet from the local computer, the router looks at the destination IP address. If it is a local address, the packet is forwarded to another local computer. If not, then the packet must be sent out to the Internet. But the return address in the package indicates the local address of the computer, which will not be available from the Internet. Therefore, the router “on the fly” transmits (replaces) the return IP address of the packet to its external (visible from the Internet) IP address and changes the port number (to distinguish response packets addressed to different local computers). The combination required for the inverse substitution is kept by the router in its temporary table. Some time after the client and server finish exchanging packets, the router will erase the entry for the nth port in the table for the statute of limitations.
If in your own words, it is an external router that allows you to send requests to the Internet, but does not allow you to receive them. You get the answer from the Internet, which means that all is not lost. I remembered the old program LogMeIn Hamach, it also allowed us to exchange data packets, while ALL clients were in a network closed by NAT. And what if you implement something like this:
What is drawn here? OPI is my Orange Pi PC, which acts as a server, NAT is, as you can guess, my operator’s router (it can be more than one, but it doesn’t change the essence), KVM is the external server of a friend, CLI is a client. Perhaps you have a question: "For what reason could you not just throw all your services on the server of a friend?". The answer is simple: I do not want. In the end, and disk space would have to use someone else's, but it does not suit me. Not to mention the increasing complexity of server administration and maintenance ...
OPI connects to KVM and a VPN channel is established between them. And then the client connects to KVM, and this machine in turn sends the request via VPN to OPI.
Why KVM? Comrade server is a regular VDS (Virtual Dedicated Server). This is usually either KVM (Kernel-based Virtual Machine) or OVZ (OpenVZ). OVZ is not suitable in our case, since iptables doesn’t work there, and the whole thing is very strange.
Server Tuning
In theory, it all sounds great, but now you need to put it into practice. Need to choose a protocol for VPN. Initially, I was prone to OpenVPN, but after a series of trials, errors, failures, I came to the conclusion that this is not the best protocol for such actions. In the end, it uses sophisticated encryption algorithms, which also will not weakly load the OPI processor and the external server, so my choice fell on PPTP.
First you need to install the PPTP daemon on the server itself:
apt install pptpd The next step is to configure it. Open its config file /etc/pptpd.conf and specify the IP address of the server and the range of IP addresses of clients:
localip 10.0.0.1 remoteip 10.0.0.100-200 Now you need to create VPN accounts for clients. Their list is in the file / etc / ppp / chap-secrets
# client server secret IP addresses orange pptpd pass123 10.0.0.100 We created an orange client with the password pass123 and the IP address 10.0.0.100. If instead of the IP address you specify * , the client will receive any free IP address from the range specified in remoteip. We obviously do not need a random house. Now just a couple of touches with the PPTPD settings. Add DNS servers in the / etc / ppp / pptpd-options file
ms-dns 8.8.8.8 ms-dns 8.8.4.4 And reload PPTPD:
service pptpd restart A very important step is the inclusion of IP forwarding. This will allow you to forward packets between public IP and private IP that you have configured using PPTP. Edit the /etc/sysctl.conf file and uncomment the line:
net.ipv4.ip_forward = 1 Great, now you can start conjuring with ipatables. First, let's find out the name of our network interface:
~$ ifconfig ens3 Link encap:Ethernet HWaddr 52:54:00:f8:0c:4a inet addr:31.148.99.234 Bcast:31.148.99.255 Mask:255.255.255.0 inet6 addr: fe80::5054:ff:fef8:c4a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8808733 errors:0 dropped:0 overruns:0 frame:0 TX packets:3300625 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3511383831 (3.5 GB) TX bytes:3245380453 (3.2 GB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:216 errors:0 dropped:0 overruns:0 frame:0 TX packets:216 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:16618 (16.6 KB) TX bytes:16618 (16.6 KB) I have it called ens3 . However, most often it is called eth0 .
Create an iptables rule:
iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE && iptables-save Do not forget to replace the interface with your own. If you plan to use VPN for your needs in the future, you can write down the rules so that the VPN network clients can interact:
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE iptables -I INPUT -s 10.0.0.0/8 -i ppp0 -j ACCEPT iptables --append FORWARD --in-interface ens3 -j ACCEPT ppp0 is a virtual network interface.
Setting up a local server
Next you need to connect our first client - Orange PI. At this moment I sat down for a long time, since all the instructions on the Internet said the same thing, and they all did not work.
First, install the PPTP client on Orange PI:
apt install pptp-linux Create a file / etc / ppp / peers / pptpserver and enter the following:
pty "pptp 31.148.99.234 --nolaunchpppd" name orange password pass123 remotename PPTP require-mppe-128 Do not forget to change the server's IP address and other data to your own.
Next, we comment out all the lines in the / etc / ppp / options file by inserting the # character
The /etc/ppp/options.pptp file should be converted to the following form:
lock noauth nobsdcomp nodeflate defaultroute replacedefaultroute mtu 1400 persist maxfail 0 lcp-echo-interval 20 lcp-echo-failure 3 And finally, we try to connect:
pon pptpserver If everything worked out, try to look at our virtual interface:
~$ ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:10.0.0.100 PtP:10.0.0.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1 RX packets:1075 errors:0 dropped:0 overruns:0 frame:0 TX packets:959 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:154176 (154.1 KB) TX bytes:194499 (194.4 KB) Let's try to ping Orange PI from an external server:
~$ ping 10.0.0.100 PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data. 64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=8.91 ms 64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=8.80 ms 64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=8.93 ms 64 bytes from 10.0.0.100: icmp_seq=4 ttl=64 time=9.00 ms Works!
Port forwarding
Now just a little: redirect packets from the server to the Orange PI. Here the methods may be different, but since port 80 and 443 are not used at all on this server, we can simply ask the server to redirect all packages for these ports to OPI
iptables -t nat -A PREROUTING -p tcp -d 31.148.99.234 --dport 80 -j DNAT --to-destination 10.0.0.100:80 iptables -A FORWARD -i ppp0 -d 10.0.0.100 -p tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp -d 31.148.99.234 --dport 443 -j DNAT --to-destination 10.0.0.100:443 iptables -A FORWARD -i ppp0 -d 10.0.0.100 -p tcp --dport 443 -j ACCEPT Remember to change the IP addresses to your own. Check that everything works:
Great! The goal is reached!
Little improvements
But suddenly, in the building where the Orange PI is located, the lights are turned off and ... After the restart, no one can again access our orange. Why? Because by itself Orange PI will not connect to VPN. Let's write a simple bash script that will be looped through, checking if the connection is established:
#!/bin/sh while [ 0 ] do if ifconfig ppp0>>/dev/null then sleep 7 else pon pptpserver if $? then echo $(date) Connected else echo $(date) Connection error fi fi sleep 3 done Now add it to autoload. In the file /etc/rc.local we enter the line with the location of the script. In my case it is:
/root/scripts/ppp.sh Do not forget to give the script execution rights:
chmod +x /root/scripts/ppp.sh An attentive user may have noticed that there are echo commands in the script, but they have nowhere to draw a conclusion! Initially, I planned to do it in the form of a service, so that the withdrawal would conveniently drop there, but in the end it was corny, it works the same. By the way, does it work? Reboot our orange and see that the ppp0 interface has successfully risen, and our services are accessible from the Internet. The goal is achieved, gentlemen!
Total
All this is done solely for entertainment and educational purposes. It almost does not carry any practical benefits, since we still need an external server, and the load does not double its network, because it has to accept packets and immediately transfer them further. However, this method has advantages, since the real IP of our server will be hidden, this external server will be able to better withstand DDoS attacks, and will also be able to display a technical work page to restless users if Orange PI is not available. Of course, it will still have to seriously try to do this, but isn't it all pleasure in the path to the goal, comrades?
Links to used resources
1. How to configure VPN using PPTP
2. Port forwarding through NAT
Source: https://habr.com/ru/post/333996/
All Articles