Строим свой VPN. Часть вторая
Эта статья является неотъемлемой составляющей обширного информационного материала о построении VPN между двумя роутерами на примере оборудования MikroTik.
Первая часть была опубликована в соседней статье. Там была сформулирована задача построения VPN со всеми техническими подробностями.
Исходные данные
- Есть организация: ООО «Ромашка».
- У организации есть домен в интернете: romashka.ru, и им, даже, кто-то управляет. Возможно, даже, на этом домене работает сайт (но к делу это не относится).
- Организация занимается оптово-розничной торговлей палочек для мороженого эскимо.
- У организации есть офис.
- У организации появился (но ещё не открылся) розничный магазин палочек для мороженого.
- У организации есть сервер, и на нём, даже, есть 1С.
- И офис, и розничный магазин должны работать в одной базе 1С.
- Адрес локальной сети для офиса мы выбрали такой:
10.1.1.0/24. У роутера в локальной сети будет IP10.1.1.254 - Для магазина мы выбрали адрес локальной сети такой:
10.1.2.0/24, где IP роутера будет10.1.2.254. - Между двумя конечными точками через публичные IP-адреса устанавливается шифрованное соединение по протоколу IPSec.
- Внутри этого соединения — IPSec-туннеля — оба роутера имеют собственные статические IP-адреса (вообще любые, но в пределах одного адресного пространства).
- Поверх установленного IPSec-туннеля мы создадим другой — GRE-туннель, трафик внутри которого шифровать уже не будем, так как он у нас и без этого зашифрован внутри IPSec
- Трафик от локальной сети офиса в локальную сеть магазина и обратно будем направлять именно в GRE-туннель.
- Способ аутентификации устройств для установки IPSec-соединения выбираем по сертификатам.
- Сеть для IKEv2 IPSec-туннеля:
192.168.99.0/24 - Адрес сети GRE-туннеля между магазином и офисом
172.16.0.0/30 - Наши «лабораторные» роутеры физически находятся в одной локальной сети. Но оба считают её для себя Интернетом.
- «Лабораторный» роутер условного офиса у нас аппаратный MikroTik RB951G-2HnD, а для магазина — виртуальный Cloud Hosted Router так же от MikroTik.
Роутер условного офиса в контексте схему VPN мы будем называть сервером, а роутер условного магазина — клиентом.
Настройка VPN-сервера
Настраивать роутеры мы будем посредством Winbox от MikroTik. Но помимо этого будем приводить примеры указания параметров и командами, выполняемыми с помощью терминала.
Первым делом создаем loopback-интерфейс роутера. Создается он в разделе Bridge.
/interface bridge
add name=ikev2-loopback-iface
Далее, этому интерфейсу мы должны назначить адрес. Мы установили, что адресом сети нашего IPSec-туннеля будет 192.168.99.0/24, в которой у VPN-сервера будет адрес 192.168.99.254. Но здесь же необходимо и не забыть о том, что между роутерами внутри IPSec-туннеля будет устанавливаться GRE-туннель, конечными адресами которого будет адрес VPN-сервера — 192.168.99.254, и адрес VPN-клиента — 192.168.99.1.
В связи с этим, следующим шагом у нас будет создание GRE-интерфейса.
- указывайте понятные имена интерфейсов, которые через несколько месяцев не заставят вас самих гадать о предназначениях;
- MTU установим именно такой;
- локальный адрес — адрес VPN-сервера внутри IPSec-туннеля;
- удаленный адрес — адрес VPN-клиента внутри IPSec-туннеля;
- каждые пять секунд будет проверяться "жизнеспособность" туннеля, чтобы признать туннель нерабочим, роутер предпримет 5 попыток;
- отключаем движение трафика через Fast-path;
- комментарий для интерфейса оставляем тоже "человеческий".
«Фишечка» RouterOS, именуемая как Fasttrack connection, штука хорошая, но как только вы переходите к продвинутым настройкам MikroTik, а всё, что отличается от «да мне просто роутер к интернету подключить», уже можно называть продвинутой настройкой, в общем, Fasttrack connection следует отключать. Поверьте, этот совет сэкономит вам много времени.
Аналогичные параметры можно установить и с помощью терминала.
/interface gre
add allow-fast-path=no comment=\
"=== GRE interface for IPSec tunnel with Store ===" keepalive=5s,5 \
local-address=192.168.99.254 mtu=1427 name=gre-ikev2-ipsec-store \
remote-address=192.168.99.1
В этот момент GRE-туннель, конечно же, будет «мёртв», так как ему нечего и не с чем соединять. Самое время перейти к назначению адресов нашим сетевым интерфейсам: loopback-интерфейсу, и GRE-интерфейсу.
Эти же параметры можно установить с помощью терминала.
/ip address
add address=192.168.99.254 interface=ikev2-loopback-iface network=\
192.168.99.254 comment="=== Loopback-interface Address ==="
add address=172.16.0.1/30 interface=gre-ikev2-ipsec-store network=172.16.0.0 \
comment="=== GRE-interface for via IPSec Address ==="
Настройки IPSec на VPN-сервере
Параметры IPSec внутри Winbox от MikroTik настраиваются внутри раздела IP -> IPSec. Расположение вкладок в нём совсем не соответствует тому порядку, в котором следует создавать параметры подключения. Действовать будем в таком порядке.
- На всех вкладках, где это возможно, отключаем (disable) параметры по умолчанию.
- Mode Configs.
- Groups.
- Profiles.
- Proposals.
- Peers.
- Identities.
- Policies.
Здесь всё, что продемонстрировано, объяснять, в общем-то, не нужно. Параметры достаточно очевидные. Единственное что, в Mode Configs мы включили параметр responder, так как наш VPN-сервер будет исключительно отвечать на запросы подключения, а не инициировать их. Двигаемся дальше
Этот профиль включается в работу на этапе первой фазы согласований между VPN-сервером и VPN-клиентом. Здесь речь ещё не идёт об авторизации, устройства просто «договариваются» о тех алгоритмах шифрования, которые они поддерживают. Если и сервер, и клиент, находят, так сказать, «точки соприкосновения», они устанавливаются первоначальное соединение. Если же между ними компромисс не найден, соединение никогда не будет установлено между этими устройствами.
А здесь мы уже указываем параметры для этапа фазы согласования алгоритмов шифрования при авторизации устройств. Принцип тот же, что и на предыдущем этапе, отличие лишь в том, что устройства, «договорившиеся» здесь, могут считать друг друга авторизованными.
Читателю следует понять, что в контексте IKEv2 IPSec, несмотря на то, что есть такие понятия как сервер и клиент, авторизация здесь обоюдная. То есть не клиент авторизуется на сервере, а клиент подтверждает свою подлинность перед сервером, а сервер, в свою очередь — свою перед клиентом.
- пира мы создаем общего; через него могут пытаться подключиться к серверу отовсюду и кто угодно; решение об авторизации клиента принимается на этапе его идентификации;
- так как сервер у нас только отвечает на подключение, не инициирует их, пир указывается как пассивный;
- метод аутентификации при создании Identity выбираем digital signature — по сертификату;
- сертификатом устройства указываем сертификат роутера в офисе, а сертификатом удаленного устройства (клиента) — сертификат магазина;
- совпадение указываем по сертификату — если клиент предоставил нам именно этот сертификат, считаем, что это и есть роутер магазина.
- так как сервер у нас лишь принимает соединения, мы создаем шаблонные политики, по которым сервер будет сличать подключающихся клиентов;
- указываем ранее созданную группу, к которой будут отнесены все подключения, соответствующие шаблону политики;
- в качестве адресов исходящих и входящих подключений указываем всю сеть IPSec
192.168.99.0/24; - мы не собираемся принимать все подряд входящие подключения, нас интересуют только те, которые будут направлены через GRE-туннель; в связи с этим мы указываем номер конкретного протокола — 47 (GRE);
- добавляем к шаблону политики понятный нам самим комментарий;
- на вкладке Action указываем использование ранее созданных Proposals.
А теперь всё то же самое, но в терминале.
/ip ipsec mode-config
add address=192.168.99.1 name=ikev2-ipsec-store
/ip ipsec policy group
add name=ikev2-ipsec-common-group-devices
/ip ipsec profile
add dh-group=ecp256,modp2048 dpd-interval=10s dpd-maximum-failures=3 \
enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name=\
PHASE_1_ikev2-ipsec-common-profile proposal-check=strict
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add auth-algorithms=sha512,sha256 enc-algorithms=\
chacha20poly1305,aes-256-cbc,aes-256-gcm,aes-192-cbc,aes-192-gcm \
lifetime=3h name=PHASE_2_ikev2-ipsec-common pfs-group=modp2048
/ip ipsec peer
add comment="=== Common peer for incoming IPSec connections ===" \
exchange-mode=ike2 name=ikev2-ipsec-common-peer-responder passive=yes \
profile=PHASE_1_ikev2-ipsec-common-profile send-initial-contact=no
/ip ipsec identity
add auth-method=digital-signature certificate="Romashka ltd IKEv2 VPN Server" \
comment="=== Identity for Store VPN connection ===" generate-policy=\
port-strict match-by=certificate mode-config=ikev2-ipsec-store peer=\
ikev2-ipsec-common-peer-responder policy-template-group=\
ikev2-ipsec-common-group-devices remote-certificate=\
"Romashka ltd IKEv2 Store VPN Client"
/ip ipsec policy
set 0 disabled=yes
add comment="=== Policy template for Authorization common devices ===" \
dst-address=192.168.99.0/24 group=ikev2-ipsec-common-group-devices \
proposal=PHASE_2_ikev2-ipsec-common protocol=gre src-address=\
192.168.99.0/24 template=yes
На сервере больше настраивать нечего. Переходим к настройке клиента — роутера магазина.
Настройка роутера VPN-клиента
Здесь нам loopback-интерфейс не нужен, поэтому обходимся созданием GRE-интерфейса, и указанием его IP-адреса.
- MTU установим именно такой;
- локальный адрес — адрес VPN-клиента внутри IPSec-туннеля;
- удаленный адрес — адрес VPN-сервера внутри IPSec-туннеля;
- каждые пять секунд будет проверяться "жизнеспособность" туннеля, чтобы признать туннель нерабочим, роутер предпримет 5 попыток;
- отключаем движение трафика через Fast-path;
- для интерфейса устанавливаем адрес
172.16.0.2/30, тем самым, мы изолируем устройства этого туннеля от других возможных туннелей.
Аналогичные параметры можно установить и с помощью терминала.
/interface gre
add allow-fast-path=no keepalive=5s,5 local-address=192.168.99.1 mtu=1427 \
name=gre-ikev2-ipsec-office-router remote-address=192.168.99.254
/ip address
add address=172.16.0.2/30 interface=gre-ikev2-ipsec-office-router network=\
172.16.0.0
И снова, здесь, в том числе, в этот момент GRE-туннель, конечно же, будет «мёртв», так как ему нечего и не с чем соединять.
Настройки IPSec на VPN-клиенте
Порядок настройки разделов и параметров для клиента аналогичен серверу. Несколько отличий будут видны внутри при настройке
- На всех вкладках, где это возможно, отключаем (disable) параметры по умолчанию.
- Mode Configs.
- Groups.
- Profiles.
- Proposals.
- Peers.
- Identities.
- Policies.
И здесь всё, что продемонстрировано, объяснять, в общем-то, не нужно. Параметры достаточно очевидные. Двигаемся дальше.
Параметры профиля идентичны параметрам профиля на VPN-сервере.
И здесь параметры идентичны тем, что на VPN-сервере.
Здесь стоит дать пояснения, так как очевидны отличия от настроек пира на VPN-сервере.
- Пир у нас на клиенте активный. Он инициирует подключение к серверу. Passive здесь отключаем, а Send INITIAL_CONTACT включаем.
- В поле Address указываем либо доменное имя, либо IP-адрес VPN-сервера. Если у вас несколько провайдеров, в поле Local Address можете указать конкретный публичный IP-адрес, который вам выделил провайдер.
Продолжаем...
- метод аутентификации при создании Identity выбираем digital signature — по сертификату;
- сертификатом устройства указываем сертификат роутера в магазине, а сертификатом удаленного устройства (клиента) — сертификат офиса;
- совпадение указываем по сертификату — если сервер предоставил нам именно этот сертификат, считаем, что это и есть роутер офиса.
- политику здесь создаем уже под конкретные адреса устройств на концах туннеля;
- указываем ранее созданную группу, к которой будут отнесены все подключения, соответствующие шаблону политики;
- мы не собираемся шифровать все подряд входящие подключения, нас интересуют только те, которые будут направлены через GRE-туннель; в связи с этим мы указываем номер конкретного протокола — 47 (GRE);
- на вкладке Action указываем использование ранее созданных Proposals.
Теперь всё то же самое, но через терминал.
/ip ipsec mode-config
add name=ikev2-ipsec-office responder=no use-responder-dns=no
/ip ipsec policy group
add name=ikev2-ipsec-common-group-devices
/ip ipsec profile
add dh-group=ecp256,ecp384,modp2048 dpd-interval=10s dpd-maximum-failures=3 \
enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name=\
PHASE_1_ikev2-ipsec-common-profile proposal-check=strict
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add auth-algorithms=sha512,sha256 enc-algorithms="chacha20poly1305,aes-256-cbc\
,aes-256-gcm,aes-192-cbc,aes-192-gcm,aes-128-cbc" lifetime=3h name=\
PHASE_2_ikev2-ipsec-common pfs-group=modp2048
/ip ipsec peer
add address=10.15.17.100/32 comment=\
"=== IKEv2 IPSec Office peer connection ===" disabled=yes exchange-mode=\
ike2 name=ikev2-ipsec-office-peer profile=\
PHASE_1_ikev2-ipsec-common-profile
/ip ipsec identity
add auth-method=digital-signature certificate=\
"Romashka ltd IKEv2 Store VPN Client" comment=\
"=== Identity for Office VPN Server ===" generate-policy=port-strict \
match-by=certificate mode-config=ikev2-ipsec-office peer=\
ikev2-ipsec-office-peer policy-template-group=\
ikev2-ipsec-common-group-devices remote-certificate=\
"Romashka ltd IKEv2 VPN Server"
/ip ipsec policy
set 0 disabled=yes
add dst-address=192.168.99.254/32 peer=ikev2-ipsec-office-peer proposal=\
PHASE_2_ikev2-ipsec-common protocol=gre src-address=192.168.99.1/32 \
tunnel=yes
Так как роутер приобретается надолго, не стоит останавливать свой выбор только лишь на озвученной выше модели. Лучше добавить средства, и приобрести более мощное устройство, в котором присутствует аппаратная поддержка современных алгоритмов шифрования. Почему это важно? Потому что в VPN, о котором идёт речь, данные стоит передавать в зашифрованном виде, чтобы в случае их перехвата злоумышленник не имел простых способов доступа к ним.
Роутеры MikroTik могут и не иметь аппаратную поддержку алгоритмов шифрования, но поддерживать их. Но это очень ощутимо будет бить не просто по производительности роутера, а вообще по его работоспособности.
Информация об аппаратной поддержке алгоритмов шифрования опубликована на сайте производителя. К примеру, озвученная выше модель роутера вообще отсутствует в этой сравнительной таблице, что даёт основания полагать об аппаратной поддержке лишь устаревших md5 и sha1, а это повлечёт за собой очень высокую нагрузку на процессор. А вот, например, hEX S уже значительно лучше, но не идеален.
Результат настройки
Если вы всё сделали верно, то после последнего шага, созданная политика на "клиенте" должна получить статус established, а на сервере должна появиться активная динамическая политика. Должен пойти трафик внутри IPSec-туннеля, и через GRE-интерфейс
Вот, что у нас на VPN-клиенте
А вот, что у нас на VPN-сервере
Последний скриншот ярко демонстрирует все «прелести» отсутствия аппаратной поддержки алгоритмов шифрования в роутере RB951G-2HnD. Трафик внутри туннеля передается, всего-навсего, на скорости около 30 мбит/с, но процессор роутера уже загружен на 100%. Выше скорость не просто не поднимется, она будет падать, и периодически при такой нагрузке будут, даже, наблюдаться потери пакетов.
Что же, в итоге, можно делать с таким VPN? Да что угодно. Дальше дело только за вашей фантазией. Хотите — обеспечивайте возможность подключения компьютеров магазина к компьютерам и серверам офиса. Для этого, всего лишь, нужно добавить в роутеры соответствующие маршруты. Статические, или же с помощью протоколов динамической маршрутизации, уже вам решать.
Данная статья не охватывает вопросы обеспечения сетевой безопасности на уровне устройства. Автор оставляет эту задачу в зоне ответственности читателя. Способы маршрутизации клиентского трафика в этом материале также не рассматриваются.
Если вам требуется реализовать какие-либо задачи с вашим сетевым оборудованием, вы всегда можете просто обратиться к нам.
У нас появился официальный канал в мессенджере Макс. Приглашаем всех желающих подписываться и читать.