Журнал LinuxFormat - перейти на главную

LXF122:net

Материал из Linuxformat
Версия от 20:58, 22 августа 2010; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Сети Свяжем ваши Linux-ПК, и пускай они вас обслуживают

Содержание

VPN: Расширяем вашу сеть

Часть 7: Нужен полный доступ к сети через Интернет? Присоединяйтесь к Нейлу Ботвику, который возьмется за виртуальную частную сеть (VPN).

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

Иногда это удобно; ну, а если нужно предоставить более полный доступ к сети по незащищенному соединению? Ответ – воспользуйтесь виртуальной частной сетью, или VPN (Virtual Private Network). Это схема, в которой часть сети отделена и подключена к основной сети через защищенное соединение по обычному незащищенному каналу (читай – через Интернет).

Связанные вместе

Существует два основных типа сетевой топологии VPN. Один из них используется для соединения двух сетей – точнее, для подключения друг к другу их шлюзов. Такая конфигурация подойдет, если у вас два офиса и нужно объединить их в одну сеть. Второй способ, который часто называют «настройкой мобильного сотрудника» [road warrior configuration] – это для случая, когда один или несколько отдельных компьютеров подключаются к центральной сети: например, ноутбук – к сети офиса по Wi-Fi или широкополосному мобильному соединению. Такой способ может применяться компанией для того, чтобы обеспечить разъездным сотрудникам доступ к сети, как если бы они находились на рабочих местах. Единственным заметным отличием здесь будет уменьшение скорости, поскольку она ограничивается возможностями интернет-соединения, а не гигабитной внутренней сети компании.

Надо сказать, что виртуальная частная сеть – скорее концепция, чем стандарт, и одной той же цели можно добиться разными способами, каждый из которых имеет свои за и против. Даже SSH-туннель, который мы рассмотрели в LXF119 – одна из разновидностей VPN, хотя и ограниченная одним сетевым соединением за раз.

