Manual:interface/eoip

Конфигурация

Изначально нам нужно убедиться, что обе наши стороны имеют «белый» маршрутизируемый ip адрес. Теоретически, все это можно прокинуть через NAT, если устройство находится внутри сети, но это осложняет конфигурацию, а еще далеко не все провайдеры позволяют one-to-one NAT в наше время.

Начнем со стороны Mikrotik. Предполагаю, что на нем стоит свежая прошивка (в моем случае это 6.48.4), и он уже настроен как роутер «белым» адресом наружу.

Локальная сеть Mikrotik в нашем случае:

Сети со стороны Cisco это множество локальных подсетей:

Маршрутизируемый адрес в примере для Mikrotik будет:

Маршрутизируемый адрес для Cisco:

Настройка подключения на стороне клиента

На компьютере или ноутбуке сотрудника настроим VPN-соединение до L2TP Сервера. Приведу пример, как это можно сделать на ОС Windows 10.

Откроем “Центр управления сетями…”, затем создадим подключение, как показано на рисунке ниже:

Следующим шагом выберем вариант подключения:

Выполним подключение через Интернет с помощью VPN:

Следующим шагом введем внешний адрес (WAN) роутера Mikrotik и произвольное имя для соединения:

В нашем примере маршрутизатору Mikrotik назначен внешний IP 111.111.111.111, у вас это будет свой адрес.

Продолжим настройку VPN соединения:

Откроем свойства созданного соединения:

Перейдем на вкладку “Безопасность”, выполнив настройку как показано на рисунке ниже:

Откроем дополнительные параметры (5 шаг на рисунке) и укажем ключ IPSec, который мы указали ранее в настройках L2TP Server, параметром IPsec Secret:

Далее откроем вкладку “Сеть”, уберем галочку с протокола TCP/IPv6 и откроем свойства протокола TCP/IPv4:

Нажмем кнопку “Дополнительно” и запретим использовать основной шлюз в удаленной сети, сняв галочку с соответствующего пункта:

Подключаем созданное VPN-соединение:

Настройка маршрутизации L2TP-клиента

Подключение установилось. Следующим шагом укажем постоянный статический маршрут прописав шлюз для удаленной подсети.

Откроем командную строку с правами администратора и выполним команду:

Где:

• 192.168.13.0 – локальная подсеть организации;
• 255.255.255.0 – маска этой подсети;
• 10.10.10.1 – шлюз (адрес устройства Mikrotik, который мы задавали в настройках профиля);
• 49 – номер созданного VPN интерфейса (можно узнать командой route print);
• /p – параметр, указывающий на то, что сделать маршрут постоянным. Иначе после перезагрузки данный маршрут удалится.

Пример, как можно посмотреть номер интерфейса:

На этом настройка L2TP Server + IPSec на Mikrotik закончена. Надеюсь, данная статья была для вас полезной.

Настройка GRE

Первым шагом рассмотрим простую настройку gre туннеля. Вся она будет одинакова на обоих роутерах. Подключившись к нажим железкам через Winbox и перейдем в Interfaces – GRE Tunnel.

Создадим по интерфейсу. Укажем следующие параметры:

• Name – понятное имя;
• Remote Address – адрес соседа по туннелю. Основной принцип — направляем роутеры друг на друга;

Keepalive – тот самый параметр отслеживания состояния. Можно ничего не менять. Он означает следующее – если в течении 10 попыток по 10 секунд не отвечает удаленная сторона, считать туннель не активным.

Сохраняем настройки и смотрим на состояние.

Как мы видим, интерфейс в состоянии running. Назначим адреса. Переходим в IP – Addresses.

Зададим адрес 172.16.25.1 для московского роутера и 172.16.26.2 для питерского.

Для проверки связи запустим ping запросы.

Пинги идут – все хорошо. Далее пропишем маршруты в локальные сети. Открываем IP – Routes на московском.

Добавляем новый маршрут:

• Dst. Address – 192.168.10.0/24;
• Gateway – 172.16.25.2.

Сохраняем и проделываем аналогичную операцию только на питерском роутере.

Основной принцип – прописать маршруты в сети через адреса в туннелях. Проверим ping до адреса бриджа Mikrotik в Москве.

Все отлично – значит мы правильно сделали. В целях демонстрации я отключу интерфейс в Москве, выжду интервал в 100 секунд и посмотрим на состояние туннеля.

Интересная ситуация, в одном офисе интерфейс активный, а в другом нет. Попробуем проверить связь.

