Все о туннелях IPIP, GRE и EoIP

dexter · 30 апреля, 2017

Здравствуйте, пытаюсь поднять IPIP туннель между Ultra2(сервер) и Ultra(клиент). туннель поднимаю по инструкции вместе с ipsec'ом. Но коннекта не идет.

Ругается он на

Apr 30 18:10:11ndmIpSec::Configurator: unable to resolve remote peer address for crypto map "IPIP0" connection.

Постом ниже селф-тесты с обоих железок.

KorDen · 2 мая, 2017

@Himmler, у вас Lite III rev. A или rev. B? Потому что у rev.B есть криптомодуль AES, на котором можно получить, по заявлениям, до 60 Мбит/с. У rev.A криптомодуля нет, поэтому с IPsec получите довольно слабые результаты. PPTP-сервер везде ограничен около 40 мбит/с.

Если безопасность совсем не интересует, и если с обоих сторон белые IP прямо на кинетиках, можно вообще использовать туннели без IPsec.

Вам нужно обязательно объединить сетки в один broadcast-сегмент, или все же ПО может ходить на IP из другого сегмента?

Himmler · 4 мая, 2017

KorDen, оба устройства ревизии А, но безопасность туннеля не интересует вовсе.

ПО не умеет ходить по подсетям, ему нужно, чтобы клиенты были подключены в один маршрутизатор (ну или чтобы для ПО это так выглядело). Потому что ранее пробовал обычный VPN, машины через туннель друг друга пингуют, а вот ПО не видит другую сторону.

Касательно IP - на одной стороне он белый (к нему привязаны KeenDNS и No-IP-dns имена). На другой стороне IP серый (на той, где GPON-модем).

Главная цель - максимальная производительность туннеля. Я так понимаю, разумнее всего поднимать EoIP, и если да, можно ли рассчитывать хотя бы на 30 Мбит/с и увеличение задержки на 3-4 мс ?

Изменено 4 мая, 2017 пользователем Himmler

vasek00 · 4 мая, 2017

19 минут назад, Himmler сказал:

ПО не умеет ходить по подсетям, ему нужно, чтобы клиенты были подключены в один маршрутизатор (ну или чтобы для ПО это так выглядело). Потому что ранее пробовал обычный VPN, машины через туннель друг друга пингуют, а вот ПО не видит другую сторону.

Это потому что любому ПО помимо IP нужен еще и порт, а для под сетей есть маршруты.

dexter · 4 мая, 2017

Судя по описанию портом и маршрутами не спасешься. Там ПО шлет броадкаст, а он только в одном широковещательном домене работает.

vasek00 · 5 мая, 2017

12 часа назад, dexter сказал:

Судя по описанию портом и маршрутами не спасешься. Там ПО шлет броадкаст, а он только в одном широковещательном домене работает.

Ну во первых - для чего данное ПО шлет броадкаст, второе вспомним теорию, которая говорит

Цитата

В TCP/IP широковещание (broadcast) обычно возможен только в пределах одного сегмента сети L2 или L3. Но однако пакеты данных могут быть посланы из-за пределов сегмента, в который будет осуществлено широковещание .... На уровне L2 используется широковещательный MAC-адрес FF:FF:FF:FF:FF:FF для передачи служебных датаграмм (ARP-запрос). На уровне L3 используются широковещательные адреса, вид которых зависит от протокола, в IP-сетях широковещательный адрес например будет 192.168.2.255
Например отправить пакет всем хостам сети 192.168.2.0/24 сам хост находится в другой сети, в заголовке пакета адрес 192.168.2.255, маршрутизатор должен не передавать, но их можно настроить на разрешение передачи broadcast трафика.

Proxy ARP — техника, применяющаяся в маршрутизаторах для трансляции ARP-ответов из одного сегмента сети в другой. Эта техника используется некоторыми сетевыми устройствами, чтобы позволить определять с помощью протокола ARP MAC-адрес устройства, находящиеся в другом канальном сегменте...... прокси-ARP имеются недостатки: 1.Это увеличивает объем ARP-трафика в вашем сегменте сети; 2.Хостам необходимы большие ARP-таблицы для обработки сопоставления IP-адресов и MAC-адресов; 3.Система безопасности может быть нарушена. Один компьютер может выдавать себя за другой для перехвата пакетов - "спуфингом".

