Перейти к содержанию

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

Опубликовано (изменено)

@Le ecureuil, пожалуй, предложу добавить на страницу настройки ipsec-соединения возможность выбора типа шифруемого трафика для mode transport - как мне кажется, это покроет большинство кейсов использования транспортного режима.

Как я это вижу:

firefox_2017-02-09_16-05-35.png.934bb1fe0aa10911b0d438f06f7e925f.png

(в случае установленных галок, добавляются правила только для нужных протоколов, если галок нет - добавляется permit ip, либо поставить отдельную галку "ip", которая делает остальные disabled и стоит по-умолчанию)

Изменено пользователем KorDen
  • 2 недели спустя...
  • Ответов 928
  • Создана
  • Последний ответ

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

Опубликовано

с циской кто-то поднимал ipsec-туннель? мне интересно, если в циске настроено tunnel mode ipsec ipv4 - это по сути gre туннель, только без gre-заголовка, что настраивать на кинетике в этом случае?

И есть ли возможность провести авторизацию на основе сертификатов?

Опубликовано
16 часов назад, Yacudzer сказал:

с циской кто-то поднимал ipsec-туннель? мне интересно, если в циске настроено tunnel mode ipsec ipv4 - это по сути gre туннель, только без gre-заголовка, что настраивать на кинетике в этом случае?

Обычный IPsec в туннельном режиме без энкапсуляций.

Опубликовано

Le ecureuil, теоретически какой скорости можно достичь между Ultra и Ultra 2 используя EoIP туннель с IPSec и без него?

Опубликовано (изменено)

@dexter, на практике у меня по IPIP с IPsec Ultra II <-> Giga II (проц же аналогичен Ultra) при гигабитном линке скорость при передаче в одну сторону порядка 13-14 МБ/с, проц Giga II упирается в полку при этом, вебинтерфейс начинает глючить (жизненно важные функции при этом вроде бы не глючат, поэтому меня все устраивает). EoIP чисто на скорость не тестировал, но думаю будет что-то похожее.

Изменено пользователем KorDen
Опубликовано

Поднял EoIP туннель с удаленной точкой c IPSec. Все работает. Впихнул в бридж. Удобно и просто 5 минут и готово. 

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

Эх... Этот бы функционал кинетикам да лет 5 назад. Тогда я OVPN не изучил бы.

 

Опубликовано

Господа, подскажите пожалуйста, согласно этой статье https://help.keenetic.net/hc/ru/articles/214471405-Организация-туннеля-IPSec-VPN-между-двумя-интернет-центрами-Keenetic-Ultra-II-и-Giga-III получится ли настроить роутер-клиент так, что бы _весь_ трафик подключённых к нему устройств ходил через туннель до основного роутера-сервера? Суть задачи:

Есть Giga 3 у меня дома. Есть Giga 2. Её увожу на дачу, другую квартиру и т.д, G2 подключается по IPSec к G3 и все клиенты подключённые к G2, ходят в интернет по туннелю через G3, т.е. G3 является основным и единственным шлюзом для клиентов. Этот мануал вроде не очень подходит, тут только можно получить доступ к другим подсетям, но не перенаправить весь трафик на G3.

Опубликовано

@JIABP, настраивайте PPTP-сервер/клиент, или попараноидальнее IPIP поверх IPSec (прямиком из шапки), дальше делаете соединение ip global 1000 и у вас резервирование интернета, т.е. трафик ходит через сервер до тех пор пока соединен с ним. Можно убрать галку доступа в инет с основного подключения и добавить ручной маршрут до сервера через основного ISP, тогда при падении туннеля интернета не будет совсем.

Опубликовано

Добрый день всем!
Сегодня начал изучать тема EoIP , понадобилось соединить дом  Keenetic Ultra  (прошивка 2.08)  и дачу  там ТП-линк прошитый на dd-wrt  v15  . Суть в следующем , на даче стоят камеры , а видеорегистратор стоит дома, ну вот и нужно что бы все это было как бы в одной локальной сети.
С чего начать ? желательно конечно через веб-интефейс,

Опубликовано
4 часа назад, Alexei Glomazdov сказал:

