Linux tunnel to vpn

Кунг-фу стиля Linux: бесплатный VPN по SSH

Если вы видите на некоторых сайтах множество рекламных баннеров, то вы знаете, что, если не будете пользоваться VPN (Virtual Private Network, виртуальной частной сетью), хакеры очень скоро захватят и разорят ваш компьютер и сожгут ваше жилище. Ну, они, по крайней мере, точно что-то такое задумывают. На самом же деле существует две основных причины, по которым кому-то может понадобиться VPN-подключение. Можно, конечно, купить подписку на соответствующий сервис, но если у вас есть SSH-доступ к какому-нибудь компьютеру, имеющему выход в интернет, это значит, что вы можете создать собственный VPN-сервис, не потратив на это ни копейки.

Основная идея тут заключается в том, чтобы подключиться к удалённому компьютеру, находящемуся в некоей сети, и сделать так, чтобы весь ваш сетевой трафик выглядел бы для той сети как локальный.

Первая причина, по которой это может кому-то понадобиться, заключается в повышении уровня безопасности и в заблаговременном устранении возможных угроз. Например, может понадобиться печатать на сетевом принтере, не «выставляя» этот принтер в обычный интернет. В результате, например, некто может сидеть в кафе и, подключившись к сети по VPN, распечатывать документы на принтере, чувствуя себя так, будто он находится за своим рабочим столом, а принтер стоит в паре метров от него. Использование VPN, кроме того, будет означать, что данные, передаваемые по WiFi-сети кафе, будут зашифрованы.

Вторая причина — это скрытие реального местоположения пользователя от любопытных глаз. Предположим, кому-то нравится смотреть видеоматериалы BBC, но живёт он в Эквадоре. Это значит, что для того чтобы видео не были бы для него заблокированы, ему нужно будет подключиться по VPN к сети, находящейся в Великобритании. Если власти некоей страны мониторят и цензурируют интернет, то жителям этой страны тоже может пригодиться возможность замаскировать свой трафик.

Использование SSH для организации VPN-подключения подойдёт для решения обеих вышеописанных задач. Правда, если вам, преимущественно, интересна первая из них, то вам, возможно, лучше подойдёт использование выделенного маршрутизатора или маленького компьютера, вроде Raspberry Pi, нацеленного на решение вашей задачи. Надо сказать, что если вы где-то арендуете сервер, то «VPN по SSH» — это не для вас.

Предварительная подготовка

Вам понадобится лишь root-доступ к обеим машинам. На удалённом компьютере должен быть установлен SSH-сервер. Понадобится вам, конечно, и SSH-клиент. И на локальной, и на удалённой машинах нужно будет выполнить некоторые настройки. Я использую KDE, поэтому для выполнения необходимых настроек применяю NetworkManager, но можно пойти и другим путём. Применение NetworkManager всего лишь упрощает задачу.

На сервере должны быть выполнены некоторые особые настройки, но вполне возможно то, что они уже на нём сделаны. Так, в файле /etc/ssh/sshd_config должна присутствовать строка PermitTunnel=yes . Кроме того, может понадобиться установить в значение yes параметр AllowTCPForwarding . В некоторых настройках может нуждаться и файрвол. При этом инструкции по конфигурированию плагина NetworkManager могут оказаться полезными даже тем, кто этой программой не пользуется.

Настройки на стороне клиента

Если вы пользуетесь NetworkManager, то вам понадобится соответствующий плагин. Для Neon и других дистрибутивов, основанных на Debian, подойдёт пакет network-manager-ssh . Это — всё, что вам потребуется. Если вы не хотите пользоваться NetworkManager, то можете применить следующие команды из материала автора плагина:

ssh -f -v -o Tunnel=point-to-point -o ServerAliveInterval=10 -o TCPKeepAlive=yes -w 100:100 root@YOUR_SSH_SERVER \ '/sbin/ifconfig tun100 172.16.40.1 netmask 255.255.255.252 pointopoint 172.16.40.2' && \ /sbin/ifconfig tun100 172.16.40.2 netmask 255.255.255.252 pointopoint 172.16.40.1 

Тут нужен root-доступ к обеим системам, так как мы создаём туннель. Это, даже при использовании плагина, ведёт к нескольким проблемам. Очевидно, нам не хотелось бы, чтобы у нас постоянно запрашивали бы пароль для SSH-подключения и проводили бы проверку ключа. Но если настраивать VPN вручную, с этими проблемами можно справиться.