http://www.cisco.com/c/ru_ru/support/docs/ip/dynamic-address-allocation-resolution/13718-5.html

Возможно это нужно пользователю, что-то для WINS или как всегда что-то для игрового сервера

В догонку на всех интерфейсах роутера по умолчанию proxy_arp = 0.

Изменено 5 мая, 2017 пользователем vasek00

Le ecureuil · 10 мая, 2017

В 4/13/2017 в 17:54, KorDen сказал:

@Le ecureuil, а в EoIP MTU=1500 на кинетике вообще должен работать, или нет? В микротиках, насколько я понимаю, это вполне рабочее решение - да, пакеты бьются на два, но зато не надо править MTU на устройствах при бриджевании с LAN.

Прямо сейчас это не сделано, но если дойдут руки - сделаю. Не забывайте подпинывать это сообщение, чтобы они дошли

Le ecureuil · 10 мая, 2017

В 4/30/2017 в 00:39, Himmler сказал:

Здравствуйте, товарищи.

Если написал не в ту тему - поправьте, пожалуйста.

Вопросов у меня несколько:

1. В основном здесь обсуждаются довольно толстые устройства вроде Giga или Ultra, а как насчёт Lite III ? На какую производительность туннеля в лучшем случае стоит рассчитывать на таком устройстве (скажем, если вопрос безопасности не интересует и нужна именно максимальная пропускная способность и минимальная задержка в туннеле) ?

2. Исходя из первого вопроса, какой именно тип туннеля стоит выбрать для поставленной задачи, если конечная цель - соединить две удалённые подсети в одну через туннель. Либо же это можно сделать меньшими усилиями и без EoIP ?

3. На обоих концах с провайдером поднимается туннель PPPoE (на одном конце напрямую кинетиком, на другом его поднимает GPON-модем, за которым стоит кинетик). Верно ли я понял, что в данном случае никаких ограничений на возможности выбора туннеля не накладывается (таких, как нерабочий GRE при использовании PPTP) ?

1. На Lite III лучше использовать PPTP + MPPE40 - будет в разы быстрее (тем более безопасность не интересует).

2. Сперва определитесь, на каком уровне вам нужно объединять сегменты/подсети - на L2 или на L3. Если L3 устроит - то вам подойдет проверенный веками вариант с PPTP.

3. Да, ограничений нет.

Le ecureuil · 10 мая, 2017

В 4/30/2017 в 18:14, dexter сказал:
Здравствуйте, пытаюсь поднять IPIP туннель между Ultra2(сервер) и Ultra(клиент). туннель поднимаю по инструкции вместе с ipsec'ом. Но коннекта не идет.

Ругается он на
Apr 30 18:10:11ndmIpSec::Configurator: unable to resolve remote peer address for crypto map "IPIP0" connection.
Постом ниже селф-тесты с обоих железок.

У вас на сервере (в данном случае ультра 2) вместо tunnel destination надо указать tunnel source (и в качестве аргумента WAN-интерфейс или ключевое слово "auto", чтобы использовался интерфейс с default route).

Le ecureuil · 10 мая, 2017

В 5/4/2017 в 18:51, Himmler сказал:

KorDen, оба устройства ревизии А, но безопасность туннеля не интересует вовсе.

ПО не умеет ходить по подсетям, ему нужно, чтобы клиенты были подключены в один маршрутизатор (ну или чтобы для ПО это так выглядело). Потому что ранее пробовал обычный VPN, машины через туннель друг друга пингуют, а вот ПО не видит другую сторону.

Касательно IP - на одной стороне он белый (к нему привязаны KeenDNS и No-IP-dns имена). На другой стороне IP серый (на той, где GPON-модем).