Добрый день всем!
Сегодня начал изучать тема EoIP , понадобилось соединить дом  Keenetic Ultra  (прошивка 2.08)  и дачу  там ТП-линк прошитый на dd-wrt  v15  . Суть в следующем , на даче стоят камеры , а видеорегистратор стоит дома, ну вот и нужно что бы все это было как бы в одной локальной сети.
С чего начать ? желательно конечно через веб-интефейс,

Сразу ничего не получится.

- в ddwrt нет eoip

- в ddwrt не ipsec-туннелей

- в web в keenetic это не настраивается 

Опубликовано
В 08.11.2016 в 12:59, Le ecureuil сказал:

Известные ограничения:

- туннели на базе EoIP/IPsec и GRE/IPsec принципиально несовместимы с PPTP-подключениями из-за использования одного и того же протокола GRE. В этом случае остается использовать всего лишь один доступный вариант: IPIP/IPsec.

Мега глупый вопрос.

Поднял  EoIP/IPsec туннель между двумя кинетика. Туннель заработал, удаленный адрес я пингую. Но при этом за Ultra 2(она же EoIP/IPsec сервер) расположена виртуальная машина с Дебиан, на котором поднят обычный PPTP. При этом я спокойно подключаюсь по впн с телефона через мобильный интернет и все работает.

Что я делаю не так и когда оно сломается(Туннель или мой PPTP)?

EoIP/IPsec туннель поднимал из примера в шапке темы.

Опубликовано
15 часов назад, Le ecureuil сказал:

Сразу ничего не получится.

- в ddwrt нет eoip

- в ddwrt не ipsec-туннелей

- в web в keenetic это не настраивается 

