Linux Ethernet Simple Tunnel in Four to Six Commands
- From the sandbox
- Tutorial
Brief cheat sheet:
Four commands per tunnel and two on the firewall (not needed if traffic between your servers is already allowed)
This is all that is needed, then a long explanation with details.
When it is required to combine several computers into a pseudo-local network via the Internet, this is often solved by setting up OpenVPN.
The solution works well, but it is not without drawbacks:
1. You need to install additional software and configure it. Moreover, the first time it is configured it is not very simple - you need to sit and sort it out.
2. Traffic encryption occurs in user mode and introduces additional delays, this is not always important, but for IP-telephony it can be noticeable.
3. Encryption is not always necessary. For example, in my case, all connections are already protected (ssh), I just need a convenient flat addressing between several computers as if they are connected to a local network.
In Linux, GRE tunnels are configured to obscene simply (if encryption is not needed), from Linux requirements and by public IP for each.
There is somehow vanishingly little information on the Internet on this topic - IP (rather than ethernet) tunnels are mainly explained and immediately coupled with traffic encryption (which is not always necessary). man ip is also very extensive and the information on
Let us have two hosts:
HOST1 with an external address 1.2.3.4
HOST2 with an external address 2.3.4.5
I would like to make an ethernet network between them, well, for example, you can configure IP addresses 192.168.0.1 192.168.0.2 on top of it, but you can use any other IPv6 or anything else - you get a regular network like through a switch.
All commands are executed from ROOT, after a reboot, they are lost. In order not to get lost, you need to register commands in startup scripts or in configs (each distribution has its own).
1. Add a virtual network gateway card to HOST1:
On HOST1, it will look like a regular network card - you can assign IP addresses, start a DHCP server, enable it in Bridge, etc.
2. Enable the added map
2. If running IP-tables - allow GRE traffic
3. Symmetric setup on the second host:
At this point, the ethernet network is already running. To verify this, you can configure private IP addresses on each side of the tunnel and send pings.
can ping.
For pings, you may also have to add rules to iptables (or turn it off altogether for the duration of the experiments).
The tunnel is quietly configured between different versions of linux, while writing this post, one end was on ubuntu, the other on centos, there is absolutely no difference in the configuration.
I repeat - this tunnel does not provide any protection against listening / introducing traffic.
HOST1: ip link add grelan type gretap local remote
HOST1: ip link set grelan up
HOST1: iptables -I INPUT -p gre -s -j ACCEPT
HOST2: ip link add grelan type gretap local remote
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s -j ACCEPT
Four commands per tunnel and two on the firewall (not needed if traffic between your servers is already allowed)
This is all that is needed, then a long explanation with details.
When it is required to combine several computers into a pseudo-local network via the Internet, this is often solved by setting up OpenVPN.
The solution works well, but it is not without drawbacks:
1. You need to install additional software and configure it. Moreover, the first time it is configured it is not very simple - you need to sit and sort it out.
2. Traffic encryption occurs in user mode and introduces additional delays, this is not always important, but for IP-telephony it can be noticeable.
3. Encryption is not always necessary. For example, in my case, all connections are already protected (ssh), I just need a convenient flat addressing between several computers as if they are connected to a local network.
In Linux, GRE tunnels are configured to obscene simply (if encryption is not needed), from Linux requirements and by public IP for each.
There is somehow vanishingly little information on the Internet on this topic - IP (rather than ethernet) tunnels are mainly explained and immediately coupled with traffic encryption (which is not always necessary). man ip is also very extensive and the information on
Let us have two hosts:
HOST1 with an external address 1.2.3.4
HOST2 with an external address 2.3.4.5
I would like to make an ethernet network between them, well, for example, you can configure IP addresses 192.168.0.1 192.168.0.2 on top of it, but you can use any other IPv6 or anything else - you get a regular network like through a switch.
All commands are executed from ROOT, after a reboot, they are lost. In order not to get lost, you need to register commands in startup scripts or in configs (each distribution has its own).
1. Add a virtual network gateway card to HOST1:
HOST1: ip link add grelan type gretap local 1.2.3.4 remote 2.3.4.5
On HOST1, it will look like a regular network card - you can assign IP addresses, start a DHCP server, enable it in Bridge, etc.
2. Enable the added map
ip link set grelan up
2. If running IP-tables - allow GRE traffic
HOST1: iptables -I INPUT -p gre -s 2.3.4.5 -j ACCEPT
3. Symmetric setup on the second host:
HOST2: ip link add grelan type gretap local 2.3.4.5 remote 1.2.3.4
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s 1.2.3.4 -j ACCEPT
At this point, the ethernet network is already running. To verify this, you can configure private IP addresses on each side of the tunnel and send pings.
HOST1: ip addr add 192.168.0.1/24
HOST2: ip addr add 192.168.0.2/24
can ping.
root@ubuntu:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=2.45 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=1.19 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=2.45 ms
For pings, you may also have to add rules to iptables (or turn it off altogether for the duration of the experiments).
The tunnel is quietly configured between different versions of linux, while writing this post, one end was on ubuntu, the other on centos, there is absolutely no difference in the configuration.
I repeat - this tunnel does not provide any protection against listening / introducing traffic.