Главная цель - максимальная производительность туннеля. Я так понимаю, разумнее всего поднимать EoIP, и если да, можно ли рассчитывать хотя бы на 30 Мбит/с и увеличение задержки на 3-4 мс ?

С такой целью у вас остается пожалуй только PPTP без шифрования. Зато он будет быстр, и по идее должен пролезть через NAT.

dexter · 10 мая, 2017

Попробовал заново настроить, но ничего не работает.

Ругается он на

May 10 13:29:45ipsec04[IKE] linked key for crypto map '(unnamed)' is not found, still searching 
May 10 13:29:45ipsec04[IKE] no shared key found for '31.129.200.42'[31.129.200.42] - '(null)'[10.228.30.81] 
May 10 13:29:45ipsec04[IKE] no shared key found for 31.129.200.42 - 10.228.30.81 
May 10 13:29:59ndmCommand::Base: no such command: down.

Селф-тесты постом ниже.

Himmler · 10 мая, 2017

Le ecureuil, спасибо за ответы, дальше остаётся только экспериментировать, чем и займусь.

Изменено 10 мая, 2017 пользователем Himmler

Le ecureuil · 10 мая, 2017

9 часов назад, dexter сказал:
Попробовал заново настроить, но ничего не работает.

Ругается он на
May 10 13:29:45ipsec04[IKE] linked key for crypto map '(unnamed)' is not found, still searching 
May 10 13:29:45ipsec04[IKE] no shared key found for '31.129.200.42'[31.129.200.42] - '(null)'[10.228.30.81] 
May 10 13:29:45ipsec04[IKE] no shared key found for 31.129.200.42 - 10.228.30.81 
May 10 13:29:59ndmCommand::Base: no such command: down.
Селф-тесты постом ниже.

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

dexter · 11 мая, 2017

8 часов назад, Le ecureuil сказал:

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

Не за, что. Главное, что бы исправили поскорее.

Le ecureuil · 11 мая, 2017

3 часа назад, dexter сказал:

Не за, что. Главное, что бы исправили поскорее.

Конкретно ваш случай исправлен, появится в ближайшей сборке.

Le ecureuil · 12 мая, 2017

В 4/13/2017 в 17:54, KorDen сказал:

@Le ecureuil, а в EoIP MTU=1500 на кинетике вообще должен работать, или нет? В микротиках, насколько я понимаю, это вполне рабочее решение - да, пакеты бьются на два, но зато не надо править MTU на устройствах при бриджевании с LAN.

Получилось реализовать быстрее, чем изначально думалось.

В следующем draft при задании команды

> system set net.core.eoip_allow_fragment 1

Будет включен режим фрагментации (отключается через задание 0).

При этом MTU на EoIP-интерфейсе фактически будет игнорироваться, в него можно будет слать хоть фреймы в 10К, они будут разбиты по нескольким фрагментам IP-пакета и отправлены в виде фрагментов корректного размера.

Кстати, предыдущая реализация имеет возможность принимать такие пакеты, но не сможет отправлять (то есть сторона-ответчик со старой прошивкой нормально их примет, но ответ больше, чем MTU у EoIP в нее по-прежнему не пролезет).

Просьба кстати проверить совместимость этой фичи с Mikrotik, да и вообще ее "погонять".

KorDen · 12 мая, 2017

1 час назад, Le ecureuil сказал:

Просьба кстати проверить совместимость этой фичи с Mikrotik, да и вообще ее "погонять".

Если взлетит и в моем случае будет приемлемо работать, то возможно будет постоянно гоняться между ультрой и микротиком в виде бриджа с сегментом LAN

Изменено 12 мая, 2017 пользователем KorDen

dexter · 13 мая, 2017

Туннель поднялся, спасибо.

Получил скорость через тоннель с айписек 100мбит при гигабитный аплинках. Загрузка CPU Ultra 2 - 18%, Ultra 1 - 52%?

А за фигу огромное спасибо. Скорости, в любом случае, улет.

Изменено 13 мая, 2017 пользователем dexter

r13 · 13 мая, 2017

В 06.01.2017 в 20:04, r13 сказал:

