KorDen

@vasek00 речь все о том же - это NIGHTLY/DRAFT - возможно все, вспомним DHCP и другие обсуждения (и мнения разработчиков) в теме про баннер. А @avanti-sysadmin хочет раскатать на живую сеть из нескольких железок. Сломаться может то, чего не ждали. Касательно версий - можно выделить некоторые билды, в которых основные компоненты стабильны (нет критических багов), а дальше уже выбирать, какие из багов не важны. Скажем, я для себя выделил "предновогоднюю" 2.09.A.0.0-3 (2016-12-30) как запасной аэродром, и текущая 2.09.A.1.0-2 тоже не имеет серьезных проблем. Т.е. если охота все же раскатать (например ради туннелей) - поставить какую-то определенную версию и аккуратно обновляться в будущем, предварительно проверяя на парочке локальных. Скажем, смотреть в среду-четверг, много ли багов было за эту неделю, и обновляться до текущей, т.е. с опозаданием приблизительно на неделю. Предварительно бэкапя предыдущую прошивку файликом. От себя скажу: имеется две удаленных Giga II, одна Extra II. Giga II на драфтах с октября, за это время потери удаленного управления при обновлении ни разу не было. Исключение - недавнее обновление DHCP, о котором предупредили заранее, но меня оно обошло стороной, даже специально пытался поломать - а они все еще нормально получали IP. До этого один раз был бутлуп на Ultra II, еще на ранних версиях.

Это только из-за VIP, или есть и другие причины?

Речь шла о трубках, которые можно купить в России. А найти реально только три вышеуказанных, еще в принципе можно найти R650H PRO, SL750 (тут правда есть момент - а действительно ли это та версия? А то там вроде как H - без поддержки, HX/Pro - без поддержки) и Yealink W65H. По более-менее адекватной цене - только S850HX, если исключить панасоник.

Режим "клиент-сервер" не нравится по одной причине - при set-peer с обоих сторон любая из сторон начинает устанавливать соединение с удаленной как только начинает идти трафик. А в клиент-серверном, если скажем перезагрузить ноду 3, надо ждать, пока 1 переподключится к ней. Насколько я понял, в таком виде придется везде использовать единый ключ и версию IKE?

