Jump to content
Le ecureuil

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

Recommended Posts

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

  • Thanks 1

Share this post


Link to post
Share on other sites

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

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

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

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

Edited by Himmler

Share this post


Link to post
Share on other sites
19 минут назад, Himmler сказал:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Edited by vasek00

Share this post


Link to post
Share on other sites
В 4/13/2017 в 17:54, KorDen сказал:

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

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

  • Thanks 4

Share this post


Link to post
Share on other sites
В 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. Да, ограничений нет.

Share this post


Link to post
Share on other sites
В 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).

Share this post


Link to post
Share on other sites
В 5/4/2017 в 18:51, Himmler сказал:

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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.

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

  • Thanks 1

Share this post


Link to post
Share on other sites

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

Edited by Himmler

Share this post


Link to post
Share on other sites
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.

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

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

Share this post


Link to post
Share on other sites

 

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

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

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

Share this post


Link to post
Share on other sites
3 часа назад, dexter сказал:

 

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

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

  • Thanks 1

Share this post


Link to post
Share on other sites
В 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, да и вообще ее "погонять".

  • Thanks 2

Share this post


Link to post
Share on other sites
1 час назад, Le ecureuil сказал:

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

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

Edited by KorDen

Share this post


Link to post
Share on other sites

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

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

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

Edited by dexter

Share this post


Link to post
Share on other sites
В 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?

Share this post


Link to post
Share on other sites
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 и по убывающей).

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

Share this post


Link to post
Share on other sites
14 часа назад, dexter сказал:

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

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

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

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

Share this post


Link to post
Share on other sites
10 минут назад, Le ecureuil сказал:

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

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

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

Edited by r13

Share this post


Link to post
Share on other sites
43 минуты назад, Le ecureuil сказал:

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

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

Share this post


Link to post
Share on other sites
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 Мбит/сек, плюс зависит от типа хэширования, которое всегда выполняется программно.

 

  • Thanks 1
  • Upvote 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
В 5/13/2017 в 22:13, r13 сказал:

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

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

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

Share this post


Link to post
Share on other sites
Just now, Le ecureuil said:

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

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

Share this post


Link to post
Share on other sites
4 минуты назад, gaaronk сказал:

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

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

Share this post


Link to post
Share on other sites
38 минут назад, Le ecureuil сказал:

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

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

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

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

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

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

 

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

2017-05-15.thumb.png.f2454bee16123790cea192914f188133.png

 

Edited by r13

Share this post


Link to post
Share on other sites
30 минут назад, r13 сказал:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...