@Le ecureuil Если туннель(EoIP) создан поверх ручного IPSec туннеля то mtu в ручную выставлять или авто настройка корректно отработает?

В 09.01.2017 в 12:22, Le ecureuil сказал:

Надо вручную, автонастройка работает только при автоматической конфигурации из первого поста.

На прошивке 2.09.A.7.0-3 EoIP "что-то" автоматом подстраивает, правда разное с обоих концов:

May 13 21:20:11ndm
Network::Interface::Tunnel: "EoIP2": resolved destination 10.0.0.1 (10.0.0.1).
May 13 21:20:11ndm
Network::Interface::Tunnel: "EoIP2": resolved source 10.0.0.2.
May 13 21:20:11ndm
Network::Interface::Base: "EoIP2": network MTU is 1326.
May 13 21:20:11ndm
Network::Interface::EoIP: "EoIP2": plain tunnel is ready.

May 13 21:22:01ndm
Network::Interface::Tunnel: "EoIP2": resolved destination 10.0.0.2 (10.0.0.2).
May 13 21:22:01ndm
Network::Interface::Tunnel: "EoIP2": resolved source 10.0.0.1.
May 13 21:22:01ndm
Network::Interface::Base: "EoIP2": network MTU is 1476.
May 13 21:22:01ndm
Network::Interface::EoIP: "EoIP2": plain tunnel is ready.

Ну это так, к слову.

Пытаюсь после включения net.core.eoip_allow_fragment 1

пинговать длинным пакетом, не пролезает

mtu надо на EoIP в этом случае задавать?

Роутер надо перезагружать после net.core.eoip_allow_fragment 1?

Le ecureuil · 13 мая, 2017

13 минуты назад, r13 сказал:
На прошивке 2.09.A.7.0-3 EoIP "что-то" автоматом подстраивает, правда разное с обоих концов:
May 13 21:20:11ndm
Network::Interface::Tunnel: "EoIP2": resolved destination 10.0.0.1 (10.0.0.1).
May 13 21:20:11ndm
Network::Interface::Tunnel: "EoIP2": resolved source 10.0.0.2.
May 13 21:20:11ndm
Network::Interface::Base: "EoIP2": network MTU is 1326.
May 13 21:20:11ndm
Network::Interface::EoIP: "EoIP2": plain tunnel is ready.
May 13 21:22:01ndm
Network::Interface::Tunnel: "EoIP2": resolved destination 10.0.0.2 (10.0.0.2).
May 13 21:22:01ndm
Network::Interface::Tunnel: "EoIP2": resolved source 10.0.0.1.
May 13 21:22:01ndm
Network::Interface::Base: "EoIP2": network MTU is 1476.
May 13 21:22:01ndm
Network::Interface::EoIP: "EoIP2": plain tunnel is ready.
Ну это так, к слову.

Пытаюсь после включения net.core.eoip_allow_fragment 1

пинговать длинным пакетом, не пролезает

mtu надо на EoIP в этом случае задавать?

Роутер надо перезагружать после net.core.eoip_allow_fragment 1?

То, что разное с обоих концов - это нормально, где-то WAN на IPoE, а где-то на PPTP. Естественно, будет разный MTU.

Перезагружать не надо, после появления сообщения в логе все должно начать работать.

Еще проверьте, умеет ли сеть (провайдер/магистраль) правильно передавать фрагментированные пакеты. Это очень важно, поскольку IP-пакеты уже фрагментированы, и сеть их фрагментировать еще раз в случае "непролезания" не сможет. Возможно на WAN у обоих устройств придется снизить MTU до одинаково низкого значения, которое устроит обе стороны (начните с 1400 и по убывающей).

На каком размере пакета перестает пролезать?

Le ecureuil · 13 мая, 2017

14 часа назад, dexter сказал:

Туннель поднялся, спасибо.

Получил скорость через тоннель с айписек 100мбит при гигабитный аплинках. Загрузка CPU Ultra 2 - 18%, Ultra 1 - 52%?

А за фигу огромное спасибо. Скорости, в любом случае, улет.