Проблемы

Большинство современных систем не позволяют входить в систему с root-правами, используя пароль, а иногда и вовсе не позволяют подключаться к системе в таком режиме. Поэтому нам, в первую очередь, нужно решить эту проблему. Кроме того, когда NetworkManager запускает SSH, он ищет ключи, причём, для root-пользователя, а не для обычного пользователя. Если он чего-то не может найти, он просто останавливается. Поэтому нам нужно обеспечить возможность беспрепятственного root-входа в систему.

Для того чтобы обеспечить возможность root-входа на сервер, нужно отредактировать файл /etc/ssh/sshd_config и установить параметр PermitRootLogin в значение yes . Рекомендую работать в этом режиме ровно столько времени, сколько нужно на выполнение следующих шагов настройки сервера. Далее, нужно будет перезапустить sshd-сервер, например, такой командой:

Ещё можно воспользоваться такой командой:

Затем, войдя в локальную машину с использованием обычной учётной записи, нужно воспользоваться ssh-copy-id для установки сертификата на хост-машину. После того, как это будет сделано, нужно вернуться на сервер и поменять в /etc/ssh/sshd_config значение PermitRootLogin на prohibit-password . Благодаря этому входить на сервер как root-пользователь можно будет с использованием сертификата, но не с использованием пароля.

Если вы уже выполняли вход с root-аккаунта, то вам, возможно, уже задавали вопрос о том, хотите ли вы принять ключ сервера. Если это не так — значит — у нас проблема. Если можете, осуществите вход и ответьте утвердительно на соответствующий вопрос, после чего система перестанет его задавать. Но, если сделать этого нельзя, мы можем решить проблему, отключив StrictHostKeyChecking .

В теории, можно передавать плагину NetworkManager дополнительные опции ssh, но по каким-то причинам этот подход не работает с версией плагина из репозиториев. Если же вы плагином не пользуетесь, делая всё вручную, то вы можете сами выполнить необходимые настройки. Настройки SSH для root-пользователя можно задать в /root/.ssh/config . Можно, кроме того, задать глобальные настройки в /etc/ssh/ssh_config .

Если вы меняете глобальные настройки, то, если система это поддерживает, рассмотрите возможность использования /etc/ssh/ssh_config.d . Благодаря этому у вас будет возможность задавать параметры для конкретного хоста, которые не будут переписаны при обновлении системы. Например, можно создать в соответствующей директории файл с именем hackaday.conf :

Host *.hackaday.com hackaday.com StrictHostKeyChecking no Tunnel yes 

Опять же, если вам не нравится идея проверки ключа хоста, просто один раз войдите в систему из root-аккаунта и вручную примите удалённый ключ. Или, если храбрости вам не занимать, вручную отредактируйте /root/.ssh/known_hosts .

Подключение

Теперь всё должно быть готово к работе. Если вы используете плагин для NetworkManager, вам понадобится просто установить новое соединение. А именно, нужно перейти в раздел VPN-соединений и выбрать SSH.

Выбор типа соединения

Теперь нужно настроить несколько параметров нового соединения. В том числе — нужно указать сертификат, который планируется использовать для входа в удалённую систему.

После сохранения настроек соединения это соединение можно активировать — как и любой другой сетевой интерфейс. Если вы хотите проверить ваш новый VPN — сначала, в обычном режиме, поинтересуйтесь своим IP-адресом на специальном сайте. А после этого включите VPN и снова узнайте свой адрес. Если VPN-соединение вам установить не удастся — поищите в системном журнале сведения об ошибках, выдаваемых SSH.

Итоги

Конечно, есть и другие VPN-решения. Но практически гарантированно то, что на удалённом компьютере, с которым вы работаете, есть SSH-сервер. Поэтому предлагаемый метод установления VPN-соединения через SSH — это простое и удобное решение, которым можно воспользоваться без какой-либо предварительной подготовки.

Источник

VPN over SSH

There are several ways to set up a Virtual Private Network through SSH. Note that, while this may be useful from time to time, it may not be a full replacement for a regular VPN. See for example [1].

Using badvpn’s tun2socks

Note: The badvpn project has been discontinued in August 2022, and the latest stable release is from April 2015.

badvpn is a collection of utilities for various VPN-related use cases.

Start SSH dynamic SOCKS proxy

First, we will set up a normal SSH dynamic socks proxy like usual:

Set up badvpn and tunnel interface

