SSH Layer 3 Tunnel Organization

In this section I will describe how to use the OpenSSH features to create a Layer 3 tunnel, as applied to the OS Debian GNU / Linux (it will probably work in Ubuntu without any particular problems).

It looks like this scheme that we build:

  ---------- / \ _ / - \ / \ / - \ -----------------
 |  Client | ~~~~~~~ / Internet / ~~~~~~~ |  Server |
 ---------- \ _ / - \ / \ _ / \ / / -----------------
 || \ \ || \
 ||  {tun0} {vlan8} ||  {tun1}
 ||  ||
 \ - ================= tunnel ============== - /

     * vlan8 - 212.90.160.1/27
     * tun0 - 10.254.254.2/30
     * tun1 - 10.254.254.1/30 

Preparatory work on the client side.
')
In our scheme, we will use key authentication, for this we first generate the key itself (rsa key type, 4KB size) and copy it to the root account on the server (on the server, while having to open it in time for login root) - PermitRootLogin yes):

  # sudo ssh-keygen -t rsa -b 4096
 # ssh-copy-id -i .ssh / id_rsa.pub root@212.90.160.1 

At this stage, we will already have the saved ssh key in .ssh / known_hosts, giving the answer “yes” to something like this:

  The authenticity of host '212.90.160.1 (212.90.160.1)' can't be established.
 RSA key fingerprint is aa: fe: a0: 38: 7d: 11: 78: 60: 01: b0: 80: 78: 90: ab: 6a: d2.
 Are you sure you want to continue connecting (yes / no)?  yes
 Warning: Permanently added '212.90.160.1' (RSA) to the list of known hosts. 

and the client authorization key already copied into .ssh / authorized_keys on the server side.

Next, we write on the client side the interface itself in / etc / network / interfaces:

  auto tun0
 iface tun0 inet static
 pre-up ssh -S / var / run / ssh-myvpn-tunnel-control -M -f -w 0: 1 212.90.160.1 true
 pre-up sleep 5
 post-up ip ls tun0 mtu 1300
 address 10.254.254.2
 netmask 255.255.255.252
 pointopoint 10.254.254.1
 post-down ssh -S / var / run / ssh-myvpn-tunnel-control -O exit 212.90.160.1 

At this stage, stop working with the client and proceed to the server.

Preparatory work on the server side.

On the server side, first of all, we make the following changes to / etc / ssh / sshd_config:

  PermitTunnel point-to-point
 PermitRootLogin forced-commands-only 

Now edit /root/.ssh/authorized_keys, adding to it a command to organize the tunnel:

  tunnel = "1", command = "/ sbin / ifdown tun1; / sbin / ifup tun1" ssh-rsa AAAA ...... X9vc = root @ ipclub 

After that, edit / etc / network / interfaces:

  auto vlan8
 iface vlan8 inet static
 address 212.90.160.1
 netmask 255.255.255.224
 network 212.90.160.0
 broadcast 212.90.160.31
 gateway 212.90.160.30
 vlan_raw_device eth0
 mtu 1400

 iface tun1 inet static
 address 10.254.254.1
 netmask 255.255.255.252
 pointopoint 10.254.254.2
 post-up ip ls tun0 mtu 1300 

Do not forget to define in /etc/sysctl.conf the status of net.ipv4.conf.default.forwarding:
Code

  net.ipv4.conf.default.forwarding = 1 

well, or before using the tunnel:

  $ sudo sysctl net.ipv4.conf.default.forwarding = 1 

Important! If you do not set net.ipv4.conf.default.forwarding to 1, then the tunnels will not rise!

Actually at this stage all the preparatory work is completed. We try to lift our tunnel from the client:

  $ sudo ifup tun0
 $ ip al dev tun0
 9: tun0: mtu 1300 qdisc pfifo_fast qlen 500
 link / [65534]
 inet 10.254.254.2 peer 10.254.254.1/30 scope global tun0
 $ ping -c2 10.254.254.1
 PING 10.254.254.1 (10.254.254.1): 56 data bytes
 64 bytes from 10.254.254.1: icmp_seq = 0 ttl = 64 time = 15.116 ms
 64 bytes from 10.254.254.1: icmp_seq = 1 ttl = 64 time = 16.454 ms
 --- 10.254.254.1 ping statistics ---
 2 packets transmitted, 2 packets received, 0% packet loss
 round-trip min / avg / max / stddev = 15.116 / 15.785 / 16.454 / 0.669 ms 

And watch icmp traffic on the server side:

  $ sudo tshark -tad -pni tun1
 Running as user "root" and group "root".  This could be dangerous.
 Capturing on tun1
 2009-03-10 11: 25: 53.927598 10.254.254.2 -> 10.254.254.1 ICMP Echo (ping) request
 2009-03-10 11: 25: 53.927649 10.254.254.1 -> 10.254.254.2 ICMP Echo (ping) reply
 2009-03-10 11: 25: 54.567857 10.254.254.2 -> 10.254.254.1 ICMP Echo (ping) request
 2009-03-10 11: 25: 54.567910 10.254.254.1 -> 10.254.254.2 ICMP Echo (ping) reply 

Further you can work with these interfaces as with usual eth, vlan, gre, etc. Route traffic through them, configure filtering rules, etc. etc. The flight of thought is limited only by fantasy;) However, we do not forget that the tunnel is still built on the third level, therefore marking QoS packets will hardly give the result that we would like to expect.

Actually, this could have been finished, but I want to draw attention to one “slippery” moment, for those who want to raise several SSH Layer 3 tunnels.
Client: pre-up ssh -S / var / run / ssh-myvpn-tunnel-control -M -f -w 0: 1 212.90.160.1 true
Server: tunnel = "1", command = "/ sbin / ifdown tun1; / sbin / ifup tun1" ssh-rsa AAAA ...... X9vc = root @ ipclub
0 is the client side tunnel number
1 is the server side tunnel number

Here, I almost forgot.
There is another unpleasant moment. Connection, periodically can "fall off". Therefore, it would be nice to take care of where the nodud in the cron will execute something like this on the client side:

  $ cat /etc/cron.d/tun0
 PATH = / usr / local / sbin: / usr / local / bin: / sbin: / bin: / usr / sbin: / usr / bin
 * / 5 * * * * root fping -c4 10.254.254.1 ||  (/ sbin / ifdown tun0; sleep 5; / sbin / ifup tun0)
 $ sudo /etc/init.d/cron restart