Ожидаемо, Giga2 слабее по шине памяти и скорости работы CPU, потому она просто не успевает полностью обеспечить работой crypto engine. Двухядерный 7621A с DDR3 успевает

r13 · 13 мая, 2017

10 минут назад, Le ecureuil сказал:

На каком размере пакета перестает пролезать?

1352 - максимально пролезающий.

Буду экспериментировать далее..

Изменено 13 мая, 2017 пользователем r13

dexter · 13 мая, 2017

43 минуты назад, Le ecureuil сказал:

Ожидаемо, Giga2 слабее по шине памяти и скорости работы CPU, потому она просто не успевает полностью обеспечить работой crypto engine. Двухядерный 7621A с DDR3 успевает

Что слабее это понятно. А если с обои концов будут Ultra 2 какой скорости можно достичь?

KorDen · 13 мая, 2017

8 минут назад, dexter сказал:

Что слабее это понятно. А если с обои концов будут Ultra 2 какой скорости можно достичь?

В 27.08.2016 в 23:42, Le ecureuil сказал:

EIP93 стоит в Keenetic II, Giga II, Ultra и поддерживается в 2.06. По скорости - в идеале можно выжать до 170-200 Мбит/сек, от типа шифра и хэширования не зависит (на Keenetic II будет 100 Мбит/с).

EIP93 стоит в Giga III, Ultra II и поддерживается в 2.07 и 2.08. По скорости - в идеале можно выжать до 330 Мбит/сек, от типа шифра и хэширования не зависит.

AES Crypto engine стоит в Start II, Lite III rev. B и 4G rev. B и поддерживается в 2.07 и 2.08. По скорости - в идеале можно выжать до 65-70 Мбит/сек, плюс зависит от типа хэширования, которое всегда выполняется программно.

Le ecureuil · 15 мая, 2017

Ну что, как там с фрагментацией? Оно хоть работает (у кого-то кроме меня)?

Le ecureuil · 15 мая, 2017

В 5/13/2017 в 22:13, r13 сказал:

1352 - максимально пролезающий.

Буду экспериментировать далее..

А dump пакетов на WAN показывает, что создаются фрагменты, или нет?

gaaronk · 15 мая, 2017

Just now, Le ecureuil said:

Ну что, как там с фрагментацией? Оно хоть работает (у кого-то кроме меня)?

О! Фрагментация. Реквестирую crypto ipsec df-bit clear

Le ecureuil · 15 мая, 2017

4 минуты назад, gaaronk сказал:

О! Фрагментация. Реквестирую crypto ipsec df-bit clear

Довольно сложно в реализации, потому пока врядли. Как минимум не раньше IKEv2 для автотуннелей.

r13 · 15 мая, 2017

38 минут назад, Le ecureuil сказал:

А dump пакетов на WAN показывает, что создаются фрагменты, или нет?

Дача в оффлайне, в выходные сделаю.

В том эксперименте был с одной стороны ipoe c другой стороны lte модем c keenetic, между ними ручной site to site ipsec поверх которого eoip. как уже писал, не работало.

Сейчас между двумя точками с ipoe просто через интернет прокинут eoip туннель, проходят пинги до 1486 включительно с компьютера,а из web интерфейса любые, пробовал 10000, проходит. Так что видимо работает фрагментация.

ЗЫ или я не знаю как правильно тестить

ЗЫ2 да в текущем дампе есть фрагментация. Оно или нет?

Скрытый текст

Изменено 15 мая, 2017 пользователем r13

IgaX · 15 мая, 2017

30 минут назад, r13 сказал:

проходят пинги до 1486 включительно с компьютера

а mtu какой на интерфейсе, к которому комп подключается?

Все о туннелях IPIP, GRE и EoIP

Рекомендуемые сообщения

Топ авторов темы

Популярные дни

Топ авторов темы

Популярные дни

Популярные посты

Le ecureuil

Le ecureuil

Le ecureuil

Изображения в теме

Присоединяйтесь к обсуждению

Последние посетители 0 пользователей онлайн

Важная информация