Пингов нет, а туннель активен. Спустя какое-то время, Mikrotik в Питере понимает, что связи через gre туннель нет и меняют статус на интерфейсе.

Тут-то и помогла доработка Mikrotik с keepalive. К чему этот эксперимент спросите вы? Во-первых – для демонстрации, во-вторых – если есть те, кто еще используют данный протокол для своих задач, имейте ввиду, что маршруты в routes буду активны то время, которое вы указали в keepalive. Только по истечении этого времени маршруты и адрес станут не активны.

Большая нагрузка от использования фильтра Layer 7

У меня есть статья про блокировку сайтов микротиком. В ней показана ошибочная настройка, которую как раз разбирает автор презентации.

Действовать нужно по-другому. Layer 7 protocol задуман как способ поиска определенных шаблонов в подключениях для маркировки трафика на основе этих шаблонов. А дальше уже маркированный трафик обрабатывается фаерволом. Фильтр с Layer 7 protocol не должен проверять абсолютно весь трафик. Он должен брать первые 10 пакетов или 2KB данных подключения и анализировать только их.

Корректное использование Layer 7 protocol показано на следующем примере.

Roadmap

• make a patch for iproute2 to include eoip support

• work towards making this code good enough for inclusion in official kernel/iproute2 releases

The inclusion of a reverse-engineered proprietary protocol which violates GRE standards is not going to happen in the official Linux kernel. Creating a patch for iproute2 is pointless as it would require patching and replacing one more component that in turn would make supporting a Linux system with kernel mode EoIP even harder. Thus using the included simple tool would be easier and preferred.

The problem in making a stand-alone EoIP kernel module is that it requires replacing gre_demux (). Linux kernel does not support overloading IP protocol handlers and EoIP does not fit anywhere in the standard gre_demux logic. A relatively sane solution might be to include the GRE demultiplexing logic in the EoIP kernel module itself, to provide a alias and to blacklist the original . In this way GRE and PPTP would still be able to coexist with EoIP.

• make a DKMS package

• implement the option and probably make it the default

Properties

Summary

Sub-menu:
Standards:

Ethernet over IP (EoIP) Tunneling is a MikroTik RouterOS protocol that creates an Ethernet tunnel between two routers on top of an IP connection. The EoIP tunnel may run over IPIP tunnel, PPTP tunnel or any other connection capable of transporting IP.
When the bridging function of the router is enabled, all Ethernet traffic (all Ethernet protocols) will be bridged just as if there where a physical Ethernet interface and cable between the two routers (with bridging enabled). This protocol makes multiple network schemes possible.

Network setups with EoIP interfaces:

• Possibility to bridge LANs over the Internet
• Possibility to bridge LANs over encrypted tunnels
• Possibility to bridge LANs over 802.11b ‘ad-hoc’ wireless networks

The EoIP protocol encapsulates Ethernet frames in GRE (IP protocol number 47) packets (just like PPTP) and sends them to the remote side of the EoIP tunnel.

Ubuntu 16.04 (ifupdown)

Все команды в примерах ниже я выполняю из под рута. Если вы не работаете под рут пользователем, добавляйте sudo перед каждой командой.
для просмотра списка интерфейсов можно набрать команду ip a

Для настройки IPIP туннеля создадим файл с именем интерфейса /etc/network/interfaces.d/tun1 для этого выполним команду:

nano /etc/network/interfaces.d/tun1

И вставим в этот файл текст:

auto tun1
iface tun1 inet static
address 172.26.30.1
netmask 255.255.255.252
pre-up ip tunnel add tun1 mode ipip local 98.213.46.5 remote 145.16.220.86
post-down iptunnel del tun1

Где:

• • tun1 — название интерфейса туннеля
  • 172.26.30.1 — локальный адрес внутри туннеля
  • 98.213.46.5 — внешний адрес Ubuntu
  • 145.16.220.86 — внешний адрес микротика

Сохраняем файл (Ctrl + O затем Ctrl + X выходим). После этого можем поднимать интерфейс командой ifup tun1.  Для проверки воспользуемся командой ip a:

С этого момента пакеты между адресами 172.26.30.1  и 172.26.30.2 будут ходить по туннелю. Можем проверить коммандой ping

Но на схеме я так же указал внутреннюю подсеть за микротиком — 172.16.220.0/24. Давайте так же добавим маршрут в неё. Для этого в файл который мы только что создали, /etc/network/interfaces.d/tun1 добавим строчку:

up ip ro add 172.16.220.0/24 dev tun1

