Mikrotik ipsec tunnel настройка firewall
Interface Lists
Two interface lists will be used WAN and LAN for easier future management purposes. Interfaces connected to the global internet should be added to the WAN list, in this case, it is ether1!
Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам
Сейчас, когда многие настраивают VPN для работы удаленных сотрудников, выбор протокола становится как никогда актуальным. С одной стороны стоят поддерживаемые современными ОС протоколы PPTP и L2TP, которые имеют ряд существенных недостатков и ограничений, с другой OpenVPN, который всем хорош, но требует установки стороннего ПО. При этом как-то забывают о быстром и безопасном IKEv2, основанном на IPsec новом протоколе, также поддерживаемом всеми современными ОС.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Почему именно IKEv2? Данный протокол входит в группу протоколов IPsec и обеспечивает высокий уровень безопасности, включая аутентификацию клиента с использованием сертификата, а также проверку подлинности сервера клиентом, что исключает атаки типа "человек посередине". При поддержке аппаратного ускорения IPsec со стороны оборудования показывает хорошую скорость соединения относительно других типов VPN в RouterOS и весьма прост в настройке с клиентской стороны, не требует добавления маршрутов.
К недостаткам можно отнести достаточную сложность настройки серверной части, которая требует выполнения определенных условий и наличия базового объема знаний о работе IPsec. В данной статье мы не будем углубляться в теорию, сделав упор на практическую сторону вопроса, ограничившись краткими пояснениями необходимости тех или иных настроек.
Настройка маршрутизации
Итак, туннель поднят, теперь нужно пустить в него трафик между сетями. Прежде всего присвоим адреса туннельным интерфейсам. Согласно схеме со стороны роутера А это будет 10.10.10.1, а со стороны роутера B - 10.10.10.2. Переходим в IP - Addresses и добавляем новый адрес: Address - 10.10.10.1/24 - именно так, с указанием префикса (/24, что соответствует маске 255.255.255.0), в противном случае сеть у вас работать не будет. В поле Interface указываем имя интерфейса GRE или IPIP-туннеля.
В терминале для этого же действия выполните команду:
Где вместо interface=gre-tunnel1 укажите имя собственного туннельного интерфейса.
Аналогичные настройки следует выполнить и на втором роутере.
Теперь приступим к указанию маршрутов, для роутера A нам нужно указать маршрут к сети 192.168.222.0/24 через туннель. Переходим в IP - Routes и создаем новый маршрут. В качестве Dst. Address указываем сеть назначения - 192.168.222.0/24, в поле Gateway указываем шлюз в эту сеть - противоположный конец туннеля, который имеет адрес 10.10.10.2, после того как мы нажмем Apply в поле рядом со шлюзом появится исходящий интерфейс, в качестве которого будет выступать наш туннель.
На втором роутере делаем аналогичные настройки с учетом IP-адреса роутера и сети назначения.
После чего пробуем получить из одной сети доступ к узлу другой. Если все сделано правильно, то попытка увенчается успехом.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Настройка брандмауэра
Будем считать, что вы используете нормально закрытый брандмауэр настроенный в соответствии с нашими рекомендациями. Для того, чтобы разрешить входящее IPsec-соединение перейдем в IP - Firewall - Filter Rules и добавим следующие правила. Первое из них разрешает работу протокола обмена ключами IKE: Chain - input, Protocol - udp, Dst. Port - 500,4500, In. Interface - внешний интерфейс, в нашем случае ether1.
Второе правило разрешает протокол шифрования полезной нагрузки Encapsulating Security Payload (ESP): Chain - input, Protocol - 50 (ipsec-esp), In. Interface - внешний интерфейс - ether1.
Обратите внимание, что мы нигде не указываем действие, потому что по умолчанию все правила имеют в качестве действия accept - разрешить.
Эти же действия можно быстро выполнить в терминале:
Для того, чтобы пакеты из одной сети могли попасть в другую, следует разрешить их транзит. Создадим еще одно правило: Chain - forward, In. Interface - внешний интерфейс - ether1, затем на закладке Advanced укажем IPsec Policy - in:ipsec. Это разрешит транзит любых входящих пакетов, которые попадают под любую установленную политику IPsec.
В терминале:
Аналогичные настройки следует выполнить на втором узле.
Protect the Clients
Before the actual set of rules, let's create a necessary address-list that contains all IPv4/6 addresses that cannot be forwarded.
Notice that in this list multicast address range is added. It is there because in most cases multicast is not used. If you intend to use multicast forwarding, then this address list entry should be disabled.
In the same case for IPv6, if multicast forwarding is used then the multicast entry should be disabled from the address-list.
Forward chain will have a bit more rules than input:
- accept established, related and untracked connections;
- FastTrack established and related connections (currently only IPv4);
- drop invalid connections;
- drop bad forward IP`s, since we cannot reliably determine in RAW chains which packets are forwarded
- drop connections initiated from the internet (from the WAN side which is not destination NAT`ed);
- drop bogon IP`s that should not be forwarded.
We are dropping all non-dstnated IPv4 packets to protect direct attacks on the clients if the attacker knows the internal LAN network. Typically this rule would not be necessary since RAW filters will drop such packets, however, the rule is there for double security in case RAW rules are accidentally messed up.
IPv6 forward chain is very similar, except that IPsec and HIP are accepted as per RFC recommendations and ICMPv6 with hop-limit=1 is dropped.
Notice the IPsec policy matcher rules. It is very important that IPsec encapsulated traffic bypass fast-track. That is why as an illustration we have added a disabled rule to accept traffic matching IPsec policies. Whenever IPsec tunnels are used on the router this rule should be enabled. For IPv6 it is much more simple since it does not have fast-track support.
Another approach to solving the IPsec problem is to add RAW rules, we will talk about this method later in the RAW section
Обход NAT и Fasttrack
Как мы уже говорили, IPsec не использует интерфейсы, а следовательно, обрабатываемый им трафик, хоть и уходит в защищенный туннель, но продолжает использовать в качестве исходящего внешний интерфейс, что может привести к ряду коллизий. Прежде всего нужно исключить обработку такого трафика правилами snat или masquerade. Для этого перейдем в IP - Firewall - NAT и создадим новое правило: Chain - srcnat, Src. Address - 192.168.111.0/24 - диапазон локальной сети, Dst. Address - 192.168.186.0/24 - диапазон удаленной сети, так как действие по умолчанию accept, то явно его не указываем. Данное правило поднимаем в самый верх, одно должно быть первым в цепочке srcnat.
Через терминал добавить его можно следующей командой:
Опция place-before=0 позволяет поставить правило в самое начало цепочки.
Если вы используете Fasttrack, то также следует исключить обработку проходящего через IPsec трафика этим механизмом, для этого следует добавить два правила. Первое для трафика из локальной сети в удаленную: Chain - forward, Src. Address - 192.168.111.0/24 - диапазон локальной сети, Dst. Address - 192.168.186.0/24 - диапазон удаленной сети, Сonnection State - established, related.
Второе правило для трафика из удаленной сети в локальную, оно полностью повторяет первое, только меняем местами сеть источника (Src. Address) и сеть назначения (Dst. Address).
Аналогичные настройки, с учетом адресов, следует выполнить и на втором узле.
Настройка IPsec соединения
Соединение IPsec имеет отличия как от предусматривающего клиент-серверную схему VPN, так и от stateless туннелей. В отличие от последних мы всегда можем проверить состояние соединения, но понятие клиента и сервера здесь отсутствует, в IPsec одно из устройств выступает в качестве инициатора (initiator), а второе в качестве ответчика (responder). Эти роли не являются жестко закрепленными и могут меняться между устройствами, хотя при необходимости мы можем закрепить за определенным устройством постоянную роль.
Например, это позволяет установить IPsec соединение, когда один из узлов не имеет выделенного IP-адреса, в этом случае ему следует настроить роль инициатора, а второму узлу роль ответчика. В нашем случае подразумевается наличие выделенных адресов с обоих сторон и каждое из устройств может выступать в любой роли.
Настройку начнем с определения алгоритмов шифрования для каждой фазы соединения. Так как мы соединяем два собственных устройства, то можем не оглядываться на требования совместимости и настроить параметры шифрования на собственное усмотрение. Но без фанатизма, не забываем, что многие устройства Mikrotik достаточно слабые и не имеют аппаратной поддержки шифрования, а те, которые имеют, поддерживают различный набор протоколов.
Так популярный RB750Gr3 (hEX) поддерживает аппаратное ускорение только SHA1/SHA256 - AES-CBC, а более новый RB3011 уже поддерживает SHA1/SHA256 - AES-CBC и SHA1/SHA256 - AES-CTR. Желание использовать сильные шифры безусловно похвально, но оно не должно опережать возможности имеющегося оборудования.
Первая фаза - обмен ключами и взаимная идентификация устройств, за ее настройки отвечает раздел IP - IPsec - Profiles, перейдем в него и создадим новый профиль. Для него укажем: Hash Algorithms - sha1, Encryption Algorithm - aes-256, DH Group - ecp384. В поле Name укажем имя профиля, в нашем случае ipsec-sts (site-to-site).
В терминале для выполнения этого же действия выполните:
Это достаточно сильные настройки шифров, для устройств без аппаратного ускорения мы бы посоветовали ограничиться aes-128 и modp1024, хотя никто не мешает протестировать желаемые варианты и остановиться на наиболее оптимальном.
Вторая фаза - установление защищённого соединения и передача данных, настройки шифров для нее задаются в IP - IPsec - Proposal, перейдем в данный раздел и создадим новое предложение. Укажем Auth. Algorithms - sha1, Encr. Algorithms - aes-256-cbc, PFS Group - ecp384.
Это же действие в терминале:
В данном примере мы использовали не самые сильные шифры, так режим шифрования CBC является наиболее слабым и при наличии аппаратной поддержки стоит использовать CTR или GCM. Но не забывайте о достаточной разумности, если нагрузка на устройство велика - понижайте уровень шифрования.
Теперь перейдем в IP - IPsec - Peer и создадим новое подключение. В поле Address указываем внешний адрес второго роутера, в Profile выбираем созданный нами на предыдущем этапе профиль, в нашем случае ipsec-sts, а в поле Exchange Mode указываем IKE2.
В терминале:
В целом того, что мы уже настроили достаточно для установления защищенного соединения, но IPsec не VPN и работает по-другому. Для того, чтобы трафик начал шифроваться он должен соответствовать одной из политик IPsec, поэтому перейдем в IP - IPsec - Policies и создадим новую политику. В поле Peer укажем созданное ранее соединение, ниже установим флаг Tunnel для работы соединения в туннельном режиме, в поле Src. Address укажем диапазон собственной сети - 192.168.111.0/24, а в поле Dst. Address - диапазон удаленной сети - 192.168.186.0/24.
Затем на закладке Action установите Proposal - ipsec-sts, предложение которое мы создали ранее.
Для терминала используйте следующие команды:
Ну и осталось совсем немного - научить узлы идентифицировать друг друга, так как оба роутера контролируются администратором и настроены принимать подключения только от другого узла, то мы будем использовать аутентификацию по предварительному ключу. Перейдем в IP - IPsec - Identities и создадим новую настройку идентификации. Здесь нам нужно заполнить поля: Peer - указываем созданное нами соединение, в нашем случае ipsec-sts, Auth. Method - pre shared key, Secret - предварительный ключ. В качестве предварительного ключа рекомендуется использовать строку с использованием цифр, букв в разных регистрах и специальных символов, сформированных в случайном порядке и с длинной не менее 16-32 символов. Не следует использовать в качестве ключа словарные слова и фразы. Предупреждения внизу окна можно проигнорировать.
В терминале:
На втором узле следует выполнить аналогичные настройки, только в качестве адреса в Peer указав внешний адрес первого роутера, а в Policy поменяв местами сеть источника и сеть назначения.
Masquerade Local Network
For local devices behind the router to be able to access the internet, local networks must be masqueraded. In most cases, it is advised to use src-nat instead of masquerade, however in this case when the WAN address is dynamic it is the only option.
Notice the disabled policy matcher rule, the same as in firewall filters IPSec traffic must be excluded from being NATed (except specific scenarios where IPsec policy is configured to match NAT`ed address). So whenever IPsec tunnels are used on the router this rule must be enabled.
IPv6 Address Lists
List of IPv6 addresses that should be dropped instantly
List of IPv6 addresses that are not globally routable
List of addresses as an invalid destination address
List of addresses as an invalid source address
Настройка подключения клиента в Windows
Прежде всего импортируем сертификат, для этого можно просто выполнить двойной клик на файле сертификата, в открывшемся Мастере импорта в качестве Расположения хранилища укажите Локальный компьютер, остальные параметры принимаются по умолчанию.
Затем создадим новое подключение штатными инструментами. А качестве Типа VPN укажем IKEv2, а в качестве Типа данных для входа - Сертификат. Также обратите внимание, что в строка Имя или адрес сервера должно совпадать с Common Name сертификата сервера, в противном случае подключение установить не удастся.
После чего откроем свойства созданного подключения и перейдем на закладку Безопасность, где установим переключатель Проверка подлинности в положение Использовать сертификаты компьютеров.
Теперь можно подключаться, если все сделано правильно - подключение будет успешно. Проверим таблицу маршрутов:
Как видим, маршрут к нашей внутренней сети 192.168.111.0/24 был добавлен автоматически и никаких ручных настроек клиента не требуется.
Настраиваем IPsec-туннель между офисами на оборудовании Mikrotik
Задача объединения нескольких сетей в разных офисах одна из наиболее часто встречающихся у системных администраторов. Для ее решения могут использоваться различные виды VPN и туннельных соединений, выбор которых может зависеть от множества требований и условий. Одной из альтернатив туннелям и VPN может служить "чистое" IPsec-соединение, которое имеет как свои достоинства, так и недостатки. В данном материале мы рассмотрим реализацию подобного соединения между сетями офисов (site-to-site) c использованием оборудования Mikrotik.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
IPsec - набор протоколов для обеспечения защиты данных, передаваемых в сетях по протоколу IP. Основным преимуществом IPsec является высокий уровень безопасности, на сегодняшний день он является лучшим протоколом для защиты передаваемых данных. Также следует отметить высокий уровень производительности, при условии достаточного количества вычислительных ресурсов для работы с криптографией. Применительно к устройствам Mikrotik IPsec позволяет получить одни из самых высоких результатов, особенно на устройствах с аппаратной поддержкой шифрования.
Но есть и недостатки, они тоже достаточно существенны. IPsec сложен, как в настройке, так в понимании его работы, это требует от администратора более глубокого уровня знаний и может вызвать серьезные затруднения при отладке и диагностике неисправностей. Также IPsec не использует интерфейсы, а обрабатывает трафик на основании собственных политик, это также приводит к ряду затруднений, начиная от прохождения трафика через брандмауэр и заканчивая невозможностью применения маршрутизации для таких соединений. Часть сетевых конфигураций легко реализуемых при помощи VPN и туннелей построить при помощи IPsec в принципе невозможно.
Далее мы рассмотрим объединение двух офисных сетей по представленной ниже схеме:
Где LAN 1 с диапазоном 192.168.111.0/24 и LAN 2 - 192.168.186.0/24 - это сети двух офисов, которые мы будем объединять, а 192.168.3.107 и 192.168.3.111 - выполняют роль внешних белых адресов в сети интернет. Наша задача обеспечить прозрачный доступ устройств одной сети в другую через защищенный канал связи.
IPv4 RAW Rules
Raw IPv4 rules will perform the following actions:
- add disabled "accept" rule - can be used to quickly disable RAW filtering without disabling all RAW rules;
- accept DHCP discovery - most of the DHCP packets are not seen by an IP firewall, but some of them are, so make sure that they are accepted;
- drop packets that use bogon IP`s;
- drop from invalid SRC and DST IP`s;
- drop globally unroutable IP`s coming from WAN;
- drop packets with source-address not equal to 192.168.88.0/24 (default IP range) coming from LAN;
- drop packets coming from WAN to be forwarded to 192.168.88.0/24 network, this will protect from attacks if the attacker knows internal network;
- drop bad ICMP, UDP, and TCP;
- accept everything else coming from WAN and LAN;
- drop everything else, to make sure that any newly added interface (like PPPoE connection to service provider) is protected against accidental misconfiguration.
Notice that we used some optional chains, the first TCP chain to drop TCP packets known to be invalid.
And another chain for ICMP. Note that if you want a very strict firewall then such strict ICMP filtering can be used, but in most cases, it is not necessary and simply adds more load on the router's CPU. ICMP rate limit in most cases is also unnecessary since the Linux kernel is already limiting ICMP packets to 100pps.
Как настроить VPN L2TP+IpSec между MikroTik и VPS CentOS 8
Весь комплекс настройки будет разделен два два этапа:
Настройка GRE-туннеля
Открываем Winbox и переходим в Interfaces - Interface где добавляем новый интерфейс с типом GRE Tunnel, в открывшемся окне заполняем поля: Local Address - внешний IP-адрес этого роутера, Remote Address - внешний IP-адрес противоположного роутера, IPsec Secret - общий ключ IPsec, рекомендуется использовать длинную случайную строку из цифр, букв в обоих регистрах и спецсимволов. Также обязательно снимите флаг Allow Fast Path.
В терминале это можно выполнить командой:
Полностью аналогичную настройку выполняем и на втором роутере, только меняем местами Local Address и Remote Address, после чего туннель должен перейти в рабочее состояние. За отслеживание состояние туннеля отвечает параметр Keepalive, по умолчанию он предполагает десять попыток с интервалов в 10 секунд, если за это время с противоположной стороны не будет получен ответ, то туннель будет считаться неработоспособным.
Важный момент связан с настройками IPsec, RouterOS использует для туннелей настройки по умолчанию и нет возможности это переопределить, поэтому на обоих роутерах профили default в IP - IPsec - Proposals и Profiles должны иметь одинаковые настройки.
В противном случае вы будете получать ошибку при согласовании параметров IPsec:
Если все сделано правильно, то в Interfaces - Interface напротив туннеля появится флаг R - running, что означает, что туннель находится в рабочем состоянии.
Protect the Device
The main goal here is to allow access to the router only from LAN and drop everything else.
Notice that ICMP is accepted here as well, it is used to accept ICMP packets that passed RAW rules.
IPv6 part is a bit more complicated, in addition, UDP traceroute, DHCPv6 client PD, and IPSec (IKE, AH, ESP) is accepted as per RFC recommendations.
1. Настройка VPN сервера L2TP на удаленном VPS сервере на CentOS 8
Подключение к удаленному серверу VPS будет производиться через SSH:
создание скрипта по установке и настройке VPN сервера L2TP+IpSec
Поддержи автора статьи, сделай клик по рекламе ↓↓↓
Если потребует изменить параметры сетевой адресации, нужно обратить внимание на этот раздел
По окончанию работы скрипт выводит параметры, которые нужно использовать на MikroTik L2TP клиенте:
Файл xl2tpd.conf содержит настройки VPN сервера:
добавить маршрут в сеть за MikroTik. Это правило будет отрабатывать каждый раз, когда туннель будет подниматься
192.168.10.0/24 – сеть за MikroTik
192.168.41.10 – адрес MikroTik на стороне CentOS 8.
IPv4 Address Lists
Before setting RAW rules, let's create some address lists necessary for our filtering policy. RFC 6890 will be used as a reference.
First, address-list contains all IPv4 addresses that cannot be used as src/dst/forwarded, etc. (will be dropped immediately if such address is seen)
Another address list contains all IPv4 addresses that cannot be routed globally.
And last two address lists for addresses that cannot be as destination or source address.
Создание центра сертификации и выпуск сертификатов
Когда мы говорим об использовании сертификатов для аутентификации, то подразумеваем наличие инфраструктуры открытых ключей (PKI), образующей область доверия, за счет чего появляется возможность проверки подлинности любого субъекта инфраструктуры без привлечения третьих служб и списков пользователей. В основе PKI лежит центр сертификации - CA, выпускающий сертификаты и дающий возможность убедиться в их подлинности при помощи корневого публичного сертификата.
В нашем случае центр сертификации будет создан средствами RouterOS прямо на маршрутизаторе. Для этого перейдем в System - Certificate и выпустим корневой сертификат нашего CA.
Красным указаны обязательные к заполнению поля. Name - видимое имя сертификата и Common Name - имя субъекта, которому выдан сертификат, в нашем случае это ca. Key Size - размер ключа, ключи размером менее 2048 байт не считаются безопасными, Days Valid - время действия сертификата, в нашем случае 10 лет.
Выделенный зеленым блок не является обязательным, но мы советуем его заполнять, дабы в дальнейшем не пришлось угадывать, что это за сертификат и кому и кем он выдан.
Затем перейдем на закладку Key Usage и оставим только crl sign и key cert. sign, затем нажмем Apply, чтобы применить изменения, после чего подпишем сертификат. нажав кнопку Sign, в открывшемся окне укажем CA CRL Host, в качестве которого следует использовать один из IP-адресов роутера.
В терминале эти же действия можно выполнить командой:
Следующим шагом выпустим сертификат сервера. Обратите внимание, что сервер обязательно должен иметь выделенный IP адрес и, желательно, доменное имя. Последнее условие не является обязательным, но предпочтительно, так как позволит отвязаться от использования адреса и в случае изменения IP вам не придется перевыпускать сертификаты и менять настройки клиентских подключений.
Заполнение полей в целом повторяет предыдущий пример, за исключением Common Name и Subject Alt. Name. Здесь мы указываем IP-адрес или FQDN по которому клиенты будут подключаться к серверу. Если вы используете IP-адрес, то тип записи в поле Subject Alt. Name нужно сменить на IP.
Обратите внимание, если вы выпустили сертификат с указанием FQDN, а подключить клиента попытаетесь по IP-адресу, либо наоборот, то такое соединение окажется невозможным.
На закладке Key Usage укажем единственное значение tls server и подпишем наш сертификат закрытым ключом центра сертификации CA.
Эти же действия в терминале:
Теперь можно выпускать клиентские сертификаты, это можно сделать как сразу, так и потом. Никаких особых требований здесь нет, в качестве имени указывайте максимально понятное значение, скажем, ФИО сотрудника или наименование офиса. Потому как понять кому принадлежит сертификат с CN IvanovIA не составит особого труда, в отличие от какого-нибудь безликого client3. Также обратите внимание на опцию Days Valid, не следует выдавать клиентские сертификаты на большой срок.
В Key Usage также указываем единственное назначение сертификата - tls client и подписываем его закрытым ключом CA.
Команды для терминала:
Для использования на клиентских устройствах сертификаты следует экспортировать, наиболее удобно использовать для этого формат PKCS12, который в одном файле содержит закрытый ключ клиента, его сертификат и корневой сертификат CA. Для этого выберите сертификат в списке и в меню правой кнопки мыши укажите действие Export. В поле Type укажите PKCS12, а в Export Passphrase следует указать пароль (не менее 8 символов), в противном случае закрытый ключ выгружен не будет.
Это же можно сделать командой:
Настройка VPN L2TP+IpSec между VPS CentOS 8 и MikroTik
Большая доля серверной инфраструктуры имеет облачное размещение в виде VPS и VDS серверов, одним из требованием к которой является организация удаленного доступа через защищенные каналы. Данным каналом будет выступать VPN туннель на базе L2TP+IpSec.
В прошлых инструкция рассматривались разные разновидности VPN серверов:
А данная конфигурация будет отличаться тем, что одним из звеньев VPN туннеля будет облачный VPS на CentOS 8.
2. Настройка L2TP клиента на MikroTik
Со стороны MikroTik нужно затронуть два раздела: PPP клиент и маршрутизацию.
Добавление L2TP клиента
Настройка находится в PPP→Interface
Успешное соединение, сопровождается статусом “R”
Добавить статический маршрут. Весь интернет трафик будет заворачиваться в VPN туннель через CentOS VPS
Настройка находится в IP→Routes
А у прежнего интернет маршрута, необходимо понизить Distance до 2
Таким образом весь интернет трафик будет заворачиваться на удаленный VPS, а если связь с сервером будет отсутствовать, то маршрутизация переключится на интернет провайдера.
Поддержи автора статьи, сделай клик по рекламе ↓↓↓
Есть вопросы или предложения по настройке VPN типа L2TP+IpSec между MikroTik и CentOS? Активно предлагай свой вариант настройки! Оставить комментарий →
adminse
IPv6 RAW Rules
Raw IPv6 rules will perform the following actions:
- add disabled accept rule - can be used to quickly disable RAW filtering without disabling all RAW rules;
- drop packets that use bogon IPs;
- drop from invalid SRC and DST IPs;
- drop globally unroutable IPs coming from WAN;
- drop bad ICMP;
- accept everything else coming from WAN and LAN;
- drop everything else, to make sure that any newly added interface (like PPPoE connection to service provider) is protected against accidental misconfiguration.
Notice that the optional ICMP chain was used. If you want a very strict firewall then such strict ICMP filtering can be used, but in most cases, it is not necessary and simply adds more load on the router's CPU. ICMP rate limit in most cases is also unnecessary since the Linux kernel is already limiting ICMP packets to 100pps
Одна из наиболее часто решаемых системным администратором задач - объединение нескольких сетей в единое пространство, для обеспечения совместной работы с общими ресурсами (site-to-site). Обычно для этих целей используется VPN, тип которого большой роли не играет. Но именно для данной задачи более предпочтительно использовать IPIP или GRE-туннели, особенно если вам требуется хорошая пропускная способность соединения. В данной статье мы расскажем об особенностях настройки и использования данного вида подключений.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Сначала коротко о протоколах. GRE (Generic Routing Encapsulation - общая инкапсуляция маршрутов) - протокол инкапсуляции, разработан компанией Cisco и предназначен для инкапсуляции пакетов сетевого уровня (L3) в IP-пакеты. IPIP (IP Encapsulation within IP - инкапсуляция IP в IP) во многом похож на GRE, но работает только с IPv4-трафиком. Наиболее популярным и используемым протоколом является GRE, его поддержка присутствует во всех современных ОС и сетевом оборудовании. Mikrotik поддерживает оба вида туннелей.
Туннели, созданные с помощью данных протоколов, не имеют никаких механизмов обеспечения безопасности (шифрование, аутентификация), поэтому в чистом виде они практически не используются. Для обеспечения нужного уровня безопасности используется IPsec, поверх которого уже разворачивается GRE или IPIP-туннель ( GRE over IPsec, IPIP over IPsec). Далее, говоря о данном типе туннелей мы будем подразумевать ввиду именно их.
Еще одна особенность указанных протоколов - они работают без сохранения состояния соединения (stateless) и понять в каком состоянии находится туннель невозможно. Мы можем только настроить обе стороны и проверить передачу данных между ними. Кроме очевидных минусов такое решение имеет и свои плюсы, GRE или IPIP-интерфейсы являются статичными и присутствуют в системе вне зависимости от состояния туннелей, что облегчает настройку маршрутизации. А состояние туннеля позволяют контролировать механизмы RouterOS, которые с заданной периодичностью умеют проверять доступность его второго конца.
Ни GRE, ни IPIP не используют порты, поэтому они не могут преодолеть NAT, это требует от обоих узлов иметь выделенные IP-адреса или находиться в одной сети. Проблема NAT частично снимается при использовании IPsec, за счет использования протокола NAT-T, но требование выделенных адресов узлов остается. Кроме того, по этой причине вы не сможете установить более одного GRE или IPIP-соединения между узлами.
Итак, подведем коротко итог: для использования GRE или IPIP-туннелей вам потребуются выделенные IP-адреса с обоих сторон и для защиты передаваемых данных обязательно использовать IPsec. Что касается оборудования, то предпочтительно использовать роутеры с аппаратной поддержкой шифрования - hEX, RB3011/4011 и все остальные модели на базе процессоров ARM. В этом случае вполне достижима пропускная способность туннеля на уровне 300-400 МБит/с. На остальных моделях роутеров (MIPSBE, SMIPS) вы получите не более 30-40 МБит/с. Подробнее об этом вы можете прочитать здесь.
Далее мы будем придерживаться следующей схемы:
Согласно которой у нас имеются две условные сети: A - 192.168.111.0/24, внешний IP-адрес 198.51.100.1 и B - 192.168.222.0/24, внешний адрес 203.0.113.1. Между ними мы будем поднимать GRE или IPIP-туннель с внутренними адресами 10.10.10.1 и 10.10.10.2.
Заключение
После того, как мы завершили процесс настройки перейдем в IP - IPsec - Active Peers и убедимся, что соединение между двумя узлами установлено. Если это не так - еще раз проверяем все настройки и изучаем файл лога, скорее всего у вас не совпадают параметры шифрования или идентификации.
Теперь откроем IP - IPsec - Installed SAs. В терминах IPsec - SA (Security Association) - ассоциация безопасности, обозначает установленное защищенное соединение. Для каждого соединения создается отдельная пара SA, так как каждая SA - это однонаправленное соединение, а данные нужно передавать по двум направлениям. Если запустить обмен данными между сетями, скажем пропинговать с узла одной сети узел другой сети, то мы увидим, что данные счетчика Current Bytes начинают меняться, а следовательно, шифрование работает и данные передаются внутри защищенного соединения.
Как видим, если хотя бы на базовом уровне понимать принципы действия IPsec, то настроить туннель между двумя сетями относительно несложно. Надеемся, что данный материал будет вам полезен.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Какие задачи может решить VPN туннель между MikroTik и VPS CentOS 8
Все запросы по настройке удаленного доступа к облачным серверам типа VPS и VDS можно разбить на две группы:
- Предоставления доступа к локальному серверу;
- Маршрутизация трафика через удаленный сервер.
В данной инструкции будет рассмотрен второй вариант, когда локальный трафик будет маршрутизироваться через удаленный сервер. Размещение при этом не играет ни какой роли: США, Германия, Болгария, Россия, Япония. Схематически это будет выследить так:
Настройка IPIP-туннеля
Настройка данного вида туннеля ничем не отличается от GRE, также переходим в Interfaces - Interface и добавляем новый интерфейс с типом IP Tunnel. Указываем все те же параметры: Local Address - внешний IP-адрес этого роутера, Remote Address - внешний IP-адрес противоположного роутера, IPsec Secret - общий ключ IPsec, также снимаем флаг Allow Fast Path.
В терминале это же действие:
Затем дублируем настройки на второй роутер, заменяя местами Local Address и Remote Address, также учитываем все то, что было сказано выше о настройках IPsec.
7 комментариев к статье “Настройка VPN L2TP+IpSec между VPS CentOS 8 и MikroTik”
По такой схеме будет работать Яндекс Алиса? У Яндекса есть уникальные службы, жаль что в Украине их так режут. К вам можно обратиться по настройке VPN, роутер MikroTik есть
Конечно обращайтесь. Без проблем настроим VPN туннель между вашим Микротиком и внешним VPS сервером. Будут работать любые службы Yandex
Спасибо за скрипт! Пара замечаний:
1. в centos 8 репозиторий PowerTools сейчас называется powertools, и с двумя заглавными буквами не заводится
2. Слетело форматирование и при создании файла ipsec.conf нет предшествующего таба перед параметрами в секциях config и conn, т. е. должно быть так ( для наглядности):
conn shared
left=%defaultroute
leftid=$PUBLIC_IP
Из-за этого не стартует ipsec
3. Не совсем понятно, почему правку IPTABLES (после скрипта) не вставили в сам скрипт. Разобрался, но пришлось вникнуть. А так бы можно было скопипастить 🙂
Ещё раз спасибо
Добрый день, делал все по шагам, запнулся на одной ошибке:
Dec 7 19:44:07 instance-test12 pppd[17225]: pppd 2.4.5 started by root, uid 0
Dec 7 19:44:07 instance-test12 pppd[17225]: Couldn’t set tty to PPP discipline: Operation not permitted
Dec 7 19:44:07 instance-test12 pppd[17225]: Exit.
Никак не могу понять в чем дело(
Возможно ваш хостер провайдер ограничивает подобные установки?
Врядли, я уже полностью отключил фаирвол провайдера (все всем)
Тут по моему в другом дело, PPP ругается что ему на что-то не хватает разрешений, а вот как узнать на что?
Эксперементирую в облаке Oracle
Уважаемый автор!
Скрипт отработал на 100% без ошибок. не смотря что Centos 7
Но мой микрот не хочет подключатся в лога (микрота) ошибок нет, но вот в Centos имеется.:
Подскажите что не так?
systemctl status ipsec.service
● ipsec.service – Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Fri 2022-03-18 23:01:44 MSK; 28min ago
Docs: man:ipsec(8)
man:pluto(8)
man:ipsec.conf(5)
Process: 1173 ExecStopPost=/usr/local/sbin/ipsec –stopnflog (code=exited, status=0/SUCCESS)
Process: 1171 ExecStopPost=/sbin/ip xfrm state flush (code=exited, status=0/SUCCESS)
Process: 1168 ExecStopPost=/sbin/ip xfrm policy flush (code=exited, status=0/SUCCESS)
Process: 1167 ExecStartPre=/usr/local/libexec/ipsec/addconn –config /etc/ipsec.conf –checkconfig (code=exited, status=3)
Mar 18 23:01:44 server_72755_1 systemd[1]: Failed to start Internet Key Exchange (IKE) Protocol Daemon for IPsec.
Mar 18 23:01:44 server_72755_1 systemd[1]: Unit ipsec.service entered failed state.
Mar 18 23:01:44 server_72755_1 systemd[1]: ipsec.service failed.
Mar 18 23:01:44 server_72755_1 systemd[1]: ipsec.service holdoff time over, scheduling restart.
Mar 18 23:01:44 server_72755_1 systemd[1]: Stopped Internet Key Exchange (IKE) Protocol Daemon for IPsec.
Mar 18 23:01:44 server_72755_1 systemd[1]: start request repeated too quickly for ipsec.service
Mar 18 23:01:44 server_72755_1 systemd[1]: Failed to start Internet Key Exchange (IKE) Protocol Daemon for IPsec.
Mar 18 23:01:44 server_72755_1 systemd[1]: Unit ipsec.service entered failed state.
Mar 18 23:01:44 server_72755_1 systemd[1]: ipsec.service failed.
From everything we have learned so far, let's try to build an advanced firewall. In this firewall building example, we will try to use as many firewall features as we can to illustrate how they work and when they should be used the right way.
Most of the filtering will be done in the RAW firewall, a regular firewall will contain just a basic rule set to accept established, related, and untracked connections as well as dropping everything else not coming from LAN to fully protect the router.
Настройка подключения клиента в Linux
Точно также начнем с сертификата, но в данном случае нам потребуется немного больше действий. Будем считать, что сертификат находится в корневой директории пользователя, для которого мы настраиваем подключение. Все последующие команды также следует выполнять от его имени.
Перейдем в домашнюю директорию и создадим скрытую папку для хранения ключей и сертификатов:
Теперь нам нужно экспортировать из PKCS12 файла корневой сертификат CA, а также ключ и сертификат пользователя. Начнем с корневого сертификата:
Затем экспортируем сертификат клиента:
И его закрытый ключ. При экспорте закрытого ключа нас попросят установить для него пароль, минимальная длинна пароля 8 символов. Пропустить этот шаг нельзя.
На каждом из этих этапов нам нужно будет вводить парольную фразу, указанную при экспорте сертификата пользователя на роутере.
И наконец уберем пароль с закрытого ключа пользователя:
Во время этого действия вы должны будете ввести пароль, который указали при создании ключа.
Для того, чтобы иметь возможность создавать VPN-подключения в графическом интерфейсе установим необходимый плагин для Network Manager:
После чего вам станут доступны настройки VPN IKEv2 соединения.
Настройки соединения достаточно просты. В секции Gateway указываем адрес сервера и путь к корневому сертификату CA. В секции Client устанавливаем Authentication: Certificate/private key и указываем пути к сертификату и закрытому ключу клиента. И в секции Option обязательно устанавливаем флаг Request an inner IP address. На этом настройка соединения окончена, можно подключаться.
Если мы после подключения проверим таблицу маршрутизации, то не обнаружим маршрута к офисной сети, но при этом она будет доступна:
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
![mikrotik-ikev2-vpn-009.jpg]()
Настройка IKEv2 VPN-сервера
Здесь мы вступаем в достаточно сложную область настройки IPsec, объем статьи не позволяет подробно останавливаться на назначении каждой настройки, поэтому если вы не уверены в своих действиях, то мы не рекомендуем отклоняться от указанных ниже настроек.
Перейдем в IP - IPsec - Profiles и создадим новый профиль, который задает параметры для установления соединения. Все параметры оставляем по умолчанию, кроме наименования, которому следует дать осмысленное имя.
Либо выполните команду в терминале:
Затем перейдем на закладку Proposals - предложения, который содержит параметры криптографии предлагаемые для соглассования подключающимся клиентам. Создадим новое предложение, которое сформировано с учетом используемых современными ОС алгоритмов и изменение его состава может либо ослабить безопасность, либо сделать подключение некоторых клиентов невозможным.
В терминале достаточно простой команды:
Здесь мы сталкиваемся с одной особенностью: создаваемые через терминал и Winbox предложения содержат различный набор параметров. То, что создается в терминале полностью соответствует приведенным выше на скриншоте требованиям.
Для выдачи VPN-клиентам нам потребуется отдельный диапазон адресов, перейдем в IP - Pool и создадим новый пул, в нашем случае будет использован диапазон адресов 10.20.0.100 - 10.20.0.199:
Снова вернемся к настройкам IPsec и создадим конфигурацию, передаваемую клиенту для настройки его сетевых параметров, для этого перейдем на в IP - IPsec - Mode Configs. При создании новой конфигурации установим флаг Responder, в поле Address Pool укажем имя созданного нами пула, в поле Address Prefix Lenght укажем префикс адреса - 32, поле Split Include указываем подсети, запросы к которым следует направлять в туннель, здесь следует указать одну или несколько внутренних сетей, доступ к которым должны получать удаленные клиенты. В нашем случае это сеть условного офиса - 192.168.111.0/24. Наконец флаг System DNS предписывает клиенту использовать DNS сервера указанные в IP - DNS роутера. Если передавать DNS-сервера не требуется, то данный флаг следует снять.
Это же действие в терминале:
Если же вам нужно, чтобы клиенты использовали внутренние сервера имен, например, в Active Directory, то флаг System DNS также следует снять и указать адреса требуемых DNS-серверов.
Команда для терминала будет выглядеть так:
На закладке Groups создадим новую группу, никаких настроек здесь нет, просто укажите уникальное имя:
Затем на закладке Policices создадим шаблон политики, которая будет указывать какой именно трафик будет подвергаться обработке IPsec и отправляться в туннель. В поле Src. Address оставляем 0.0.0.0/0, в поле Dst. Address указываем выделенный для VPN-сети диапазон: 10.20.0.0/24, устанавливаем флаг Template и указываем созданную нами ранее группу в поле Group.
На закладке Action в поле Proposal укажите созданный нами ранее набор предложений.
Эти же действия в терминале:
После чего перейдем в IP - IPsec - Peers создадим новый пир для приема подключений. Сразу установим флаг Passive, в поле Address указываем 0.0.0.0/0 (разрешаем подключаться из любого места), в поле Profile указываем созданный нами профиль, а в поле Exchange Mode укажем протокол обмена ключами - IKE2.
В терминале для получения аналогичного результата выполните:
На закладке Identities создадим новую настройку идентификации подключающихся клиентов. Здесь много настраиваемых полей и нужно быть предельно внимательными, чтобы ничего не упустить и не перепутать. В поле Peer - указываем созданный нами пир, Auth. Method - способ аутентификации - digital signature, Certificate - сертификат сервера. Policy Template Group - группа шаблонов политик - выбираем созданную нами группу, Mode Configuration - указываем созданную нами конфигурацию для клиентов, Generate Policy - port strict.
Команда для терминала:
На этом настройка сервера завершена, осталось лишь добавить правила брандмауэра, разрешающие работу с ним. Для того, чтобы клиенты могли подключаться к серверу перейдем в IP - Firewall - Filter Rules и добавим правило: Chain - input, Protocol - udp, Dst. Port - 500, 4500, In. Interface - ваш внешний интерфейс (в нашем случае это ether1). Действие не указываем, так как по умолчанию применяется accept.
Для добавления правила в терминале:
Но это еще не все, чтобы VPN-клиенты могли получить доступ к внутренней сети, следует добавить еще одно правило. На закладке General укажите Chain - forward и Interface - внешний интерфейс, затем на Advanced: IPsec Policy - in:ipsec.
Оба правила следует расположить выше, чем запрещающие в каждой из цепочек.
Читайте также: