Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы администрирования и системного программирования в операционной системе Linux. В 2 частях. Ч.2. Учебное пособие.pdf
Рис. 2.3. Конфигурация интерфейсов маршрутизатора R1
R1(config-if)#ip nat inside
R1(config-if)#no sh
R1(config-if)#ex
R1(config)#access-list 1 permit 192.168.1.0 0.0.0.255
R1(config)#access-list 1 permit 192.168.2.0 0.0.0.255
R1(config)#access-list 1 permit 172.16.10.0 0.0.0.255
R1(config)#ip nat inside source list 1 int e0/2 overload
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.0.10
Конфигурация интерфейсов маршрутизатора R1 представлена на рис. 2.3.
2.3.3. НАСТРОЙКА IP-АДРЕСОВ КОНЕЧНЫХ УСТРОЙСТВ
Зададим IP-адрес для устройства Server_NFS. Для этого отредактируем
файл /etc/network/interfaces с помощью утилиты nano, как показано на рис. 2.4.
Проверим текущую конфигурацию устройства с помощью команды
ifconfig (рис. 2.5).
Аналогичным образом установим IP-адреса на устройствах Server_SMB,
LinuxClient1, LinuxClient2 (рис. 2.6 – 2.11).
Рис. 2.4. Настройка IP-адреса на устройстве Server_NFS
Рис. 2.5. Конфигурация устройства Server_NFS
31
Рис. 2.6. Настройка IP-адреса на устройстве Server_SMB
Рис. 2.7. Конфигурация устройства Server_SMB
Рис. 2.8. Настройка IP-адреса на устройстве LinuxClient1
Рис. 2.9. Конфигурация устройства LinuxClient1
32
Рис. 2.10. Настройка IP-адреса на устройстве LinuxClient2
Рис. 2.11. Конфигурация устройства LinuxClient2
2.3.4. НАСТРОЙКА NFS-СЕРВИСА
Для работы с протоколом NFS необходимо на серверном устройстве установить пакет nfs-kernel-server. Для этого воспользуемся командой
root@ubuntu:~# apt-get install nfs-kernel-server
Далее создадим экспортируемые директории:
root@ubuntu:~# mkdir /nfs-server/public
root@ubuntu:~# mkdir /nfs-server/private
С помощью утилиты nano отредактируем файл /etc/exports для настройки
доступа к ресурсам NFS-сервера (рис. 2.12).
Для экспорта указанных к файле exports каталогов необходимо воспользоваться следующей командой
root@ubuntu:~# exportsf –a
Создадим в каталоге nfs_server соответствующие подкаталоги и файлы.
Изучим содержание каталога nfs_server (рис. 2.13).
Рис. 2.12. Редактирование файла exports
Рис. 2.13. Содержание каталога nfs_server
33
Рис. 2.14. Монтирование каталога на устройстве LinuxClient1 и
проверка его содержания
Рис. 2.15. Сообщение «В разрешении отказано» при попытке создать файл
Рис. 2.16. Сообщение «В разрешении отказано» при попытке отредактировать файл
На устройстве LinuxClient1 можно смонтировать каталог public устройства Server_NFS. Монтирование каталога на устройстве LinuxClient1 и его содержание представлено на рис. 2.14.
В файле exports указан параметр ro (только для чтения) при подключении
к каталогу public. Поэтому при попытке создать или удалить файл, директорию
или изменить данные в уже существующем файле, находящемся в импортируемом каталоге, пользователь получит сообщение «В разрешении отказано»
(рис. 2.15, 2.16).
34
Рис. 2.17. Монтирование каталога на устройстве LinuxClient2 и
проверка его содержания
Рис. 2.18. Изменение файла secret на устройстве LinuxClient2
Для устройства LinuxClient2 разрешено монтирование директории сервера nfs-server. Монтирование каталога на устройстве LinuxClient2 и его содержание представлено на рисунке 2.17.
На устройстве LinuxClient2 разрешено редактировать смонтированный
каталог (создать или удалить файл, директорию, редактировать информацию в
файлах). На рисунке 2.18 представлено редактирование файла secret в каталоге
/nfs-client/private на устройстве LinuxServer2. На рисунке 2.19 изображена проверка изменения файла secret в экспортируемой директории на устройстве
Server_NFS.
35
Рис. 2.19. Проверка файла secret на устройстве Server_NFS
2.3.5. НАСТРОЙКА SMB-СЕРВИСА
Перед началом создания SMB-сервера необходимо установить пакет
samba. Для этого выполним команду
root@ubuntu:~# apt-get install -y samba
Далее создадим экспортируемую директорию.
root@ubuntu:~# mkdir /smb-server/public
Создадим файл в экспортируемой директории.
root@ubuntu:~# touch /smb-server/public/document
С помощью редактора nano отредактируем файл /etc/samba/smb.conf для
настройки доступа к ресурсам SMB-сервера (рис. 2.20).
На устройстве LinuxClient1 смонтируем каталог public устройства
Server_SMB. Монтирование каталога на устройстве LinuxClient1 и его содержание представлено на рис. 2.21.
Рис. 2.20. Редактирование файла smb.conf
36
Рис. 2.21. Монтирование каталога на устройстве LinuxClient1 и
проверка его содержания
Рис. 2.22. Изменение файла document на устройстве LinuxClient1
Рис. 2.23. Проверка файла document на устройстве Server_SMB
Внесём изменения в файле document на клиентском устройстве с помощью редактора nano (рис. 2.22). После операции проверим сохранение внесённых изменений на сервере (рис. 2.23).
37
3. АДМИНИСТРИРОВАНИЕ СЕРВИСА OPENVPN
3.1. ТЕХНОЛОГИЯ OPENVPN
3.1.1. ОБЩИЕ СВЕДЕНИЯ
Протокол OpenVPN отвечает за поддержание коммуникации между клиентом и сервером. Как правило, он используется для создания защищённого
«туннеля» между VPN-клиентом и VPN-сервером.
Для передачи данных OpenVPN может использовать UDP (User Datagram
Protocol) или TCP (Transmission Control Protocol).
OpenVPN лучше всего работает по UDP (согласно данным OpenVPN.net),
поэтому сервер доступа OpenVPN сначала пытается установить UDPсоединения. Если это не удаётся, только тогда сервер пробует создать соединение по протоколу TCP. Большинство VPN-сервисов по умолчанию предостав-
ляют OpenVPN через UDP.
Благодаря своей структуре кода, протокол OpenVPN может легко обходить HTTP и NAT.
В отличие от большинства VPN-протоколов, OpenVPN – это протокол с
открытым исходным кодом. Это означает, что код никому не принадлежит,
и третьи стороны всегда могут его проверить или модернизировать.
3.1.2. ОСНОВНЫЕ МЕХАНИЗМЫ И ВОЗМОЖНОСТИ OPENVPN
3.1.2.1. Безопасность и шифрование
Безопасность и шифрование в OpenVPN обеспечивается библиотекой
OpenSSL и протоколом транспортного уровня Transport Layer Security (TLS).
Вместо OpenSSL в новых версиях OpenVPN можно использовать библиотеку
PolarSSL. Протокол TLS представляет собой усовершенствование протокола
защищённой передачи данных уровня защищённых сокетов Secure Socket
Layers (SSL).
OpenSSL – это система защиты и сертификации данных, название SSL переводится как система безопасных сокетов (Secure Socket Layer). OpenSSL ис-
38
пользуется практически всеми сетевыми серверами для защиты передаваемой
информацией. В OpenSSL может использоваться симметричная и ассиметричная криптография.
В первом случае перед началом передачи данных на все узлы сети необходимо поместить одинаковый секретный ключ. При этом возникает проблема
безопасной передачи этого ключа через небезопасный Интернет.
Во втором случае у каждого участника обмена данными есть два ключа –
публичный (открытый) и приватный (секретный).
Публичный ключ используется для зашифрования данных, а приватный –
для расшифрования. В основе шифрования лежит довольно сложная математика. Выбранный в SSL/TLS алгоритм зашифрования публичным ключом обеспечивает возможность расшифрования только с помощью приватного ключа.
Приватный ключ секретный, и должен оставаться в пределах узла, на котором он создан. Публичный ключ должен передаваться участникам обмена
данными.
Для безопасной передачи данных необходимо идентифицировать стороны, принимающие участие в обмене данными. В противном случае можно стать
жертвой так называемой «атаки посредника» (Man in the Middle, MITM). В ходе
такой атаки злоумышленник подключается к каналу передачи данных и прослушивает его. Он также может вмешиваться, удалять или изменять данные.
Чтобы обеспечить аутентификацию (проверку подлинности пользователя) протокол TLS использует инфраструктуру публичных ключей (Public Key
Infrastructure, PKI) и асимметричную криптографию.
Нужно осознавать, что расшифрование данных без наличия приватного
ключа тоже возможно, например, методом последовательного перебора. Хотя
такой метод и требует больших вычислительных ресурсов, это только вопрос
времени, когда данные смогут быть расшифрованы.
Хотя размер ключа влияет на сложность расшифрования, никакой ключ
не даёт гарантии полной безопасности данных. Кроме того, существует возможность похищения уже расшифрованных данных и ключей за счёт уязвимостей и закладок в операционной системе или прикладном ПО, а также в аппаратном обеспечении серверов и рабочих станций.
Шифрование данных увеличивает трафик и замедляет обмен данными.
Чем больше длина ключа, применяемого для шифрования данных, тем труднее
будет его подобрать, но и тем заметнее получится замедление обмена данными.
39
3.1.2.2. Сертификаты и удостоверяющий центр
При ассиметричной криптографии открытый ключ используется для зашифрования данных, а закрытый – для расшифрования. Чтобы избежать подделки открытого ключа, какая-то третья сторона должна его заверить. В результате этой процедуры создаётся так называемый сертификат открытого ключа.
Сертификат должна заверить организация, которой доверяют. Эта организация играет роль удостоверяющего центра (Certification authority, CA).
Если создаётся открытый ключ для публичного использования, в качестве
удостоверяющего центра должна выступать коммерческая или государственная
организация с неоспоримой репутацией. Эта организация публикует собственный открытый ключ, доступный всем.
Для сети VPN, создаваемой для своей компании, вы можете самостоятельно создать свой удостоверяющий центр CA и выпускать так называемые
самоподписанные сертификаты.
Самоподписанные сертификаты и будут играть роль публичных ключей,
с помощью которых узлы сети OpenVPN будут зашифровывать данные.
Для расшифрования данных будут использованы приватные ключи.
Сертификаты создаются в соответствии со стандартом X.509. Этот стандарт определяет форматы данных и процедуры распределения открытых ключей с помощью сертификатов, снабженных электронными подписями.
Сертификат X.509 – это публичный ключ, содержащий такие данные, как
субъект, владеющий сертификатом, имя узла, период действия, алгоритм и значение подписи сертификата, и т.д. Сертификат должен быть подписан приватным ключом удостоверяющего центра (Certification authority, CA).
Когда наш узел рабочей станции подключается к удалённому узлу (серверу) с использованием протокола TLS, сервер отправляет ему сертификат
X.509. На узле есть публичный ключ удостоверяющего центра CA, который
подписал этот сертификат. Этот ключ используется для проверки подписи.
При необходимости, блокировать доступ отдельных узлов к сети VPN.
Для упрощения этой процедуры в OpenVPN предусмотрен список отзыва сертификатов (Сertificate Revocation List, CRL) и простые средства для управления
этим списком. Список CRL создаётся в удостоверяющем центре CA и потом копируется на сервер OpenVPN.
40