@Le ecureuil Теперь я еще больше запутался :\ Для всех туннелей между роутерами есть прямая видимость в обе стороны, статические IP, у роутеров не пересекающиеся локальные подсети. Нужно чтобы все локалки видели друг друга (в том числе #3-#5 через 3-1-2-5), поэтому я склоняюсь к IPIP поверх ручного транспорта IPsec, без серверов. #1-#2 - кинетики, остальное - кинетики/микротики. Плюс есть road-warrior'ы за всевозможными NAToverNATbehindNAT, для них и нужен сервер(ы), скорее всего VirtualIP. В принципе не критично, если закинуть их только на #1 или #2. Возможно ли для межроутерных туннелей использовать одни параметры (в частности, ключ) первой фазы, а для удаленщиков - другие? Или все должно совпадать везде?

При одновременной настройке двух и более роутеров (например, настройка туннелей между роутерами) легко запутаться, на каком в данный момент сидишь Предлагаю добавить: - отображение хостнейма в CLI вида "RouterName(config)>" - отображаение хостнейма в <title> веб-интерфейса в виде "RouterName - ModelName - PageName" - отображение хостнейма и, возможно, snmp location в веб-интерфейсе, в идеале справа (PC)/снизу(mobile) от .header-model. snmp location как вариант можно отображать в "О системе" в дашборде.

Т.е., (еще раз для завершения картинки в голове) я правильно понимаю, что если с обоих сторон будет прямая видимость и указаны set-peer 1.2.3.4 (а не set-peer any на "сервере"), то параметры таких туннелей могут быть индивидуальными, в таком случае на этом роутере едиными должны быть только параметры для VirtrualIP-сервера и туннеля-"сервера" для клиента за NAT? И в автоматическом режиме такое изначально невозможно, т.к. один из пиров обязательно должен являться сервером, два tunnel destination быть не может, так?

На всякий случай, хотелось бы уточнить, чтобы не тратить время на поиск того чего быть не может: все это верно так же и для ручного режима, или есть оговорки? Если, скажем, я хочу сделать на одном роутере несколько ручных транспортов точка-точка и VirtualIP-сервер для смартфонов - это вообще возможно? Во всех случаях должны быть одни и те же параметры первой фазы?

Я именно так и делаю, но все равно периодически ловлю глюки. Например: (ipsec был выключен) сделал конфигурацию, которую отправил вам, "service ipsec", попробовал пропинговать с компа за ультрой удаленный роутер - не пошло, в логах то что приводил в примере. Останавливаю ipsec на обоих роутерах, прописываю id, запускаю, жду инициализации по логам, пытаюсь опять пропинговать с компа за ульттрой - пинги не идут, в логах тишина, хотя "show ipsec" показывает политику. Пытаюсь пропинговать с компа за гигой - начинается согласование. А иной раз может и первый раз пойти (когда после перевключения пингую с ультры). Хотя может это винда чудит, надо будет попробовать пинговать прямо с роутеров.

Это не хеш, это обратимое шифрование, причем по одному алгоритму с общим ключом...

Прислал. Еще замечу - при изменении настроек без перезагрузки можно получить глюкодром. Все изменения обычно делаю при отключенном ipsec - т.е. "no service ipsec" на обоих роутерах, выжидаю 5-10 сек, меняю что-то, включаю - и тут может происходить что угодно. Поэтому пока обычно любое изменение сопровождается перезагрузкой обоих роутеров. Как минимум один из глюков, на который неоднократно попадал - не срабатывает политика: останавливаю - прописываю удаленный id или меняю ikev1/v2, запускаю (на обоих роутерах выполняю синхронно), в Routed Connections запись про icmp появляется (и по логам вроде все как обычно), но при пинге SA не поднимается, в логах тишина, пинг не проходит вообще. Причем с другой стороны в этот момент если пинговать - может начаться согласование, а может и тоже быть тишина.

Кажется, у меня что-то очень похожее наблюдается, только с настройкой ручного транспорта. Хотя не исключаю, что у меня что-то другое Насколько я понял свою ситуацию: роутеру не удается найти ключ, пока удаленный идентификатор "any". Имеем Ultra II <-> Giga II, 2.09.A.0.0-3. Пытаюсь настроить ручной транспорт, конфиг с одной из сторон: Пингуем и получаем: I [Jan 16 23:25:24] ipsec: 16[IKE] 1.2.3.4 is initiating an IKE_SA I [Jan 16 23:25:24] ipsec: 16[CFG] received proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# I [Jan 16 23:25:24] ipsec: 16[CFG] configured proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# I [Jan 16 23:25:24] ipsec: 16[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/# I [Jan 16 23:25:25] ipsec: 06[CFG] looking for peer configs matching 5.6.7.8[%any]...1.2.3.4[thorn@ilirea.alagaesia] I [Jan 16 23:25:25] ipsec: 06[CFG] selected peer config 'Ilirea' I [Jan 16 23:25:25] ipsec: 06[IKE] linked key for crypto map 'Ilirea' is not found, still searching I [Jan 16 23:25:25] ipsec: 06[IKE] no shared key found for '%any' - 'thorn@ilirea.alagaesia' E [Jan 16 23:25:25] ndm: IpSec::Configurator: unable to authenticate remote peer for crypto map "Ilirea". W [Jan 16 23:25:25] ndm: IpSec::Configurator: (possibly because of wrong local/remote ID). Стоит с обоих сторон прописать match-identity-remote email ... - и транспорт поднимается.

Хорошую темку подняли.. Только это надо не в "Развитие", а в "сборку"... Никто таки не пробовал реально заводить хуавеи с поддержкой голоса на кинетике? Я все думаю, стоит заморачиваться с поиском нужного модема, или это бессмысленно. Кто желает почитать - легко гуглится например по "huawei e1550 sip" и подобным. Вот например про асусы - https://habrahabr.ru/sandbox/32290/

(могу ошибаться) Голый IPSec на то и голый IPSec, что не маршрутизируется ни в одну, ни в другую сторону, т.к. использует политики, а не маршрутизацию... А подружить одновременно IPIP/IPSec-"сервер" и VirtualIP-сервер на одном роутере лично у меня пока не получилось - что-то одно да не работает

Вопрос, который давно уже поднимался, но лично для меня встал острее с появлением туннелей. На текущий момент единственный вариант не натировать сеть через туннель - отключить ip nat полностью, воспользовавшись ip static, однако он требует наличия статического IP - https://zyxel.ru/kb/3252/ По вполне очевидным причинам во многих случаях этот вариант совсем не приемлем (разве что играться со скриптами в entware). Варианты реализации с точки зрения пользователя, на мой взгляд: - в ip nat добавить опциональный исходящий интерфейс, описывая таким образом что натить, а что нет (скажем, натить Home->ISP, Guest ->ISP, IPIP0->ISP, но не натить IPIP<->Home) - в ip static добавить возможность указания исходящего интерфейса, чтобы автоматически брался IP с этого интерфейса

Через голый IPsec-туннель маршрутизация не проходит, нужно делать туннель L2TP/IPIP/GRE/EoIP over IPsec, о последних трех в соседней теме...

@r13, а, я думал, у вас транспортом настроен.. ведь туннель через туннель = лишние служебные данные = меньший MTU... Надо будет попробовать со второй точкой на стенде, а не на живом.. А то мне кажется, там надо было просто ребутнуть, ведь после удаления транспорта я так и не мог пинговать удаленный роутер, пока не ребутнул оба...

@r13, можете привести пример рабочей настройки IPSec-транспорта для ручного туннеля? Я для начала попробовал создать через веб, указав в качестве IP сети назначения IP удаленного шлюза/32, и соответственно IP роутера в качестве локального, а потом поправить access-list (вместо permit ip ... сделать permit ipip LOCALIP 255.255.255.255 REMOTEIP 255.255.255.255) - но туннель так и не поднялся, и роутеры стали недоступны друг для друга. ЧЯДНТ?

Знаю, что все сильно нестандартно, "просто оставлю это здесь". Имеем: две сетки через IPIP - 192.168.0.1/24 и 192.168.1.1/24. На первом роутере порты Telnet/Web нестандартные. cloudcontrol не установлен на обоих роутерах. Смартфон с установленным MyKeenetic 2.23 подключен к .0.1. Жму "Ок, Wi-Fi подключен". Вначале мне выдается "Похоже, что вы пытаетесь подключиться не к интернет-центру Keenetic", секунд через пять это сообщение само пропадает и спрашивает пароль. Офигеваю (он что, просканировал все порты?), ввожу пароль. Не подходит. Fast forward - понадобилось зайти на удаленный роутер - а там в логах куча попыток входа с моего IP. Начинаю догадываться, ввожу пароль от удаленного роутера - он подключается к нему. Только как-то странно - вроде видит удаленный роутер, но выбрасывает, открывает через раз, короче ведет себя неадекватно. Выкинуло на авторизацию повторно, ввел неверный пароль опять - в логах бесконечный перебор, приложение упорно не хочет показывать, что пароль неверный Мне оно как бы не нужно, и я понимаю, что моя конфигурация шибко для него нестандартная, но оставлю здесь

@cbloner шифрует и MD5/DES, я немного спутал (мне казалось, что EIP умеет только 3DES/AES/SHA), вот: Могу сильно ошибаться, но вроде бы шифрование на процент служебных данных не влияет. Т.е. в пакете есть фрагмент IPsec, и есть данные. Зашифрованы они (и как) или нет - не важно.

Нет, это сырые данные для #dashboard.connections. По крайней мере для 2.09 ссылка такая, может на стабильных версиях отличается. Что-то типа

Открываете http://192.168.1.1/rci/show/ip/nat и дальше парсите как надо

А как-то можно узнать, какие трубки его поддерживают, по списку или косвенным признакам? В инструкции вроде пишут только про CAT-iq 2.0 для новых трубок, про 1 никто не пишет, насколько я понимаю. Скажем, есть трубки Gigaset A420 - в инструкции только стандартное "Поддержка DECT/GAP", про качество звука говорится только в контексте маркетинговой технологии полнодуплексной передачи на громкой связи. Или пока единственный вариант - банальный - подключить две такие трубки к кинетику на разные линии и сравнивать качество при внутреннем и внешнем вызовах между ними?

Может немного глупое предложение.. Но зачем вам DES/MD5, при двух ультрах? AES-128/SHA1 прекрасно ускоряется аппаратно и с ними лично у меня фризов не замечалось, кроме как при пересогласовании.

Так есть же, если не ошибаюсь, 183 Progress with SDP или как там, который Early Media.. Другой вопрос, что его не все операторы поддерживают передачу пользовательского Early Media и второй стороне выдают стандартный гудок... В любом случае, IMO это на данной стадии лишнее - ведь все это можно реализовать через промежуточный астер в энтвари/дебиане, и это уже функции PBX.. Гораздо интересно развитие именно взаимосвязи трубок с базой и возможностями SIP, хотя бы для дорогих трубок... Я тут думал про репитеры или микросотовую сеть из нескольких DECT-модулей (DECT-соты) - чисто теоретически интересно, возможно ли что-нибудь подобное на текущих модулях? Понятно, что количество поддерживаемых трубок совсем не то, что у серьезных DECT-микросот, и хэндовер наверное не получится (хотя, интересно, можно ли синхронизироваться по IP?), тем не менее...