Afterwards, we can go ahead with setting up the TUN.

# ip tuntap add dev tun0 mode tun user # ip addr replace 10.0.0.1/24 dev tun0 # badvpn-tun2socks --tundev tun0 --netif-ipaddr 10.0.0.2 --netif-netmask 255.255.255.0 --socks-server-addr localhost:4711

Now you have a working local tun0 interface which routes all traffic going into it through the SOCKS proxy you set up earlier.

Get traffic into the tunnel

All that’s left to do now is to set up a local route to get some traffic into it. Let us set up a route that routes all traffic into it. We will need three routes:

1. Route that goes to the SSH server that we use for the tunnel with a low metric.
2. Route for DNS server (because tun2socks does not do UDP which is necessary for DNS) with a low metric.
3. Default route for all other traffic with a higher metric than the other routes.

The idea behind setting the metrics specifically is because we need to ensure that the route picked to the SSH server is always direct because otherwise it would go back into the SSH tunnel which would cause a loop and we would lose the SSH connection as a result. Apart from that, we need to set an explicit DNS route because tun2socks does not tunnel UDP (required for DNS). We also need a new default route with a lower metric than your old default route so that traffic goes into the tunnel at all. With all of that said, let us get to work:

# ip route add via metric 5 # ip route add via metric 5 # ip route add default via 10.0.0.2 metric 6

Now all traffic (except for DNS and the SSH server itself) should go through tun0 .

OpenSSH’s built in tunneling

OpenSSH has built-in TUN/TAP support using -w: . Here, a layer 3/point-to-point/ TUN tunnel is described. It is also possible to create a layer 2/ethernet/TAP tunnel.

Enable forwarding for the TUN device

To enable forwarding for the TUN device, edit /etc/ssh/sshd_config and set PermitTunnel to yes , point-to-point or ethernet . Setting yes enables forwarding for both point-to-point and ethernet tunnels. See sshd_config(5) for details.

Create tun interfaces using systemd-networkd

/etc/systemd/network/vpn.netdev

[NetDev] Name=tun5 Kind=tun [Tun] User=vpn Group=network

/etc/systemd/network/vpn.network

[Match] Name=tun5 [Address] Address=192.168.200.2/24

Once these files are created, enable them by restarting systemd-networkd.service .

Also, you may manage tun interfaces with ip tunnel command.

Creating interfaces in SSH command

SSH creates both interfaces automatically, but IP and routing should be configured after the connection is established.

ssh \ -o PermitLocalCommand=yes \ -o LocalCommand="sudo ifconfig tun5 192.168.244.2 pointopoint 192.168.244.1 netmask 255.255.255.0" \ -o ServerAliveInterval=60 \ -w 5:5 vpn@example.com \ 'sudo ifconfig tun5 192.168.244.1 pointopoint 192.168.244.2 netmask 255.255.255.0; echo tun0 ready'

Start SSH

ssh -f -w5:5 vpn@example.com -i ~/.ssh/key "sleep 1000000000"

or you may add keep-alive options if you are behind a NAT.

ssh -f -w5:5 vpn@example.com \ -o ServerAliveInterval=30 \ -o ServerAliveCountMax=5 \ -o TCPKeepAlive=yes \ -i ~/.ssh/key "sleep 1000000000"

Troubleshooting

• ssh should have access rights to tun interface or permissions to create it. Check owner of tun interface and/or /dev/net/tun.
• Obviously if you want to access a network rather than a single machine you should properly set up IP packet forwarding, routing and maybe a netfilter on both sides.
• If you do not enable tunneling, you may get the following error when you want to create an SSH tunnel using -w :

channel 0: open failed: connect failed: open failed Tunnel forwarding failed

Using PPP over SSH

pppd can easily be used to create a tunnel through an SSH server:

# pppd updetach noauth silent nodeflate pty "/usr/bin/ssh root@remote-gw /usr/sbin/pppd nodetach notty noauth" ipparam vpn 10.0.8.1:10.0.8.2

When the VPN is established, you can route traffic through it. To get access to an internal network:

# ip route add 192.168.0.0/16 via 10.0.8.2

To route all Internet traffic through the tunnel, for example, to protect your communication on an unencrypted network, first add a route to the SSH server through your regular gateway:

Next, replace the default route with the tunnel

# ip route replace default via 10.0.8.2

Helper script

pvpn (package pvpn AUR ) is a wrapper script around pppd over SSH.

See also

Источник