Создание интерфейса VPN
Следующее, что нам нужно сделать, это создать виртуальный интерфейс, который будет размещать сегмент сети VPN (подсеть, частью которой вы становитесь после успешного VPN-соединения) в нашем блоке pfSense.
Интерфейс был автоматически создан pfSense, когда мы нажали «Сохранить» после настройки нашего соединения ранее. Но нам еще нужно его назначить и настроить.
Как добавить интерфейс в pfSense
- Перейдите в Интерфейсы> Назначения. Вы увидите ovpnc1 в списке справа от доступных сетевых портов.
- Нажмите зеленую кнопку «Добавить» справа. Интерфейс ovpnc1 назначается и отображается как OPT1.
- Щелкните OPT1. Вы попадете на страницу конфигурации интерфейса.
- Tick Включить интерфейс и дать ему имя. Оставьте все остальные настройки нетронутыми.
- Щелкните Сохранить и применить изменения. Ваш интерфейс назначен и включен.
Если вы вернетесь на страницу «Назначения интерфейсов», то увидите, что ваш именованный интерфейс теперь является частью списка активных интерфейсов.
Создание сертификата клиента и пары ключей
Нам нужно будет создать каталог для хранения сертификатов и ключей клиентов. Обязательно предоставьте разрешение пользователю, не являющемуся пользователем root.
Сгенерируйте запрос на сертификат клиента:
Ответ в терминале:
Теперь скопируйте клиентский ключ в каталог client-configs:
Скопируйте файл запроса сертификата клиента на сервер центра сертификации:
На сервере центра сертификации импортируйте CSR:
Теперь мы должны подписать запрос для клиента, набрав:
Ответ в терминале:
Скопируйте сертификат клиента на сервер openvpn:
Теперь на сервере openvpn нам нужно скопировать все клиентские файлы в каталог клиента, который мы создали ранее.
Убедитесь в том, что пользователь не является root и имеет разрешения на файлы.
Настройка клиента
На сервере
На сервере генерируем сертификат для клиента. Для этого сначала чистим файл index.txt в папке C:\Program Files\OpenVPN\easy-rsa\keys.
Затем запускаем командную строку от имени администратора:
Переходим в каталог easy-rsa:
cd %ProgramFiles%\OpenVPN\easy-rsa
Далее наши действия зависят от версии RSA.
а) Создание сертификатов с RSA 3
Запускаем команду:
EasyRSA-Start.bat
Мы окажемся в среде EasyRSA Shell.
Создаем клиентский сертификат:
./easyrsa gen-req client1 nopass
./easyrsa sign-req client client1
Мы должны увидеть запрос на подтверждение намерения выпустить сертификат — вводим yes:
Confirm request details: yes
* в данном примере будет создан сертификат для client1.
После вводим пароль, который указывали при создании корневого сертификата.
Теперь из папки pki копируем файлы:
- issued/client1.crt
- private/client1.key
- ca.crt
- dh.pem
- ta.key
… и переносим их на клиентский компьютер.
б) Создание сертификатов с RSA 2
Запускаем vars.bat:
vars.bat
И генерируем сертификат первого пользователя:
build-key.bat client1
* на все запросы наживаем Enter, кроме Common Name — в данном поле вводим имя клиента (в нашем случае, просто client1). В конце подтверждаем введенную информацию — y.
** На каждого клиента нужно сгенерировать свой сертификат, в противном случае, им будет присваиваться один и тот же IP-адрес, что будет приводить к конфликту.
Получиться, что-то на подобие:
По умолчанию, для Common Name будет подставляться значение из vars.bat — но с ним сертификат не будет создаваться. Необходимо при создании каждого ключа подставлять значение, равное имени сертификата. Например, как выше — подставлено client1.
Теперь из папки keys копируем файлы:
- client1.crt
- client1.key
- ca.crt
- dh.pem
… и переносим их на клиентский компьютер.
На клиенте
Заходим на официальную страницу загрузки openvpn и скачиваем клиента для Windows:
* по сути, это тот же файл, который скачивался для сервера.
Запускаем скачанный файл и устанавливаем программу, нажимая «Далее».
Переходим в папку C:\Program Files\OpenVPN\config. И копируем в нее сертификаты, которые перенесли с сервера.
Теперь открываем блокнот от имени администратора и вставляем следующие строки:
client
resolv-retry infinite
nobind
remote 192.168.0.15 443
proto udp
dev tun
compress
ncp-disable
fast-io
cipher AES-256-CBC
ca ca.crt
cert client1.crt
key client1.key
dh dh.pem
float
keepalive 10 120
persist-key
persist-tun
verb 0
* где 192.168.0.15 443 — IP-адрес OpenVPN-сервера и порт, на котором он принимает запросы. Для боевой среды это будет внешний адрес.
Сохраняем файл с именем config.ovpn в папке C:\Program Files\OpenVPN\config.
Запускаем с рабочего стола программу «OpenVPN GUI» от имени администратора (это важно). Нажимаем правой кнопкой по появившемуся в трее значку и выбираем «Подключиться»:
Нажимаем правой кнопкой по появившемуся в трее значку и выбираем «Подключиться»:
Произойдет подключение и значок поменяет цвет с серого/желтого на зеленый.
Option 60 (Vendor Class Identifier — VCI)
This option is used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. The information is a string of n octets, interpreted by servers. Vendors may choose to define specific vendor class identifiers to convey particular configuration or other identification information about a client. For example, the identifier may encode the client’s hardware configuration. Servers not equipped to interpret the class-specific information sent by a client MUST ignore it (although it may be reported). Servers that respond SHOULD only use option 43 to return the vendor-specific information to the client. The code for this option is 60, and its minimum length is 1.The phone sends its type (i.e. snomD765) via this option to the DHCP server.
List of all Vendor class identifiers for Snom phones:
| Desk phones | DECT base stations | Conference & PA |
|---|---|---|
|
snomD120 snomD305 snomD315 snomD335 snomD345 snomD375 snomD385 snom710 snom715 snomD717 snom725 snomD735 snomD745 snomD765 snomD785 |
snomM200SC snomM300/xx.xx.xxxx snomM700/xx.xx.xxxx SnomM900/xx.xx.xxxx (xx.xx.xxxx being the firmware version, e.g. 04.10.0004) |
snomC520 snomPA1 snomMP |
[править] Инсталляция и настройка DHCP сервера ISC-DHCP
Будем использовать dhcp-сервер ISC-DHCP (v3)
ISC DHCP Server — наиболее распространнённый DHCP-сервер, из использующихся в UNIX/Linux-системах.
Для нас сейчас важно и то, что это один из серверов, умеющих распознавать опцию 82
Будем предполагать, что инсталляция и настройка сервера
выполняется в Debian GNU/Linux. Пользователи других систем
должны учесть, что процедура инсталляции
и местоположение конфигурационных файлов могут несколько отличаться.
Установка DHCP-сервера с поддержкой опции 82
В обычном случае установить откомпилированный DHCP-сервер из репозитория пакетов
можно было бы с помощью команды:
%# apt-get install dhcp3-server
и можно было бы считать, что на этом инсталляция сервера закончена,
и можно переходить к его настройке. Однако, в том случае, если предполагается использование
DHCP-ретранслятора (что обязательно, если будет использоваться опция 82),
может потребоваться сборка пакета с включённой директивой USE_SOCKETS.
Подробнее эта процедура описана ниже.
Сборка с включённой директивой USE_SOCKETS
По умолчанию DHCP-сервер ожидает услышать запросы клиентов на широковещательном адрес 255.255.255.255. Однако, когда запрос перенаправляет DHCP-ретранслятор, запрос приходит непосредственно на адрес DHCP-сервера.
Для того чтобы DHCP-сервер корректно обрабатывал информацию от DHCP-ретранслятора,
его необходимо скомпилировать с использованием директивы
#define USE_SOCKETS
и указать в конфигурационном файле local-address.
Скачиваем исходники DHCP-сервера:
%# apt-get source dhcp3-server
Перед началом сборки исходников необходимо установить все пакеты,
необходимые для успешной сборки пакета, для чего выполнить:
%# apt-get build-dep dhcp3-server
Теперь необходимо в файле site.h раскомментировать директиву #define USE_SOCKETS:
%# vi dhcp3-3.0.6.dfsg/includes/site.h
Перейти в каталог dhcp3-3.0.6.dfsg:
%# cd dhcp3-3.0.6.dfsg/
Для того чтобы собрать пакет необходимо выполнить:
%$ dpkg-buildpackage -rfakeroot -b
или, если сборка производится root’ом:
%# dpkg-buildpackage -b
После сборки пакеты должны быть установлены в системе
(инсталлируем только common и server, так как нам не нужен DHCP-ретранслятор и DHCP-клиент):
%# dpkg -i dhcp3-common_3.0.6.dfsg-1_i386.deb dhcp3-server_3.0.6.dfsg-1_i386.deb
Настройка DHCP-сервера
Сразу же после инсталляции пакета,
сервер не заработает — сначала необходимо
отредактировать его конфигурационный файл /etc/dhcp3/dhcpd.conf.
# Укажите адрес, на который DHCP-сервер ожидает получать запросы (адрес DHCP-сервера)
local-address 192.168.2.9;
# Укажите подсеть интерфейса, на котором запущен DHCP-сервер
subnet 192.168.2.0 netmask 255.255.255.0 {
}
# Если сервер получит запрос, содержащий опцию 82, он сгенерирует сообщение в системный журнал
#
if exists agent.circuit-id
{
log ( info, concat( " Lease for ",
binary-to-ascii (10, 8, ".", leased-address),
" Switch port: ",
binary-to-ascii (10, 8, ".", option agent.circuit-id),
" Switch MAC: ",
binary-to-ascii(16, 8, ".", option agent.remote-id)));
}
# Запросы, пришедшие с 5го порта коммутатора:
class "port-5"
{
match if binary-to-ascii (10, 8, "", suffix( option agent.circuit-id, 1)) = "5";
}
# Адрес для 5го порта:
pool {
range 192.168.1.55;
allow members of "port-5";
}
Интерфейс, на котором будет работать DHCP-сервер,
передается ему в качестве аргумента при вызове.
В Debian GNU/Linux аргументы и ключи вызова программ
принято указывать в соответствующих файлах в каталоге /etc/default,
в частности, конфигурационный файл, в котором находятся опции для нашего сервера,
называется /etc/default/dhcp3-server.
При условии, что сервер будет слушать запросы на интерфейсе eth0,
файл будет выглядеть так:
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests? # Separate multiple interfaces with spaces, e.g. "eth0 eth1". INTERFACES="eth0"
Можно указать несколько интерфейсов,
запросы с которых будет обрабатывать сервер.
Они должны быть разделены пробелом.
Теперь можно запускать сервер:
%# /etc/init.d/dhcp3-server start
После сборки сервера с #define USE_SOCKETS:
udp 0 0 192.168.2.9:67 0.0.0.0:* 863/dhcpd3 udp 0 0 192.168.2.9:67 0.0.0.0:* 863/dhcpd3
Quick Setup Guide
RouterOS has a built in command that lets you easily set up a DHCP server. Let’s say we want to configure DHCP server on ether1 interface to lease addresses from 192.168.0.2 to 192.168.0.254 which belong to the 192.168.0.0/24 network. The gateway and DNS server is 192.168.0.1.
From menu run setup command and follow instructions:
ip dhcp-server> setup
Select interface to run DHCP server on
dhcp server interface: ether1
Select network for DHCP addresses
dhcp address space: 192.168.0.0/24
Select gateway for given network
gateway for dhcp network: 192.168.0.1
Select pool of ip addresses given out by DHCP server
addresses to give out: 192.168.0.2-192.168.0.254
Select DNS servers
dns servers: 192.168.0.1
Select lease time
lease time: 3d
ip dhcp-server>
The wizard has made the following configuration based on the answers above:
ip dhcp-server> print Flags: X - disabled, I - invalid # NAME INTERFACE RELAY ADDRESS-POOL LEASE-TIME ADD-ARP 0 dhcp1 ether1 0.0.0.0 dhcp_pool1 3d no ip dhcp-server> network print # ADDRESS GATEWAY DNS-SERVER WINS-SERVER DOMAIN 0 192.168.0.0/24 192.168.0.1 192.168.0.1 ip dhcp-server> /ip pool print # NAME RANGES 0 dhcp_pool1 192.168.0.2-192.168.0.254 ip dhcp-server>
DYNAMIC DNS
Note that everything in this section is true whether you are using DHCPv4
or DHCPv6. The exact same syntax is used for both.
To make it work, you have to declare a key and zone as in the DHCP
server (see dhcpd.conf(5) for details). You also need to
configure the fqdn option on the client, as follows:
send fqdn.fqdn "grosse.example.com."; send fqdn.encoded on; send fqdn.server-update off; also request fqdn, dhcp6.fqdn;
The fqdn.fqdn option MUST be a fully-qualified domain
name. You MUST define a zone statement for the zone to be
updated. The fqdn.encoded option may need to be set to
on or off, depending on the DHCP server you are using.
The
do-forward-updates
statement
do-forward-updates [ flag ] ;
If you want to do DNS updates in the DHCP client
script (see dhclient-script(8)) rather than having the
DHCP client do the update directly (for example, if you want to
use SIG(0) authentication, which is not supported directly by the
DHCP client, you can instruct the client not to do the update using
the do-forward-updates statement. Flag should be true
if you want the DHCP client to do the update, and false if
you don’t want the DHCP client to do the update. By default, the DHCP
client will do the DNS update.
Настройка клиентов на работу с DHCP сервером
Осталось настроить клиентов, например, у меня в качестве примера клиентом выступает компьютер под управлением ОС Windows 7, мы заходим в свойства протокола TCP/IP и выбираем настройку «Получить ip адрес автоматически»
И после (если сервер и клиент находятся в одной сети) мы увидим, что клиент получил ip адрес и параметры
А на DHCP сервере появится запись о том, что он выдал ip адрес такому то компьютеру, это можно посмотреть, в оснастке «DHCP» в меню Арендованные адреса
В общем, на этом все. Мы с Вами и установили и настроили DHCP сервер на операционной системе Windows Server 2012 R2 Datacenter.
Нравится15Не нравится3
Создание сервера центра сертификации с помощью EasyRSA
Первое что требуется сделать это создать файл с именем для хранения информации об организации. Для этого мы можем использовать пример файла, доступного в каталоге EasyRSA-3.0.8.
Чтобы перечислить файлы в каталоге EasyRSA, используйте команду:
В терминале вы увидите следующий ответ:
Сделайте копию файла vars.example как vars:
Теперь откройте файл vars и добавьте информацию об организации в конец файла:
Теперь инициализируйте PKI на сервере центра сертификации. После инициализации сервер создаст папку pki.
Теперь мы можем создать корневую пару открытых и закрытых ключей для нашего ЦС. Во время этого процесса вас попросят ввести кодовую фразу для пары ключей. А так же она потребуется, когда вам нужно будет подписать или отозвать сертификат. Но в нашем случае мы будем использовать команду так, чтобы нам кодовая фраза не предлагалась. Вам также будет предложено указать Общее имя (CN), но мы оставим его по умолчанию, нажав клавишу Enter.
Это создаст корневой сертификат с именем ca.crt в каталоге pki и приватным ключом ca.key в каталоге pki/private.
Вот и все наш сервер центра сертификации готов!
Testing DNS resolution from a client system
We are going to assume that you have a DNS server configured in the Admin UI of the Access Server, under VPN Settings. We are assuming you are not using the DNS Resolution Zones or the DNS Default Suffix fields. With this setting, all DNS request should be going from the OpenVPN client, through the OpenVPN Access Server, and then to the specified DNS server. In our example we are pushing the Google Public DNS server 8.8.8.8, and our test results will reflect this in the sample outputs as well.
Install your OpenVPN client program on your chosen client system. In our example we will be using a Windows 10 Professional client system with the OpenVPN Connect Client installed, and connected to the OpenVPN Access Server. Next open a console session or an SSH session to the OpenVPN Access Server, and obtain root privileges. We will be using the tool tcpdump to monitor activity on port 53 TCP and UDP, the default port where DNS queries are handled. We will be flushing the local DNS resolver cache on the client side, and then resolve a number of domains simply by pinging them by name. In our test situation, there are only a handful of clients connected, and the activity of DNS queries is very low, so we can monitor it easily. If you are testing on a production system and the tcpdump command gives too much output, you can append a grep filter by IP address, to filter queries coming only from your specific VPN client’s IP address, to make reading and locating the DNS query results easier.
On the Access Server run these commands:
With TCPdump installed, now run it with these parameters:
Or, if you want to filter it by the IP address of your VPN client (adjust as needed):
With this running in the background, go to your VPN client’s operating system, and open a command prompt. On Windows for example you can run the cmd program to open an old style DOS prompt. With that open, use the following commands to wipe the local DNS resolver cache, so it won’t pull results from its own local memory, and then do an actual query.
Wipe local DNS resolver cache on Windows:
Resolve some domain names:
Each of these should yield results that look somewhat like this:
On the OpenVPN Access Server you should be seeing results that look somewhat like this:
The above result from tcpdump shows that a DNS request was received from the VPN client at 172.27.232.2, and that it was directed at the DNS server at 8.8.8.8, and the request was to find the A record (IP address) for the DNS name www.google.com. The first line shows that this request is coming in at the OpenVPN Access Server, from the VPN client. The second line shows the request leaving the Access Server through the network interface with MAC address 00:0c:29:c7:60:e9. In our test setup, this is the network interface of the Access Server that goes to the Internet, which makes sense, because the 8.8.8.8 DNS server is on the Internet. The third line shows that a DNS result has been received, and the fourth line shows that this result has been relayed back to the VPN client. In this case, DNS resolution is working.
[править] Задача
Протокол динамического конфигурирования DHCP очень удобен — настройка стека TCP/IP клиентских
машин не требует никакого внимания со стороны администратора, всё происходит само собой.
С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост
получит какой адрес. Если нужно сохранить удобство использования DHCP, но при этом сделать так, чтобы адреса были
чётко закреплены за каждым компьютером, используется так называемая привязка к MAC-адресу: DHCP-сервер имеет таблицу соответствия MAC-адресов IP-адресам, и назначает IP-адреса в соответствии с этой таблицей.
Минус этого решения — необходимость отслеживания MAC-адресов и сопровождения таблицы соответствия.
В некоторых случаях может помочь компромиссное решение — поставить IP-адреса в соответствие не MAC-адресам,
а портам коммутатора, к которым подключен клиентский компьютер.
Другой вариант — выдавать IP-адреса в зависимости от того, с какого DHCP-ретранслятора пришел запрос.
В этом случае выдаются адреса из одной подсети, но с привязкой конкретных диапазонов адресов к различным коммутаторам,
работающим как DHCP-ретрансляторы. Это может помочь облегчить администрирование сети в том смысле, что по IP-адресу клиентского компьютера, будет понятно к какому коммутатору он подключен.
Решить эти задачи позволяет опция 82 протокола DHCP.
Ниже описывается, каким образом настроить DHCP-сервер, чтобы он выдавал IP-адрес в зависимости от того, к какому порту коммутатора подключен клиент, сделавший запрос. Рассматривается случай, когда коммутатор,
через который поступает запрос, используется в роли DHCP-ретранслятора
(решение задачи для случая, когда это не так, описано на странице DHCP snooping).
Некоторые дополнительные параметры
option domain-name string;
Параметр задает доменное имя, которое клиенты используют при запросах к DNS, при разрешении имен.
option netbios-name-servers ip-address [, ip-address…];
Задает список серверов имен NetBIOS (NBNS), соответствующих RFC 1001/1002 Сервера должны быть перечислены в порядке предпочтительности. Сервера имен NetBIOS так же известны как сервера WINS.
option netbios-dd-server ip-address [, ip-address…];
Опция сервера распределения данных NetBIOS (NBDD) указывает список серверов RFC 1001/1002 NBDD. Серверы должны быть перечислены в порядке предпочтения.
option netbios-node-type INT;
Параметр позволяет сконфигурировать тип узла, т.е. способ разрешения имен клиентами NetBIOS поверх TCP/IP.
Возможные значения параметра:
1
B-node (Broadcast): Разрешение имен с помощью широковещательных запросов, WINS не используется.
2
P-node (Peer): Используется только WINS.
4
M-node (Mixed): Смешанный тип, сначала используется широковещательный запрос, затем в случае неудачи — WINS
8
H-node (Hybrid): Смешанный наоборот. WINS, а затем broadcast.
option netbios-scope string;
Опция области NetBIOS указывает параметр NetBIOS через TCP/IP для клиента, как указано в RFC 1001/1002. См. RFC1001, RFC1002 и RFC1035 для ограничения набора символов.
Properties
Sub-menu:
| Property | Description |
|---|---|
| add-default-route (yes | no | special-classless; Default: yes) | Whether to install default route in routing table received from dhcp server. By default RouterOS client complies to RFC and ignores option 3 if classless option 121 is received. To force client not to ignore option 3 set special-classless. This parameter is available in v6rc12+
|
| client-id (string; Default: ) | Corresponds to the settings suggested by the network administrator or ISP. If not specified, client’s MAC address will be sent |
| comment (string; Default: ) | Short description of the client |
| default-route-distance (integer:0..255; Default: ) | Distance of default route. Applicable if is set to . |
| disabled (yes | no; Default: yes) | |
| host-name (string; Default: ) | Host name of the client sent to a DHCP server. If not specified, client’s system identity will be used. |
| interface (string; Default: ) | Interface on which DHCP client will be running. |
| script (script; Default: ) | Execute script on status change. This parameter is available in v6.39rc33+ These are available variables that are accessible for the event script:
|
| use-peer-dns (yes | no; Default: yes) | Whether to accept the DNS settings advertised by DHCP Server. (Will override the settings put in the submenu. |
| use-peer-ntp (yes | no; Default: yes) | Whether to accept the settings advertised by DHCP Server. (Will override the settings put in the submenu) |
Networks
Sub-menu:
| Property | Description |
|---|---|
| address (IP/netmask; Default: ) | the network DHCP server(s) will lease addresses from |
| boot-file-name (string; Default: ) | Boot file name |
| caps-manager (string; Default: ) | Comma-separated list of IP addresses for one or more CAPsMAN system managers. DHCP Option 138 (capwap) will be used. |
| dhcp-option (string; Default: ) | Add additional DHCP options from . |
| dhcp-option-set (string; Default: ) | Add additional set of DHCP options. |
| dns-none (yes | no; Default: no) | If set, then DHCP Server will not pass dynamic DNS servers configured on the router to the DHCP clients if no DNS Server in dns-server is set. By default if there are no DNS Servers configured, then the dynamic DNS Servers will be passed to DHCP clients. |
| dns-server (string; Default: ) | the DHCP client will use these as the default DNS servers. Two comma-separated DNS servers can be specified to be used by the DHCP client as primary and secondary DNS servers |
| domain (string; Default: ) | The DHCP client will use this as the ‘DNS domain’ setting for the network adapter. |
| gateway (IP; Default: 0.0.0.0) | The default gateway to be used by DHCP Client. |
| netmask (integer: 0..32; Default: ) | The actual network mask to be used by DHCP client. If set to ‘0’ — netmask from network address will be used. |
| next-server (IP; Default: ) | IP address of next server to use in bootstrap. |
| ntp-server (IP; Default: ) | the DHCP client will use these as the default NTP servers. Two comma-separated NTP servers can be specified to be used by the DHCP client as primary and secondary NTP servers |
| wins-server (IP; Default: ) | The Windows DHCP client will use these as the default WINS servers. Two comma-separated WINS servers can be specified to be used by the DHCP client as primary and secondary WINS servers |
SAMPLE
timeout 300;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
reject 192.33.137.209;
interface "ep0" {
send host-name "andare.example.com";
hardware ethernet 00:a0:24:ab:fb:9c;
send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
send dhcp-lease-time 3600;
supersede domain-search "example.com", "rc.isc.org", "home.isc.org";
prepend domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name;
require subnet-mask, domain-name-servers;
script "/sbin/dhclient-script";
media "media 10baseT/UTP", "media 10base2/BNC";
}
alias {
interface "ep0";
fixed-address 192.5.5.213;
option subnet-mask 255.255.255.255;
}
Параметры
| Параметр | Описание |
|---|---|
| none | Значение опции «none» означает отсутствие данного параметра для данного интерфейса, не взирая на наличие по умолчанию значения данного параметра. |
| default | Значение опции «default» означает отсутствие специального значения данного параметра. При этом к данному интерфейсу применяется значение по умолчанию, если оно задано. Отметим, что значение опции «default» не отображается в конфигурации клиента DHCP. |
| -l (none|default|$ACLNAME|acl:ACLNAME) |
Опция устанавливает список IP-адресов серверов DHCP, от которых клиенту разрешено принимать параметры. «ACLNAME» – имя системного списка доступа (см. описание команды «acl»). Если указанный список доступа отсутствует в системе (не создан командой «acl»), то клиент DHCP допускает получение параметров от любого сервера DHCP. |
| -k (none|default|key:KEYVALUE) | Опция устанавливает ключ авторизации. Авторизация DHCP проводится в соответствии c “RFC 3118 — Authentication for DHCP Messages”. |
|
-a (none|default|NUMBER) |
Клиент обязан проверить предложенный DHCP-сервером IP-адрес на предмет отсутствия в сети устройств с таким адресом, с этой целью он рассылает ARP-запросы. Данная опция устанавливает количество повторных ARP-запросов, которые проводит клиент DHCP после получения предложения IP-адреса от сервера DHCP. Для надежности клиент DHCP проводит несколько ARP-запросов с интервалом ¼ секунды. Если количество ARP-запросов не определено ни у заданного интерфейса, ни по умолчанию, то клиент DHCP проводит 16 запросов. |
| –c (none|default|CLIENT-CLASS ID) |
Опция устанавливает идентификатор класса клиента DHCP. «CLIENT-CLASS ID» – имя идентификатора. Тип вводимой информации: любая строка (например, «IW-R5000-MESH»). |
| -t (on|off) | Опция включает/отключает вывод отладочной информации в системный журнал. |
|
Имя сетевого интерфейса |
|
| IFNAME | Имя сетевого интерфейса, к которому относятся опции и команды. Если имя интерфейса не указано, устанавливаются параметры по умолчанию. |
|
Команды |
|
| start | Запускает DHCP-клиента на указанном интерфейсе. |
| stop | Останавливает DHCP-клиента на указанном интерфейсе. |
| delete | Останавливает клиента DHCP на указанном интерфейсе и очищает все опции. |
| dump | Отображает текущее состояние клиента DHCP. |
Установка и настройка сервера Openvpn
Давайте перейдем ко второму серверу, чтобы установить и настроить openvpn. Вам также потребуется создать некорневого пользователя на этом сервере и предоставить ему соответствующие привилегии.
Чтобы установить openvpn на ubuntu, выполните следующие команды:
На сервере openvpn утилита easyrsa будет использоваться для генерации запроса сертификата, который будет проверен и подписан сервером центра сертификации (ЦА). Выполните те же действия, что и в предыдущем разделе, чтобы установить Easyrsa.
Теперь распакуйте загруженный файл tgz:
Ограничьте доступ только пользователю:
Переместите EasyRSA-3.0.8 в каталог:
