VPN на базе SSH: различия между версиями

Материал из OpenBSD-Wiki
Перейти к навигации Перейти к поиску
(Новая страница: «:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] == Мини-руководство «шаг за шагом» == Д…»)
 
Строка 11: Строка 11:
 
</pre>
 
</pre>
  
Ключевые элементы сетевой конфигурации рассмотрены, теперь приступаем к настройкам. Логинимся на <tt>srv1</tt> и правим главный конфигурационный файл sshd(8):
+
Ключевые элементы сетевой конфигурации рассмотрены, теперь приступаем к настройкам. Логинимся на <tt>srv1</tt> и правим главный конфигурационный файл [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html sshd(8)]:
  
 
<pre>
 
<pre>
Строка 33: Строка 33:
 
  srv1# kill -HUP `sed q /var/run/sshd.pid`
 
  srv1# kill -HUP `sed q /var/run/sshd.pid`
  
Далее разрешаем прохождение пакетов на используемых туннельных псевдоустройствах tun(4) (на tun0 у меня висит OpenVPN, tun1 — для OpenSSH):
+
Далее разрешаем прохождение пакетов на используемых туннельных псевдоустройствах [http://www.openbsd.org/cgi-bin/man.cgi?query=tun&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html tun(4)] (на <tt>tun0</tt> у меня висит OpenVPN, <tt>tun1</tt> — для OpenSSH):
  
 
  srv1# vi /etc/pf.conf
 
  srv1# vi /etc/pf.conf
Строка 42: Строка 42:
 
  srv1# pfctl -f /etc/pf.conf
 
  srv1# pfctl -f /etc/pf.conf
  
Создаем интерфейс tun1 и назначаем ему IP-адрес:
+
Создаем интерфейс <tt>tun1</tt> и назначаем ему IP-адрес:
  
 
  srv1# ifconfig tun1 create
 
  srv1# ifconfig tun1 create
 
  srv1# ifconfig tun1 10.0.0.1 10.0.0.2 netmask 255.255.255.252
 
  srv1# ifconfig tun1 10.0.0.1 10.0.0.2 netmask 255.255.255.252
  
При помощи команды ifconfig(8) проверяем его состояние:
+
При помощи команды [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html ifconfig(8)] проверяем его состояние:
  
 
<pre>
 
<pre>
Строка 64: Строка 64:
 
  srv2# echo 'Tunnel point-to-point' >> /etc/ssh/ssh_config
 
  srv2# echo 'Tunnel point-to-point' >> /etc/ssh/ssh_config
  
Остальные настройки и действия практически идентичны описанным выше: правим и активируем рулесеты файервола, поднимаем tun1, присваиваем ему сетевой адрес (обратите внимание, порядок следования IP-адресов изменен) и добавляем статический маршрут:
+
Остальные настройки и действия практически идентичны описанным выше: правим и активируем рулесеты файервола, поднимаем <tt>tun1</tt>, присваиваем ему сетевой адрес (обратите внимание, порядок следования IP-адресов изменен) и добавляем статический маршрут:
  
 
<pre>
 
<pre>
Строка 80: Строка 80:
 
  srv2# ssh -f -w 1:1 212.34.XX.YY true
 
  srv2# ssh -f -w 1:1 212.34.XX.YY true
  
Чтобы снизить накладные расходы, к списку аргументов имеет смысл добавить ключи «-o Compression=yes -x -a -n» (сжимать передаваемые данные, отключить пересылку пакетов X11, запретить аутентификацию с помощью агента и направить /dev/null на стандартный входной поток stdin(4)). Теперь проверим доступность удаленного узла, находящегося «за первым сервером»:
+
Чтобы снизить накладные расходы, к списку аргументов имеет смысл добавить ключи «-o Compression=yes -x -a -n» (сжимать передаваемые данные, отключить пересылку пакетов X11, запретить аутентификацию с помощью агента и направить <span style="color:green;">/dev/null</span> на стандартный входной поток [http://www.openbsd.org/cgi-bin/man.cgi?query=stdin&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html stdin(4))]. Теперь проверим доступность удаленного узла, находящегося «за первым сервером»:
  
 
<pre>
 
<pre>
Строка 88: Строка 88:
 
</pre>
 
</pre>
  
Если все ОК, можно дальше развивать предложенную схему, упрощая или, наоборот, усложняя настройки. Например, применить беспарольную аутентификацию на базе ключей, создать конфигурационный файл для автоматического создания псевдоустройства tun1:
+
Если все ОК, можно дальше развивать предложенную схему, упрощая или, наоборот, усложняя настройки. Например, применить беспарольную аутентификацию на базе ключей, создать конфигурационный файл для автоматического создания псевдоустройства <tt>tun1</tt>:
  
 
  srv2# echo '10.0.0.2 10.0.0.1 netmask 255.255.255.252' > /etc/hostname.tun1
 
  srv2# echo '10.0.0.2 10.0.0.1 netmask 255.255.255.252' > /etc/hostname.tun1
  
Занести необходимые статические маршруты и запуск «ssh -f -w» в один из сценариев начальной загрузки (/etc/rc.local) или в отдельный скрипт, чтобы все выполнялось одной командой, без дополнительных телодвижений. Чтобы использовать OpenSSH на уровне OSI 2, в качестве значения директив PermitTunnel и Tunnel следует использовать ethernet, а затем объединить в мост внешний сетевой интерфейс и псевдоустройство tunX (см. bridge(4)).
+
Занести необходимые статические маршруты и запуск «ssh -f -w» в один из сценариев начальной загрузки (<span style="color:green;">/etc/rc.local</span>) или в отдельный скрипт, чтобы все выполнялось одной командой, без дополнительных телодвижений. Чтобы использовать OpenSSH на уровне OSI 2, в качестве значения директив <tt>PermitTunnel</tt> и <tt>Tunnel</tt> следует использовать <tt>ethernet</tt>, а затем объединить в мост внешний сетевой интерфейс и псевдоустройство <tt>tunX</tt> (см. [http://www.openbsd.org/cgi-bin/man.cgi?query=bridge&sektion=4&apropos=0&manpath=OpenBSD+Current&arch=i386 bridge(4)]).
  
 
Стоит отметить, с помощью OpenSSH возможно построение не только Site-to-Site VPN (межсайтовое подключение, в котором два маршрутизатора создают туннель в интернете), но и Client-to-Site (VPN-подключение удаленного доступа для проводных и беспроводных клиентов).
 
Стоит отметить, с помощью OpenSSH возможно построение не только Site-to-Site VPN (межсайтовое подключение, в котором два маршрутизатора создают туннель в интернете), но и Client-to-Site (VPN-подключение удаленного доступа для проводных и беспроводных клиентов).

Версия 14:49, 5 июня 2013

Данная статья 100 % копипаст с www.openbsd.ru

Мини-руководство «шаг за шагом»

Для примера возьмем два сервера: srv1 с IP-адресами 212.34.XX.YY и 192.168.2.1 подключен к сегменту внутренней сети 192.168.2.0/24, а srv2 с 213.167.XX.YY и 192.168.1.1 шефствует над подопечными из 192.168.1.0/24. Настроим VPN-туннель средствами OpenSSH, в котором будут использоваться адреса 10.0.0.1 и 10.0.0.2. Для наглядности сценарий можно представить следующим образом:

     (10.0.0.1) 212.34.XX.YY            213.167.XX.YY (10.0.0.2)
192.168.2.0/24 — srv1 — [ internet ] — srv2 — 192.168.1.0/24
                192.168.2.1               192.168.1.1

Ключевые элементы сетевой конфигурации рассмотрены, теперь приступаем к настройкам. Логинимся на srv1 и правим главный конфигурационный файл sshd(8):

srv1# vi /etc/ssh/sshd_config

# Разрешаем туннелирование layer-3
# 
PermitTunnel point-to-point

# VPN на базе OpenSSH требует привилегий суперпользователя,
# поэтому аутентификацию под учетной записью root разрешаем
# только с доверенных хостов
# 
PermitRootLogin no
Match Host 213.167.XX.YY,192.168.2.*,127.0.0.1
 PermitRootLogin yes

По окончании настроек не забываем отправить демону сигнал SIGHUP, чтобы он смог перечитать свой конфиг:

srv1# kill -HUP `sed q /var/run/sshd.pid`

Далее разрешаем прохождение пакетов на используемых туннельных псевдоустройствах tun(4) (на tun0 у меня висит OpenVPN, tun1 — для OpenSSH):

srv1# vi /etc/pf.conf
pass quick on { tun0, tun1 } inet all

Загружаем правила из конфига:

srv1# pfctl -f /etc/pf.conf

Создаем интерфейс tun1 и назначаем ему IP-адрес:

srv1# ifconfig tun1 create
srv1# ifconfig tun1 10.0.0.1 10.0.0.2 netmask 255.255.255.252

При помощи команды ifconfig(8) проверяем его состояние:

srv1% ifconfig tun1
tun1: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
        groups: tun
        inet 10.0.0.1 --> 10.0.0.2 netmask 255.255.255.252

Не забываем добавить в таблицу маршрутизации удаленную подсеть:

srv1# route add 192.168.1.0/24 10.0.0.2

Второй сервер выступает в роли SSH-клиента, поэтому процедура конфигурирования здесь чуть проще:

srv2# echo 'Tunnel point-to-point' >> /etc/ssh/ssh_config

Остальные настройки и действия практически идентичны описанным выше: правим и активируем рулесеты файервола, поднимаем tun1, присваиваем ему сетевой адрес (обратите внимание, порядок следования IP-адресов изменен) и добавляем статический маршрут:

srv2# vi /etc/pf.conf
pass quick on { tun0, tun1 } inet all

srv2# pfctl -f /etc/pf.conf
srv2# ifconfig tun1 create
srv2# ifconfig tun1 10.0.0.2 10.0.0.1 netmask 255.255.255.252
srv2# route add 192.168.2.0/24 10.0.0.1

И, наконец, самый ответственный момент: устанавливаем защищенное соединение между двумя сетями:

srv2# ssh -f -w 1:1 212.34.XX.YY true

Чтобы снизить накладные расходы, к списку аргументов имеет смысл добавить ключи «-o Compression=yes -x -a -n» (сжимать передаваемые данные, отключить пересылку пакетов X11, запретить аутентификацию с помощью агента и направить /dev/null на стандартный входной поток stdin(4)). Теперь проверим доступность удаленного узла, находящегося «за первым сервером»:

srv2% ping 192.168.2.101
PING 192.168.2.101 (192.168.2.101): 56 data bytes
64 bytes from 192.168.2.101: icmp_seq=0 ttl=127 time=2.508 ms

Если все ОК, можно дальше развивать предложенную схему, упрощая или, наоборот, усложняя настройки. Например, применить беспарольную аутентификацию на базе ключей, создать конфигурационный файл для автоматического создания псевдоустройства tun1:

srv2# echo '10.0.0.2 10.0.0.1 netmask 255.255.255.252' > /etc/hostname.tun1

Занести необходимые статические маршруты и запуск «ssh -f -w» в один из сценариев начальной загрузки (/etc/rc.local) или в отдельный скрипт, чтобы все выполнялось одной командой, без дополнительных телодвижений. Чтобы использовать OpenSSH на уровне OSI 2, в качестве значения директив PermitTunnel и Tunnel следует использовать ethernet, а затем объединить в мост внешний сетевой интерфейс и псевдоустройство tunX (см. bridge(4)).

Стоит отметить, с помощью OpenSSH возможно построение не только Site-to-Site VPN (межсайтовое подключение, в котором два маршрутизатора создают туннель в интернете), но и Client-to-Site (VPN-подключение удаленного доступа для проводных и беспроводных клиентов).

Данное пошаговое руководство основано на статье «Волшебные криптотуннели», опубликованной в июльском номере журнала «Хакер» за 2008 год. Авторы оригинальной статьи: Андрей Матвеев и Сергей Яремчук.