файлик после этого будет выглядеть примерно так:

auto tun1
iface tun1 inet static
address 172.26.30.1
netmask 255.255.255.252
pre-up ip tunnel add tun1 mode ipip local 98.213.46.5 remote 145.16.220.86
up ip route add 172.16.220.0/24 dev tun1
post-down iptunnel del tun1

Для применения изменений передёрнем интерфейс.

ifdown tun1
ifup tun1

Проверим таблицу маршрутизации командой route -n. Должно выглядеть примерно так:

На этом всё. Пакеты будут успешно проходить. К созданному туннелю можно настроить IPSEC шифрование. Переходим к IPIP туннелю с помощью нетплана.

Настройка

1. Настройка DNS на Mikrotik

Если помните, в предыдущей статье мы много обсуждали, какой адрес DNS раздавать клиентам и куда форвардить запросы с маршрутизатора

Для целей же нашего нового решения важно на маршрутизаторе указать в качестве DNS-серверов именно сервера нашего провайдера — чтобы они оставались доступны при блокировке сервиса за неуплату, например. Поэтому или настраиваем получение DNS от оператора по DHCP, или идем в Winbox по пути IP — DNS и в поле Servers прописываем адреса DNS-серверов провайдера

2. Настройка VRRP на Mikrotik

Создаем новый VRRP интерфейс с привязкой к интерфейсу Bridge и навязываем на него наш виртуальный адрес. Можно сделать в Winbox, но гораздо проще сделать это в терминале:

Здесь vrrp-dns — это имя интерфейса (можете выбрать любое на свой вкус, главное совпасть в обеих командах), vrid — ID группы, можно тоже выбрать любой в диапазоне 1-255, нужно совпасть на обоих устройствах. Имя интерфейса bridge и IPv4-адреса нужно скорректировать под вашу домашнюю сеть.

После выполнения этого действия можно попинговать 192.168.1.9 — он уже должен отвечать с маршрутизатора, если пинг не закрыт файрволом.

UPD. Если у вас жесткие настройки файрвола — проверьте, что DNS на виртуальном адресе работает (nslookup google.com 192.168.1.9 с вашего компьютера). И если нет — добавьте разрешающее правило для 53/udp.

3. Настройка VRRP на Pi-Hole

Устанавливаем демон keepalived:

Создаем файл конфигурации демона /etc/keepalived/keepalived.conf:

Здесь обратите внимание на имя интерфейса, на котором сейчас работает Pi-Hole — в примере дефолтное ens160, у вас может быть другое (проверить можно, например, через команду ifconfig). Создаем скрипт проверки живости DNS /etc/keepalived/check_dns.sh:

Создаем скрипт проверки живости DNS /etc/keepalived/check_dns.sh:

и не забываем сделать его исполняемым:

С методикой проверки DNS вы можете экспериментировать как угодно. Для себя я выбрал проверку резолвинга адреса amazon.com. Плюс этого варианта в том, что TTL этой записи — 1 минута, поэтому дольше чем на минуту ваш Pi-Hole закэшировать запись не сможет и, соответственно, на это время максимум и отложится убегание сервиса в случае потери связи с миром. Основной принцип, который надо помнить — если скрипт выдает 0 в качестве error code, то keepalived будет считать, что всё хорошо, и добавит приоритета. Любой другой error code — и адрес уползет на Mikrotik.

Теперь достаточно перезапустить сервис:

и всё заработает. В логе Mikrotik можно будет увидеть запись, подобную этой:

Вы можете проверить, что теперь на адресе 192.168.1.9 отвечает Pi-Hole, самый простой способ проверки — это резолвинг имени pi.hole:

Обратите внимание, что резолвиться будет в адрес сервера Pi-Hole, а не в наш виртуальный IP — это правильно и так и должно быть

4. Настройка DHCP на Mikrotik

Ну и наконец нам надо научить DHCP-сервис Mikrotik раздавать клиентам правильный адрес DNS. Это удобнее сделать из WinBox — там вы увидите все свои пулы. Идем по пути IP — Networks, смотрим глазами на все сети, которые у вас связаны с Pi-Hole сейчас и изменяем поле DNS Servers с адреса Pi-Hole 192.168.1.10 на виртуальный адрес 192.168.1.9.

Обновляем аренду адреса на компьютерах, проверяем, что получили правильный адрес DNS, проверяем, что резолвинг работает (например, командой nslookup pi.hole — уже без прямого указания имени используемого сервера). Радуемся.

