Jump to content

Recommended Posts

Posted

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

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

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

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

Posted

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

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

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

  • Thanks 1
Posted (edited)

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

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

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

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

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

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

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

Posted

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

Posted (edited)
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
Posted
В 4/13/2017 в 17:54, KorDen сказал:

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

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

  • Thanks 4
Posted
В 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. Да, ограничений нет.

Posted
В 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).

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

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

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

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

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

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

Posted

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

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

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
Posted (edited)

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

Edited by Himmler
Posted
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.

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

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

Posted

 

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

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

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

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

 

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

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

  • Thanks 1
Posted
В 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
Posted (edited)
1 час назад, Le ecureuil сказал:

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

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

Edited by KorDen
Posted (edited)

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

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

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

Edited by dexter
Posted
В 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?

Posted
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 и по убывающей).

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted
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
Posted
В 5/13/2017 в 22:13, r13 сказал:

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

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

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

Posted
Just now, Le ecureuil said:

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

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

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

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

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

Posted (edited)
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
Posted
30 минут назад, r13 сказал:

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

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

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...

Important Information

This site uses cookies. By clicking "I accept" or continuing to browse the site, you authorize their use in accordance with the Privacy Policy.