2.3. Сеть 3
 Рис. 2.3 Сеть 3
Сеть 3 (рис. 2.3) состоит из двух серверов Server_1 и Server_2. На обоих серверах настроены статические адреса.
Сеть 3 предназначена для демонстрации работы протокола L2TP и будет реализовывать собой соединение хост-хост.
Таблица 2.3 (Таблица пользователей и паролей Сети 3)
Хост
|
Пользователь
|
Пароль
|
Server_1
|
root
|
g4g8zf
|
server
|
bynthytn
|
Server_2
|
root
|
g4g8zf
|
server
|
bynthytn
|
2.4. Сеть 4
 Рис. 2.4 Сеть 4
Сеть 4 (рис 2.4) состоит из одного сервера (Server_3), отвечающего за подсеть 192.168.44.0 с маской 255.255.255.0. Сервер 3 подключен к сети Интернет и имеет реальный IP – 192.168.5.23.
Сеть 4 будет использоваться для соединения сеть-сеть с сетью 5.
Таблица 2.4 (Таблица пользователей и паролей Сети 4)
Хост
|
Пользователь
|
Пароль
|
Server_3
|
root
|
g4g8zf
|
server
|
bynthytn
|
2.5. Сеть 5
 Рис. 2.5 Сеть 5
Сеть 5 (рис 2.5), как и сеть 4 (рис. 2.4), состоит из одного сервера (Server_4). Server_4 отвечает за сеть 192.168.55.0/255.255.255.0 и имеет реальный IP – 192.168.5.21.
Сеть 5 будет использоваться для соединения сеть-сеть с сетью 4.
Таблица 2.5 (Таблица пользователей и паролей Сети 5)
Хост
|
Пользователь
|
Пароль
|
Server_3
|
root
|
g4g8zf
|
server
|
bynthytn
|
3. Планирование подключений моделей сетей в программном обеспечении
3.1. OpenVPN
В Unix-подобных операционных системах, для реализации openVPN туннеля используется виртуальный драйвер ядра. Этот драйвер эмулирует сетевые устройства tun или TAP.
TAP симулирует Ethernet устройство и работает на канальном уровне модели OSI, оперируя кадрами Ethernet.
TUN (сетевой туннель) работает на сетевом уровне модели OSI, оперируя IP пакетами. TAP используется для создания сетевого моста, тогда как TUN - для маршрутизации.
Пакет, посылаемый операционной системой через TUN/TAP устройство, обрабатывается программой, которая контролирует это устройство. Сама программа также может отправлять пакеты через TUN/TAP устройство. В таком случае TUN/TAP устройство доставляет (или «внедряет») такой пакет в сетевой стек операционной системы, эмулируя таким образом доставку пакета с внешнего устройства.
Для реализации схемы соединения “Сеть-сеть” будем использовать tun-адаптер.
 Рис. 2.6 Соединение сеть-сеть при работе с туннелем OpenVPN
На рисунке 2.6 показано, что Сеть 1 соединена через Интернет с Сетью 2 с помощью двух сетевых адаптеров tun0.
Концепция OpenVPN подразумевает клиент-серверную модель. В качестве клиента будет выступать Server_2, а в качестве сервера – Server_1. Для настройки tun интерфейса необходимы специальные файлы конфигурации, как для клиента, так и для сервера.
На сервере Server_1 будет создан файл конфигурации server.ovpn, а на клиенте Server_2 будет создан файл конфигурации client.ovpn.
Важно учитывать тот факт, что за настройки маршрутизации и настройки для обоих tun интерфейсов, при объединении двух сетей посредством openVPN соединения, отвечает сервер (Server_1). Именно в файле конфигурации сервера описываются: сеть за клиентом, сеть за сервером, маршруты и настройки tun-интерфейса, выдаваемые клиенту.
Сервер (Server_1) будет иметь адрес tun-интерфейса – 10.10.10.1. Клиент (Server_2) – 10.10.10.2.
Для избежания возможных сложностей со стороны ipfw (пакетного фильтра FreeBSD), на серверах Server_1 и Server_2 в настройках фаерволла включена политика по умолчанию – DEFAULT TO ACCEPT (пропускать весь трафик).
Помимо файлов конфигурации для установления соединения между клиентом и сервером, OpenVPN использует обмен криптографическими ключами и сертификатами.
Первый шаг в построении конфигурации OpenVPN 2.0 заключается в создании инфраструктуры открытых ключей (Public Key Infrastructure, PKI). PKI состоит из:
отдельного сертификата (также известного как открытый ключ) и секретного ключа для каждого сервера и клиента;
главного сертификата центра сертификации (Certificate Authority, CA) и ключа, который используется для подписи каждого сертификата для сервера и клиентов.
OpenVPN поддерживает двунаправленную аутентификацию на основе сертификатов, это означает что клиент должен проверять подлинность сертификата сервера, а сервер должен проверять подлинность сертификата клиента до того как они начнут доверять друг другу.
Сервер и клиент будут аутентифицировать друг друга, сначала проверив что представленный сертификат подписан центром сертификации (CA), а затем путем проверки информации в заголовках уже аутентифицированного сертификата, таких как "common name" сертификата (этот термин оставлен в тексте "как есть" по причине отсутствия общеупотрбительного варианта перевода, само же понятие в общем случае обозначает имя объекта, которому выдается сертификат) сертификата и тип сертификата (клиент или сервер).
Эта модель безопасности с точки зрения VPN имеет ряд желательных функций:
Серверу необходим только свой сертификат/ключ - у него нет необходимости знать индивидуальные сертификаты каждого клиента, который может подключиться к нему.
Сервер будет принимать только клиентов, чьи сертификаты были подписаны главным CA-сертификатом (который мы будем генерировать ниже). Поскольку сервер может выполнить эту проверку подписи без необходимости доступа непосредственно к закрытому ключу CA, есть возможность для CA-ключа (наиболее чувствительного ключа во всем PKI) находиться на совершенно другой машине, даже без сетевого подключения.
Если закрытый ключ скомпрометирован, его можно отключить, добавив его сертификат к CRL (certificate revocation list, список отозванных сертификатов). CRL позволяет выборочно отклонять скомпрометированные сертификаты без необходимости перестройки всего PKI.
Сервер может применять клиент-специфичные права доступа на основании встроенных областей сертификата, таких как Common Name.
В используемой модели (рис. 2.6), в качестве центра сертификации выступает Server_1. На нем, будут создан публичный ключ (ca.key) и главный сертификат центра сертификации (ca.crt), на основе которого будет проверяться подлинность подписи сертификата клиента Server_2. Важно отметить, что ключи и сертификаты для клиентов генерируются на Server_1 и впоследствии, передаются (любыми возможными путями), на машину клиента Server_2. Так же, будет создан файл ta.key – файл, необходимый для tls-аутентификации. TLS (англ. Transport Layer Security) — безопасность транспортного уровня, как и его предшественник SSL (англ. Secure Socket Layers — уровень защищённых сокетов) — криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети Интернет.
На клиенте Server_2 будут 4 файла: публичный ключ (са.key), сертификат клиента (client.crt), ключ клиента (client.key), tls-ключ (ta.key).
Для модели соединения “хост-сеть” (рис. 2.7) требуются те же условия что и для соединения “сеть-сеть”(рис. 2.6), но с тем отличием, что клиент не имеет за собой сети и имеет другие имена файлов сертификата и ключа. Так же, важно, что в файле конфигурации клиента на сервере (только в этом случае), не будет записи о сети, находящейся за клиентом.
 Рис. 2.7 Соединение хост-сеть при работе с туннелем OpenVPN
|