Особо ответственные могут каким-либо образом сломать своему DNS-серверу резолвинг и проконтролировать, что по истечении таймаута виртуальный адрес переползет на Mikrotik. Но это уже зависит от вашей фантазии.

Траблшутинг

При развертывании конфигурации на действующем железе нужно обязательно переключить прямой и обратный маршруты с туннелей L2TP на OpenVPN-туннель. Если, например, переключить только прямой маршрут, а обратный оставить на L2TP вместо OpenVPN, агрегация полностью работать не будет и пакеты все равно будут теряться. 
Утилиты RouterOS в разделе /tools очень полезны при траблшутинге. Еще неплохо работает связка /tools Packet Sniffer + Wireshark.
Не забудьте «поиграться с mtu», чтобы достичь лучшей производительности туннелей.
Качество сигнала никто не отменял. RSRP, RSRQ и SINR покажут, насколько все хорошо. При большом удалении от базовой станции и плохом сигнале помогут внешние направленные антенны

Важно! Если провайдер фильтрует трафик и идет блокировка L2TP, то можно поднять другие туннели в качестве основы для EoIP, например: OpenVPN или SSTP. Чтобы проверить все в деле, можно сымитировать сбой

Отключаем любой из LTE-интерфейсов или создаем потери искусственно: добавляем в межсетевой экран правило частичной блокировки пакетов и указываем при создании нового правила значение в поле random.

Маршрутизатор R2

1. Первым делом прописываем маршруты от одного интерфейса LTE-модема до одного белого IP-адреса дата-центра. Запрещаем в настройках межсетевого экрана в цепочке output прохождение пакетов с другого интерфейса:

2. Приводим в соответствие с R1 дефолтный конфиг /ip ipsec profile:

3. Создаем /ppp profile:

   и два L2TP/IPsec-подключения к дата-центру для каждого из провайдеров:

4. Создаем EoIP-туннели по аналогии с R1, только меняем местами local и remote IP L2TP/IPsec-линков маршрутизатора R2. Bonding-интерфейс такой же, как на R1:

5. Также импортируем сертификаты, создаем профиль:

   Настраиваем OpenVPN-клиента на R2:

6. Туннели загорелись волшебной буквой R, а EoIP – еще и RS. OpenVPN тоже завелся. Теперь можно направлять трафик с компьютера трансляций в наш слоеный бутерброд – в OpenVPN-туннель. Для этого создаем правило /ip firewall mangle и прописываем сразу новую таблицу маршрутизации:

7. Создаем маршрут через наш OpenVPN-туннель с данной таблицей маршрутизации:

И готово!

Настройка EOIP Tunnel + Ipsec

Настроим vpn сеть на базе EOIP в Mikrotik

Тут нужно понимать одно важное отличие от всех предыдущих настроек, которые мы делали ранее. EOIP туннель работает на уровне l2, то есть оба сегмента сети будут считать, что находятся в одной физической сети

Адресное пространство для обоих будет одно и то же. В моем примере это 10.20.1.0/24. DHCP сервер должен остаться только один для обоих сетей. В моем случае он останется на m-server.

Создаем EOIP туннель на m-server. Идем в Interface list -> EoIP Tunnel и добавляем новый.

Из настроек достаточно указать только удаленный адрес второго микротика. Новый EoIP интерфейс необходимо добавить в локальный бридж вместе с физическими интерфейсами.

Идем на удаленный микротик и там делаем все то же самое, только Remote Address указываем другой.

Этого достаточно, чтобы EoIP туннель сразу же заработал. Его состояние будет RS.

На втором микротике EoIP интерфейс так же нужно добавить в локальный бридж с остальными интерфейсами.

Проще всего проверить, что все в порядке, это запросить по dhcp на m-slave ip адрес для интерфейса bridge. Он должен получить ip адрес от dhcp сервера на m-server, при условии, что в сети больше нет других dhcp серверов. То же самое будет и с локальными машинами в сети за m-slave. Они будут получать ip адреса от dhcp сервера на m-server.

Проверим теперь быстродействие такого vpn туннеля на основе EoIP.

Показываю максимальный результат, который у меня получился — 836 мбит/сек. По какой-то причине в разных тестах скорость плавала в интервале между 600-850 мбит/сек. Для того, чтобы скорость изменилась, необходимо было отключить и заново включить EoIP интерфейс. Скорость впечатляет. При этом, процессор не загружен на 100%. То есть узкое место не он. Похоже я уперся в производительность сети. Напомню, что тут нет никакого шифрования и маршрутизации трафика. Прямой l2 канал между двумя микротиками через EoIP vpn.