-  вместо  Тплинка с dd-wrt  есть mikrotic 941-2nD  .
- без веба будет тяжело ( но возможно

Какой будет порядок действий если пытаться соединить 941-2nD  и Keenetic Ultra   . На обоих белые ip  адреса

Опубликовано
3 часа назад, Alexei Glomazdov сказал:

-  вместо  Тплинка с dd-wrt  есть mikrotic 941-2nD  .
- без веба будет тяжело ( но возможно

Какой будет порядок действий если пытаться соединить 941-2nD  и Keenetic Ultra   . На обоих белые ip  адреса

В первом посте все подробно описано.

Опубликовано
16 часов назад, dexter сказал:

Мега глупый вопрос.

Поднял  EoIP/IPsec туннель между двумя кинетика. Туннель заработал, удаленный адрес я пингую. Но при этом за Ultra 2(она же EoIP/IPsec сервер) расположена виртуальная машина с Дебиан, на котором поднят обычный PPTP. При этом я спокойно подключаюсь по впн с телефона через мобильный интернет и все работает.

Что я делаю не так и когда оно сломается(Туннель или мой PPTP)?

EoIP/IPsec туннель поднимал из примера в шапке темы.

Это не работает в случае, если у вас настроен EoIP/IPsec-сервер, и там же настроен PPTP-клиент. В остальных случаях худо-бедно работает.

Можете полистать первые 2-3 страницы темы, там были живые примеры несовместимости.

  • 2 недели спустя...
Опубликовано

А как настроить что бы при прохождении трафика из сегмента Home в GRE туннель к трафику не применялся NAT ?

Опубликовано
41 минуту назад, gaaronk сказал:

А как настроить что бы при прохождении трафика из сегмента Home в GRE туннель к трафику не применялся NAT ?

Пока есть только хотелка

 

Опубликовано

И еще вопрос.

Попробовал поднять просто IPSec туннель между Giga и удаленным офисом. Локалка на гиге 192.168.19.0/24, на удаленной точке пачка разных сетей вида 192.168.Х.0/24

 

Описываем концы туннеля как 192.168.19.0/24 - 192.168.0.0/16

IPSec поднимается и.... и все умирает. 

 

Как минимум правила вида

Chain _NDM_IPSEC_INPUT_FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndmmark match 0x88
    0     0 DROP       all  --  *      *       192.168.0.0/16       192.168.19.0/24

Убивают пакет от локальной сети к самому рутеру.

И в таблице mangle есть в достатке таких нюансов.

Опубликовано
8 minutes ago, r13 said:

Пока есть только хотелка

 

Нет, ну есть костыль подпинывать ACCEPT через /opt/etc/ndm/netfilter.d

Но это плохая идея. Правила "дергаются" очень часто, можно не успеть со своим скриптом и пара тройка транзитных пакетов улетит в NAT

Опубликовано
В 3/9/2017 в 21:16, gaaronk сказал:

И еще вопрос.

Попробовал поднять просто IPSec туннель между Giga и удаленным офисом. Локалка на гиге 192.168.19.0/24, на удаленной точке пачка разных сетей вида 192.168.Х.0/24

 

Описываем концы туннеля как 192.168.19.0/24 - 192.168.0.0/16

IPSec поднимается и.... и все умирает. 

 

Как минимум правила вида

Chain _NDM_IPSEC_INPUT_FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ndmmark match 0x88
    0     0 DROP       all  --  *      *       192.168.0.0/16       192.168.19.0/24

Убивают пакет от локальной сети к самому рутеру.

И в таблице mangle есть в достатке таких нюансов.

Все верно, если этот пакет пришел через IPsec, то он будет "принят" первым правилом, иначе будет отброшен. Это нужно, чтобы роутер не принимал пакеты из незащищенных сетей и не отправлял пакеты в них, если поднят IPsec с определенной удаленной сетью.

Плюс из-за особенностей работы XFRM локальная и удаленная подсеть не могут пересекаться. Если вам это нужно - используйте Gre, IPIP или EoIP over IPsec.

Опубликовано
В 1/10/2017 в 19:25, distinctive сказал:

По моей проблеме будут комментарии или создавать отдельную тему?

Реализовано.

Создаете на интерфейсе профиль ping-check с обязательным указанием restart-interface (без этого не будет переподключения). На мой взгляд лучше всего указать интервал проверки в 30 секунд, а количество попыток - 3. При меньшем интервале при недоступности удаленной стороны у вас весь лог будет завален сообщениями о рестарте туннеля.

Опубликовано
В 11/10/2016 в 15:53, r13 сказал:

@Le ecureuil В дальнейшем планируете реализовать для клиент серверного режима указывать не конкретный интерфейс а использовать интерфейс текущего подключения к Интернет?

что-то вроде tunnel source default 

что бы работало в том числе в схеме с резервированием интернета

Сделано.

Можете указывать tunnel source auto, при этом будет использоваться любой доступный WAN (а если WAN нет вообще, то соединение уйдет в standby).

Опубликовано
В 3/9/2017 в 20:29, gaaronk сказал:

А как настроить что бы при прохождении трафика из сегмента Home в GRE туннель к трафику не применялся NAT ?

Тоже сделано, см. тут:

 

Опубликовано (изменено)

 

Новая проблема. Исходные данные:

Два кинетика соединены EoIP туннелем, На первом туннель в бридже с домашней подсетью, второй получает ип от первого.

На первом, создаю профиль Ping_Cheсk и вешаю его на туннель, указывая адрес второго роутера для проверки.

НО, проверка не работает, и когда просматривашь профиль то пишет
Network::Interface::IP error[72220772]: "EoIP3": address is not available.
Селф тест в сообщении ниже.

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

EoIP.PNG

 

P.S. На втором роутере, после пропадания первого роутера, проходит проверка, делает рестарт интерфейса, и если после него первый роутер так и не заработал, то появляется точно такая же ошибка. 

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

Как тогда сделать проверку?)

Изменено пользователем distinctive
Опубликовано (изменено)

И еще одна интересная проблема, после того как на роутере 2 вручную поднимаю туннель, то пингчек начинает работать, но при этом происходят ложные срабатывания, и каждые 30 сек происходит рестарт интерфейса. При этом оба роутера друг друга видят.

self-test2.txt

Изменено пользователем distinctive
Опубликовано (изменено)
В 28.02.2017 в 16:21, Le ecureuil сказал:

Сразу ничего не получится.

- в ddwrt нет eoip

- в ddwrt не ipsec-туннелей

- в web в keenetic это не настраивается 

Запоздалая справка по dd-wrt но все же, настройка в WEB можно в bridge. Данная реализация зависит от роутера (его памяти) но если есть USB то через доп пакет для нужного ядра, так как там их 3.2 до 4.х. Пример ниже в прошивке.

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

Linux B 3.10.105 #28682 Tue Feb 28 01:09:15 CET 2017 mips DD-WRT

root@B:~# ifconfig

...

oet1      Link encap:Ethernet  HWaddr 06:хх:хх:хх:хх:37  
          inet addr:192.168.100.1  Bcast:0.0.0.0  Mask:255.255.255.0
 ...

ppp0      Link encap:Point-to-Point Protocol  
....

root@B:~# lsmod
Module                  Size  Used by
etherip                 4372  0
...

root@B:~# ip ro
....

192.168.100.0/24 dev oet1  proto kernel  scope link  src 192.168.100.1
...
root@B:~#

И про ipsec в wiki

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

This deccribes how to use DD-WRT to connect to a Cisco VPN Concentrator using vpnc without auto-reconnect and without connect on startup ....

 

Изменено пользователем vasek00
Опубликовано
2 часа назад, vasek00 сказал:

Запоздалая справка по dd-wrt но все же, настройка в WEB можно в bridge. Данная реализация зависит от роутера (его памяти) но если есть USB то через доп пакет для нужного ядра, так как там их 3.2 до 4.х. Пример ниже в прошивке.

  Скрыть содержимое

Linux B 3.10.105 #28682 Tue Feb 28 01:09:15 CET 2017 mips DD-WRT

root@B:~# ifconfig

...

oet1      Link encap:Ethernet  HWaddr 06:хх:хх:хх:хх:37  
          inet addr:192.168.100.1  Bcast:0.0.0.0  Mask:255.255.255.0
 ...

ppp0      Link encap:Point-to-Point Protocol  
....

root@B:~# lsmod
Module                  Size  Used by
etherip                 4372  0
...

root@B:~# ip ro
....

192.168.100.0/24 dev oet1  proto kernel  scope link  src 192.168.100.1
...
root@B:~#

И про ipsec в wiki

  Показать содержимое

 

А oetX это точно EoIP, а не EtherIP по RFC3378?

Опубликовано
35 минут назад, Le ecureuil сказал:

А oetX это точно EoIP, а не EtherIP по RFC3378?

EtherIP конечно же по RFC3378, но в WEB страница имеет имя - EoIP Tunnel и как следствие по lsmod - etherip.

dmesg | grep etherip
<6>[   31.610000] etherip: Ethernet over IPv4 tunneling driver

Раньше была библиотека конкретная ipip в некоторых сборках, если ее не было то добавлялась.

insmod ipip
ip tunnel add tun0 mode ipip remote x.x.x.x local y.y.y.y
ifconfig tun0 172.16.1.2 netmask 255.255.255.250
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o tun0 -j TCPMSS --clamp-mss-to-pmtu
route add -net 192.168.10.0 netmask 255.255.255.0 gw 172.16.10.2 dev tun0

 

Опубликовано
14 часа назад, distinctive сказал:

 

Новая проблема. Исходные данные:

Два кинетика соединены EoIP туннелем, На первом туннель в бридже с домашней подсетью, второй получает ип от первого.

На первом, создаю профиль Ping_Cheсk и вешаю его на туннель, указывая адрес второго роутера для проверки.

НО, проверка не работает, и когда просматривашь профиль то пишет
Network::Interface::IP error[72220772]: "EoIP3": address is not available.
Селф тест в сообщении ниже.

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

EoIP.PNG

 

P.S. На втором роутере, после пропадания первого роутера, проходит проверка, делает рестарт интерфейса, и если после него первый роутер так и не заработал, то появляется точно такая же ошибка. 

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

Как тогда сделать проверку?)

Задать адрес EoIP3 статикой, а не по DHCP. Именно в этом и кроется причина всех проблем. Да и вообще, если нужен ping-check внутри туннеля, то лучше задать адреса обоих концов статикой.

Опубликовано
13 часа назад, distinctive сказал:

И еще одна интересная проблема, после того как на роутере 2 вручную поднимаю туннель, то пингчек начинает работать, но при этом происходят ложные срабатывания, и каждые 30 сек происходит рестарт интерфейса. При этом оба роутера друг друга видят.

self-test2.txt

Адрес 10.70.70.10 точно отвечает на ping от 10.70.70.200?

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

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

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

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

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

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.