Рассмотрим два различных подхода к VPN: OpenVPN (http://openvpn.net/index.php/opensource.html) и Openswan (http://www.openswan.org). Обе программы доступны и для Windows, но здесь мы займемся только версиями для Linux. Подробности работы с ними в Windows можно найти на сайтах проектов.

Начинаем работать с OpenVPN

OpenVPN – кросс-платформенная программа, умеющая создавать сети типа «точка–точка» или обеспечивать подключение к серверу нескольким клиентам. Она также прозрачно работает с маршрутизаторами и NAT-брандмауэрами, что делает ее идеальным вариантом для подключения так называемых мобильных сотрудников к офисной сети извне.

В качестве примера предположим, что у вас есть ноутбук, который подключается к домашнему компьютеру или машине в офисе по мобильному широкополосному соединению или Wi-Fi. Дадим этим компьютерам изобретательные имена laptop.example.com и gateway.example.com.

OpenVPN использует для связи устройства tun, поэтому сначала нужно убедиться, что они существуют. В большинстве дистрибутивов они есть, но не мешает проверить наличие файла /dev/net/tun. Если его нет, загрузите модуль командой 

modprobe -v tun

и попробуйте еще раз. Если он опять не создастся, сделайте это сами, командой 

mknod /dev/net/tun c 10 200

Также нужно убедиться, что порт 1194 (UDP) перенаправляется с маршрутизатора на компьютер, с которым вы хотите соединиться. Для начала выполним базовую установку, а уж потом посмотрим, как она работает и что делать дальше. Во-первых, выполните на компьютере шлюза команду 

OpenVPN --remote laptop.example.com --dev tun1 --ifconfig 10.0.1.1 10.0.1.2

а эту – на ноутбуке: 

openvpn --remote gateway.example.com --dev tun1 --ifconfig 10.0.1.2 10.0.1.1

Параметр опции --remote может быть либо именем хоста, либо IP-адресом. Потом на каждом из компьютеров вы должны увидеть несколько строк вывода, заканчивающихся 

Initialization Sequence Completed

Тем самым мы велели OpenVPN подключиться к другому компьютеру с использованием устройства tun1 (вы это увидите, запустив ifconfig) и задали адреса обеих конечных точек соединения. Они должны входить в одну из стандартных частных сетей – 10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16 – но не должны совпадать с адресами вашей локальной сети. Обратите внимание, что при выполнении команды с другого компьютера адреса меняются местами, так что в каждом случае первый адрес – это адрес компьютера, где выполняется команда. Попробуйте пропинговать второй адрес, чтобы убедиться, что вы можете общаться со вторым компьютером.

Запускать команду на обоих компьютерах для создания канала неудобно, так как в этом случае вам потребуется либо помощник на другой стороне, либо защищенное SSH-соединение между машинами. Указывать все опции каждый раз тоже неудобно, поэтому мы можем записать их в конфигурационный файл и запускать OpenVPN на компьютере шлюза во время загрузки системы.

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

dev tun1
remote laptop.example.com #или IP-адрес
ifconfig 10.0.1.1 10.0.1.2

а команда: 

openvpn /путь/к/настройкам

организует канал на стороне шлюза.

Безопасность – это ключ

Здесь есть одна очевидная проблема: данный метод предполагает, что известен IP-адрес компьютера, с которого вы подключаетесь. Если вы соединяете шлюзы двух офисов друг с другом – все прекрасно: у каждого из них есть известный статический IP-адрес. Но в случае с мобильными сотрудниками постоянный IP-адрес есть только у офиса, а ноутбук получает свой адрес через DHCP, и он будет зависеть от сети, где мобильный сотрудник находится в текущий момент. Поэтому нам нужно разрешить подключение с любого адреса или, по крайней мере, с диапазона адресов мобильного провайдера, что можно сделать путем настройки OpenVPN в конфигурации клиента/сервера.

Тут возникает важный вопрос, касающийся безопасности: как гарантировать подключение к сети только авторизованных пользователей, если разрешены соединения отовсюду? Нужно дать клиентам и серверам цифровые сертификаты, которые позволят им признать друг друга. Мы создадим их на сервере, и у OpenVPN есть набор скриптов для работы с ключами, он обычно находится в каталоге /usr/share/openvpn/easy-rsa. Если вам понадобится задать в них какие-либо параметры, скопируйте каталог целиком в /etc/openvpn, чтобы при обновлении настройки не затерлись.

Потом перейдите (cd) в директорию /etc/openvpn/easy-rsa и отредактируйте файл vars. После этого будет нужно задать подходящие значения для параметров KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG и KEY_EMAIL – ни один из них не должен остаться пустым. Наконец, создадим главный центр сертификации (Certificate Authority, CA) командами 


source ./vars/
./clean-all
./build-ca

Последует серия вопросов, но обычно можно просто нажимать Enter для каждого, потому что ответы на них заранее записаны в файле vars. Эти команды создадут в каталоге keys ключи, которыми мы будем подписывать все создаваемые клиентские и серверные сертификаты. Создадим сертификат сервера командой 

./build-key-server server

Примите настройки по умолчанию, но установите Common Name в server, потом ответьте y на вопрос, хотите ли вы подписать и утвердить сертификат. Теперь на каждом клиенте, который вы хотите подключить, выполните следующую команду, указав одинаковые имя клиента в командной строке и в ответ на запрос Common Name: 

./build-key clientname

Скрипт создаст ключ для подключения к VPN, которым может воспользоваться каждый, у кого есть доступ к компьютеру. Если это ноутбук, то используйте команду buildkey-pass вместо build-key. Будет создан ключ, защищенный паролем: это защитит вас, если компьютер украдут. Теперь выполните команду 

./build-dh

чтобы создать еще один файл, требуемый для процесса аутентификации. Теперь в каталоге keys будет несколько файлов CRT и KEY: один для центра сертификации, второй – для сервера, и по одному для каждого из клиентов. Есть также несколько файлов SR (запрос на подпись сертификата), на которые можно не обращать внимания. Вам нужно скопировать в каталог /etc/openvpn каждого компьютера четыре файла – два файла CA, файл CRT и собственный файл KEY для машины. На сервере также нужно скопировать файл dh1024.pem, созданный командой build-dh. Делать это нужно безопасно – либо на физическом носителе, либо по SSH, потому что каждый, у кого есть эти файлы, сможет подключиться к вашей сети. Убедитесь, что права доступа на секретный файл KEY установлены в rw-------; так как USB-брелки форматируются в FAT, файл при копировании получит большие права доступа.

Теперь нужно создать конфигурационные файлы для сервера и клиентов на основе примеров из каталога /usr/share/doc/openvpn/examples/sample-config-files/ или подобных. Скопируйте server.conf в /etc/openvpn/openvpn.conf на компьютере шлюза и загрузите его в свой редактор. Файл большой, но в основном это комментарии. С настроек по умолчанию начать вполне можно, но убедитесь, что параметры ca, cert, key и dh соответствуют файлам, созданным вами ранее. Для их задания используйте полные пути, иначе вы сможете запускать OpenVPN, только если он находится в одном каталоге с ключами. Раскомментирование строк user и group может повысить безопасность, но делайте это, только убедившись, что подключения работают. На каждом из клиентов скопируйте файл client.conf из каталога примеров в /etc/openvpn/openvpn.conf и откройте его на редактирование. В remote укажите IP-адрес (или имя хоста) сервера и порт, который он слушает (по умолчанию 1194). В файле может быть больше одной строки remote; они будут перебираться по очереди, пока не установится соединение. 

remote gateway.example.com 1194
remote 123.124.125.126 1194

Если шлюз находится за маршрутизатором, воспользуйтесь его публичным IP-адресом и перенаправьте порт 1194 на сервер шлюза в настройках своего маршрутизатора. Вставьте в строки cert и key имена файлов клиентского сертификата и ключа. Меняя любую из настроек по умолчанию в файле server.conf, убедитесь, что все сопутствующие параметры изменены и здесь. Проверьте конфигурацию, выполнив команду 

openvpn /etc/openvpn.conf

на сервере и затем на ноутбуке. Вы должны увидеть 

Initialization Sequence Completed

а запуск ifconfig на каждом из компьютеров покажет устройство tun с IP-адресом в диапазоне от 10.8.0.1 до 10.8.0.254, где сервер использует первый адрес. Теперь компьютеры должны пинговаться по новым IP-адресам. Если вы видите сообщение Initialization Sequence Completed, но пинг не работает, проверьте брандмауэры на сервере и клиенте. Ни один из них не должен блокировать трафик через интерфейс tun0.

Ну вот, все работает; можно настроить запуск OpenVPN при старте сервера с помощью менеджера пакетов, и он будет тихо сидеть в ожидании запросов на соединение. Когда вы захотите подключиться с ноутбука, наберите на нем команду openvpn или запустите сервис.

Подключаемся ко всей сети

Пока мы лишь позволили вашему ноутбуку соединяться со шлюзом сети. OpenVPN изменил таблицу маршрутизации таким образом, чтобы через VPN-соединение пропускался любой трафик на адреса 10.8.0.*, но к остальной части удаленной сети доступа еще нет. Настройте его, добавив строку 

push “route 192.168.1.0 255.255.255.0”

в конфигурационный файл сервера. Тогда при подключении клиента его таблица маршрутизации изменится таким образом, чтобы весь трафик в эту сеть отправлялся через VPN-соединение. Если, открыв VPN-соединение на клиенте, выполнить команду “route -n”, вы увидите примерно следующее: 

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0

Это работает хорошо при условии, что сервер OpenVPN также является и шлюзом, то есть другие компьютеры удаленной сети будут в любом случае отправлять через него весь внешний трафик. Если нет, имеются два варианта. Можно изменить таблицы маршрутизации всех компьютеров сети, которые должны быть доступны через VPN, выполнив следующую команду 

route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.1.1

или изменить настройки маршрутизатора так чтобы весь трафик на сеть 10.8.0.0 шел через сервер, адрес которого в этом примере 192.168.1.1.

Если вы хотите соединить через VPN две сети, у них должны быть разные адреса, иначе система не сможет определить, нужно ли отправлять пакет по обычному Ethernet, беспроводному интерфейсу или через устройство tun. То же самое может произойти и в конфигурации мобильного сотрудника, если сеть, к которой вы подключены, использует ту же маску подсети, что и ваша собственная. Вряд ли вам удастся убедить Starbucks поменять их сетевые настройки, и если вы планируете использовать их часто, хорошо бы переместить вашу сеть в менее популярную подсеть по сравнению с распространенными 192.168.0.0, 192.168.1.0 или 10.0.0.0. Мы советуем использовать что-нибудь типа 192.168.137.0 или гораздо менее распространенный (наверное, потому, что эти числа никак не упомнить) диапазон адресов с 172.16.0.0 до 172.31.255.255.

Виртуальные частные сети – большая и сложная тема. И хотя здесь нельзя описать все, надеюсь, рассказанного достаточно, чтобы начать. На сайтах OpenVPN и Openswan есть подробнейшие разделы с документацией, и при желании копнуть поглубже можете начать с них.

Займемся IPsec

Хотя здесь в основном говорилось об OpenVPN, вы можете предпочесть ей VPN на основе IPsec; тогда мы рекомендуем Openswan. Хотя Openswan – набор программ по большей части для Linux, он разрабатывается на других открытых платформах и может работать с реализациями IPsec многих операционных систем. Не будем углубляться в детали, но если вас заинтересовал Openswan, то сейчас мы рассмотрим основы создания соединения для конфигурации мобильного сотрудника.

Сначала для каждого компьютера создается секретный ключ. Сделать это можно так: 

ipsec newhostkey --verbose --hostname laptop.example.com --output /etc/ipsec.secrets
chmod 600 /etc/ipsec.secrets

Процесс можно ускорить, пошевеливая мышкой: тем самым вы обеспечите постоянное наличие данных в /dev/random. Выполните команду chmod, и имейте в виду, что IPsec откажется работать с файлом, который может читать кто-то кроме root. Не забудьте подставить вместо hostname собственное имя хоста. Теперь на ноутбуке можно выполнить следующую команду: 

ipsec showhostkey --left

чтобы просмотреть ключ. Повторите команду на шлюзе, заменив --left на --right. Вкратце поясним, что у соединения IPsec есть две стороны, левая и правая, и в случае соединения по типу момобильного сотрудника его компьютер считается левой стороной.

Базовая настройка

На ноутбуке откройте файл конфигурации Ipsec – обычно это /etc/ipsec.conf – и добавьте в него следующие строки: 

conn laptop
 left=%defaultroute
 leftid=@laptop.example.com
 leftrsasigkey=0sAQNoJVpgKtOM...
 right=192.168.1.1
 rightsubnet=192.168.1.0/24
 rightid=@gateway.example.com
 rightrsasigkey=0sAQPp2+LvORyzRYaI7...
 auto=add

Первая строка создает соединение под названием laptop. Остальные строки содержат его настройки и должны начинаться с пробела или знака табуляции. Вместо %defaultroute при запуске будет подставлен IP-адрес, полученный от системы, где выполняется IPsec – это удобно при настройке мобильного компьютера по DHCP в различных сетях. Каждая из сторон может использовать %defaultroute, но не обе сразу. Параметры id используются для аутентификации, и здесь проще всего вписать имя компьютера, предварив его @. Значения rsasigkey — это те, что вы получили от showhostkey. Для правой стороны можно также указать маску подсети, задающую диапазон адресов, к которым она может подключаться, имея заданный IP-адрес. Без этого вы увидите только сервер.


Теперь скопируйте этот файл на компьютер шлюза. Так как обе стороны соединения остаются теми же, на них можно использовать один и тот же файл. Впрочем, есть одно исключение – IP-адреса должны даваться так, как их видит эта машина, и если шлюз находится в частной сети за маршрутизатором, запишите «серый» адрес в его конфигурационный файл и предоставьте ноутбуку публичный адрес маршрутизатора.

Проверка, проверка.........

Теперь не худо убедиться, что все работает. Воспользуйтесь командой 

ipsec verify

для проверки доступности важных файлов, программ и модулей ядра. Могут появиться сообщения об ошибках, так как разрешены перенаправления ICMP. В Openswan есть пример файла sysctl.conf – обычно он находится в каталоге /etc/ipsec.d/examples, поэтому добавьте его содержимое в /etc/sysctl.conf, и после перезагрузки там окажутся верные настройки. Примените их сейчас командой 

sysctl -p

Также нужно разрешить маршрутизацию пакетов, добавив строку 

net.ipv4.ip_forward = 1

в /etc/sysctl.conf. В примере sysctl.conf она есть, и вы увидите сообщение об ошибке, потому что не запущен Pluto, демон соединения. Это можно исправить, запустив сервис IPsec с помощью менеджера пакетов. Теперь снова наберите команду: 

ipsec verify

и все результаты проверок должны быть OK или N/A. Пропустите две строки после Opportunistic Encryption DNS checks и проверьте настройки командой: 

ipsec auto --status

Строки, которые начинаются с чисел, отличных от 000 – это ошибки, но в Интернете легко найти информацию о том, как их исправить. Наконец, создайте соединение с ноутбука, выполнив команду: 

ipsec auto --up laptop

Она создаст устройство ipsec0, которое связывается с другой сетью, почти так же, как устройство tun в OpenVPN. Если ваш сервер находится за маршрутизатором, нужно также переправить на него UDP-порты 500 и 4500. LXF

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF122:net&oldid=10623»
Персональные инструменты
купить
подписаться
Яндекс.Метрика