Добавим в EoIP туннель шифрование Ipsec и посмотрим на скорость. Для этого меняем настройки каналов на обоих микротиках. Добавляем пароль Ipsec и локальные адреса, отключаем Fast Path.

Измеряем скорость соединения.

У меня получилась скорость vpn при использовании EoIP + Ipsec в среднем 27 мбит/сек. Скорость сопоставима с шифрованными туннелями L2tp и Openvpn. В этом плане никаких приятных сюрпризов не получилось. Шифрование очень тяжело дается этой железке. Можно сказать она для него не предназначена практически совсем.

Последние штрихи

Осталось объединить нужные интерфейсы в мосты и проверить работу.

MikroTik M151-office

Создадим мост и добавим туда туннель и ранее созданный VLAN интерфейс

#
#
/interface bridge
add name=office-tunnels
/interface bridge port
add bridge=office-tunnels interface=v200office
add bridge=office-tunnels interface=tunnel-m152

Как раз здесь я и поясную, зачем поднимал интерфейсы VLAN на портах wan обоих микротиков. Мне (и вам) они нужны для тестирования. Т.е. в физический внешний интерфейс wan кабель воткнут. Он работает. Соответственно работают и все поднятые на нем VLAN-интерфейсы. А так как я присвоил этим интерфейсам IP-адреса в офисе и в «удаленном» офисе, то мне этого будет достаточно для проверки. А увидит ли микротик центрального офиса внутреннюю сеть удаленого офиса, я узнаю пропинговав соответствующие адреса. Заодно посмотрю как тикает счетчик байтов в IPsec, подтверждая, что трафик шифруется. В дальнейшем эти айпишники не нужны, достаточно будет объединить нужные интерфейсы (внутренней сети и моста) в бридж.

MikroTik M152-remote1

#
#
/interface bridge
add name=office-tunnels
/interface bridge port
add bridge=office-tunnels interface=tunnel-m151
add bridge=office-tunnels interface=v200-office

Если все было сделано правильно, то вы должны увидеть такую картину на обоих ваших роутерах:

#
#
> ping 192.168.200.2
SEQ HOST SIZE TTL TIME STATUS
0 192.168.200.2 56 64 1ms
1 192.168.200.2 56 64 1ms
2 192.168.200.2 56 64 1ms
3 192.168.200.2 56 64 1ms
4 192.168.200.2 56 64 1ms

#
#
> ping 192.168.200.1
SEQ HOST SIZE TTL TIME STATUS
0 192.168.200.1 56 64 1ms
1 192.168.200.1 56 64 1ms
2 192.168.200.1 56 64 1ms
3 192.168.200.1 56 64 1ms
4 192.168.200.1 56 64 1ms

Если так, то поздравляю, мы построили прозрачную сеть, по которой будет бегать любой трафик, включая DHCP. Т.е. вы можете поставить один DHCP-сервер в центральном офисе и он будет вещать на все остальные офисы

Правда, с одной важной оговоркой: вы должны быть стопроцентно (нет, двестипроцентно) уверены в качестве связи, чего не скажешь про интернет. Но если ваши офисы (или точки продаж) расположены в одном здании — в торговом центре, например, то один настроенный DHCP-сервер в центральном офисе облегчит вашу нелегкую админскую жизнь

Настройка openvpn server в микротик

В настройке openvpn сервера на mikrotik нет ничего сложного, кроме нюанса с сертификатами. Тому, кто с ними никогда не работал, может показаться все слишком замороченным. К тому же в самом микротике нет никаких средств для создания сертификатов сервера и клиента. Необходимо использовать сторонние утилиты. Если у вас есть linux машина, можете воспользоваться моей инструкцией по созданию сертификатов для openvpn на linux.

Выполняем установку от имени администратора и указываем в процессе компонент под названием EasyRSA 2 Certificate Management Scripts.

Идем в директорию C:Program FilesOpenVPN. Переносим оттуда папку easy-rsa куда-нибудь в другое место, чтобы не приходилось постоянно спотыкаться об UAC, который не даст спокойно работать в Program files. Я перенес в D:tmpeasy-rsa. Переименовываем файл vars.bat.sample в vars.bat. Открываем его на редактирование и приводим примерно к следующему виду.

Для тех, кто не понял, это просто переменные, которые я указал под свои нужды. Там писать можно все, что угодно, не принципиально для нашей задачи. Можно вообще ничего не менять, а оставить как есть. Создаем в директории папку keys. Далее запускаем командную строку от администратора и перемещаемся в указанную директорию D:tmpeasy-rsa.

Далее в командной строке пишем vars и жмем enter. Этим мы загрузим переменные из файла vars.bat, потом вводим clean-all. Дальше генерируем Root CA командой — build-ca.

Отвечаем на задаваемые вопросы и завершаем создание корневого сертификата. Он появится в папке D:tmpeasy-rsakeys. Дальше создаем сертификат openvpn сервера командой — build-key-server имя_сервера.

Теперь сгенерируем сертификат для клиента. У меня только один клиент в виде удаленного микротика. Вы создаете ровно столько, сколько вам нужно. Используем команду build-key имя_сертификата.

С созданием сертификатов закончили. Они у нас все лежат в директории keys. На микротик, который будет выступать в качестве openvpn сервера, нужно передать файлы:

• ca.crt
• ovpnserver.crt
• ovpnserver.key

Импортируем сертификаты из добавленных файлов. Идем в System -> Certificates и импортируем сначала ca.crt, потом ovpnserver.crt и ovpnserver.key.

Должно получиться примерно так. Теперь приступаем к настройке openvpn сервера в mikrotik. Создадим для него отдельный профиль в PPP -> Profiles.

Все настройки дефолтные. В качестве локального и удаленного адреса использую Ip Pool, который создал в самом начале настройки l2tp. Добавим удаленного пользователя для openvpn в PPP ->Secrets.

Идем в раздел PPP и жмем OVPN Server. Указываем настройки и загруженный ca сертификат.

Далее добавляем по аналогии с остальными vpn серверами OVPN Server Binding и статические маршруты.

На этом настройка openvpn server в микротик завершена. По дефолту будет использоваться протокол шифрования BF-128-CBC. Его можно поменять в свойствах клиента, а список всех поддерживаемых шифров в свойствах vpn сервера.

Для работы указанной настройки openvpn сервера необходимо открыть входящий tcp порт 1194 на фаерволе. Теперь настроим openvpn клиент и протестируем скорость соединения через vpn на основе openvpn.

openvpn client

Для настройки openvpn client на mikrotik, туда нужна передать сертификаты, сгенерированные на предыдущем шаге. Конкретно вот эти файлы:

• m-remote.crt
• m-remote.key

Импортируем, как и на сервере сертификат из этих файлов

Обращаю внимание, что должны быть символы KT напротив имени сертификата

Теперь настраивает openvpn клиента. Идем в PPP и добавляем OVPN Client.

Добавляем статический маршрут для доступа к ресурсам удаленной сети за openvpn сервером.

Все готово. Можно подключаться и тестировать скорость vpn соединения через openvpn.

Получилось в среднем 24 мбит/сек при 100% загрузке процессора. Результат сопоставим с l2tp + ipsec. Немного удивил результат. Я думал, будет хуже, чем l2tp, а на деле то же самое. Мне лично вариант с openvpn в целом нравится больше, хотя из-за ограниченности настроек openvpn в микротике преимущества openvpn трудно реализовать. Напомню, что тестировал с шифрованием BF-128-CBC, то есть blowfish.

Вот результат с AES-128-CBC — 23 мбит/сек, примерно то же самое.

С клиент-серверными реализациями vpn сервера в mikrotik разобрались. Теперь просмотрим на скорость l2-vpn в виде eoip tunnel.

Сравнение скорости L2tp, Pptp, EoIP, GRE и OpenVPN туннелей

Сведу все данные измерений в единую таблицу для наглядного и удобного анализа и сравнения скоростей всех упомянутых vpn соединений в Mikrotik.

Приведенная таблица наглядно показывает разницу в различных методах шифрования. С помощью нее можно быстро оценить, к каким потерям производительности может привести шифрование. Сейчас все по-умолчанию все шифруют, но если разобраться, очень часто это не требуется. Можно пойти на некий компромис и использовать pptp сервер, который хоть и не обеспечивает 100% безопасное шифрование, но тем не менее скрывает трафик от просто любопытных глаз и имеет неплохое быстродействие. В любом случае трафик просто так не прочитать, надо целенаправленно приложить усилия для дешифровки. В некоторых случаях такой защиты будет достаточно.

Похожие записи:

Вход в личный кабинет роутера Бесшовный wifi роуминг с помощью capsman в микротик Manual:reset Как настроить микротик routerboard rb951g-2hnd Каталог устройств mikrotik Перенаправление запросов (проброс портов) на mikrotik