soft_warrior

технически из на страничке приложений - компоненты включены только такие: VPN-сервер SSTP VPN-сервер IKEv1/IPsec VPN-сервер IKEv2/IPsec момент с ключами - нужно сделать минимум 4-5 туннелей, разные PSK ключи в каждом. а не в одном из них. технически у меня ведь 4 входящих IKEv2 и 7 исходящих IKEv1... итого 11 штук... может массовость имеет значение в некоторых случаях... нашел еще одну схему слома логики подключения туннелей все туннели IKEv1 имеют одинаковую конфигурацию, разные только удаленные подсети в том числе по их колву ( по 1-2-3-4 подсети в туннелях). уменьшил до минимума вариации настроек все соединены, все в порядке... выключаем последний по списку из 7 исходящих туннель, меняем ему в фазе 1 группу DH с "14" на "1", включаем - он естественно не соединяется. теперь любой туннель IKEv1 из тех шести кто выше по списку, если ему сделать выкл/вкл, то он уже не сможет соединится, будет постоянный реконнект каждые 6-10 секунд. стоит последний по списку туннель, что "неверно" настроен, выключить - то соединения установятся - и ошибки с реконнектом прекратятся. после спокойно ему вернуть правильную настройку DH с 1 на 14 и запустить - другие туннели уже слетать каждые 6-10 секунд при выкл/вкл уже не будут. это как раз чтото про проникновение настроек туннелей IKEv1 друг в друга... меня немного смущают в логах перекрестные загрузки/выгрузки непонятных PSK ключей между туннелями... вопрос зачем оно вообще нужно? ведь ключ индивидуален для одного туннеля, не для всех в перемешку... зачем оно так странно загружается? я чтото не понимаю в логике этого туннеля? селфтест прикреплю в следующем скрытом сообщении

вновь подтвердил (в 5.0.1 в том числе так и остался ) и заново нашел прямо Баг-Багов. @Le ecureuil я уже про него писал неоднократно в чатах и в нескольких топиках. для группы "IPsec сеть-сеть" IKEv1 туннелей есть прямо супер баг: PSK ключ каким то образом получается один на всех. причем случайный из тех что указаны или последний по списку в конфигурациях... как пятна на солнце покажут. проверяется легко - создаются туннели сначала с одинаковыми PSK ключами, проверяем что все работает... потом меняем ключи с двух сторон соотвественно на различные для каждого туннеля .... и получаем только один работающий туннель, остальные выпадают в ошибку - неверный ключ PSK. если нужно - могу подтвердить селф тестом... долго только делать смену ключей с двух сторон.

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

перед обновлением с v4.3.6.3 до 5.0.1 оставил 3 входящих IKEv2 - они на прошивке работали стабильно. по крайней мере один постоянно в онлайне точно был без рьновления времени обновления ключей. исходящие так же работали без ошибок, как три так и семь до удаления. после обновления: входящий IKEv2 стабильно соединяется. но к ним вопросов и небыло. счетчики трафика вход/исход считаются, показываются, ключи не прыгают по исходящим IKEv1: первый по списку туннель: моргает. второй по списку туннель: живет. счетчик трафика на web показывает "—" на каждом направлении. останавливаю второй туннель, первый моргать не перестает. удаляю второй туннель, первый всеравно моргает. перезагрузка роутера - все так же остается. в след сообщении вложу два комплекта логов и селфтестов

пусть с большим опозданием но добавлю заметку по части физики 4х парного ethernet-a часто свичи неадекватно угорают подвисанием соединения если есть проблема с одним из проводов группы белосиний/синий и белокоричневый/коричневый. если там обрыв в синей паре, то соединение может реально подвиснуть...

@Le ecureuil а в роутере ipv6 прямой доступ вместо "через облако" в опционал возможно в конфиг добавить?

Реально сильно не хватает "пинг тестера соединения" для данного вида туннелей "IPsec подключения Сеть-Сеть". т.к. если была проблема обновления ключей фазы 2 - то связи в туннеле фактически нет. а он как бы остается "логически" цел и здоров... лишь для кинетика, помогает только его выкл/вкл или следующая попытка обновить ключи. именно изза (каким то магическим образом) взаимно проникающих из туннеля в туннель psk-ключей и таймеров обновления ключей в старых прошивках

Реально не NC-1018 а NC-1012... новый девайс. не запомнил еще

Доброго дня всем Есть два роутера: Было: Zyxel Ultra II v4.3.6.2 Стало: Netcraze Giga (NC-1012) v4.3.6.3. это в данный момент - работающий NC-1018 в текущих режимах на указанной прошивке. на текущем и на предыдущем настроено 10 туннелей : 1) 3 Шт входящих IKEv2 в одинаковых конфигурациях: 2) 7 шт исходящих IKEv1 в одинаковых конфигурациях: "Key PSK" у всех одинаковый, т.к. ранее на более низких версий прошивках наблюдалось взаимное проникновение как разных ключей шифрования так и времени смены ключей в соседние туннели ( сейчас не проверял ), стараюсь делать идентичные для минимизации таких случайностей. делаешь одинаковые ключи - работают туннели, делаешь разные, начинается хаос, то ключ не подходит, то подходит... раньше когда то об этом писал. Теперь о результате обновления: обновлял Zyxel Ultra II, перезагрузка - все хорошо. туннели при установке соединения начинают моргать: в каждые несколько секунд обновляя ключи и теряя связь... стабильная работа туннелей естественно невозможна. если остановить 5 из 7 ike1, то оставшиеся два жили вроде нормально... но такое конечно не вариант. возвращался на рабочую прошивку. взял NC-1012: вручную выставил аналогичную ситуацию, передал на него запись keendns, уменьшил разницу между туннелями даже в именах пунктов local и remote. обновление вообще уронило роутер в ступор на несколько минут, на web интерфейс не возможно было зайти минут 10, потом так и не смог завершить отображение соединений пункт "Другие подключения" открывалась правая торона просто несколько минут, и так и не закончла открываться. одна часть - "IPsec-подключения сеть—сеть" висела в "Загрузка...." уже минут 40, без изменений. в журнале log прилично ошибок. self тест не скачивается - таймаут браузера (приложу в сообщении лог файл в архиве) сбросил до заводских настроил все вручную на 5.0.1 без автоустановки соединения было без ошибок. попытка начать соединяться - ни один исходящий туннель не вышел в режим установлено соединений совсем. визуально на форме есть так же ошибка отображения объема входящих и исходящих данных - там либо "0Б" либо какойто "тэг" —

меня больше интерсует "проникновение" информации о фразе шифрования из одного туннеля в другой... тут вопрос даже не про неверно срабатывающий DPD, а то что туннели как то влияют друг на друга - изза своей многочисленности? к сожалению IKEv2 на той стороне не поддерживается и это единственный совместимый протокол туннелей ну и тут возможно из той же оперы: роутер Keeenetic Ultra II - прошивка 4.2.1. при объемном постоянном пинге (10к - 30к фрагменированный пакет) в туннели и/или из них до роутера при таких настройках туннелей роутер периодически стал уходить в жесткий ребут. что никак не радует. просто пинг в инет на хост - никаких проблем нет. хотя раньше я долго не пытался "нагружать" именно туннели и именно большим пакетом пинга... но опять же и перекачки данных туда/обратно на 700мБитах - вообще проблем ни разу не возникало. опять же в туннель не попадает второй маршрут из настроек - тоже глюк.

4.2.1 версия Кинетик Ultra II в монитор при пинге 10к (чтобы он хоть какой то процент сегмента получил ) в ipip туннель с зарегистрированного ip адреса в списке клиентов по какойто причинает данный вид трафика попадать в "незарегистрированные" странно

DPD - обнаружение неработающего пира - включено при чем мой кинетик - инициирующий соединение. лог с текущей даты начиная утра... незначимые строки постарался убрать, ip заменить на ххх.ххх.ххх.nnn туннелей рабочих 7 шт, все ipsec ikev1 конфигурация одинаковая. из глюков что были на 2.16..хх версии, но на 4.2.1/4.2.3 не проверял - нельзя было сделать разные фразы шифрования на разные туннели, бралась от первого инициировавшего начало соединения и просто ко всем применялась, сейчас даже не проверял. второе и далее направления маршрутизации для туннеля на ту сторону, если даже в настройках есть и заполнено, то на туннель никак не применяется, отается только одно - первое по сортировке из них в текущие сутки зависаний было два, заходил на web и делал выкл вкл для туннеля. в 7 ровно, но это мог быть разрыв провайдера. в 12:20-12:30 - один туннель в 12:30- соединился зависший еще с прошлых суток sklad.spb [xx.xxx.xx.2] прожил 10 мин 2 сек и отвалися в 12:40 без помощи, но в статусе на интерфейсе кинетика он был "все хорошо", соединение есть. и прямо сейчас с ним все хорошо, но связи нет (на той стороне пассив - сообщает что нет связи). в 13:50-13:55 - третий туннель log-2024-11-28__3.txt

+1 всем известно - в новой версии прошивки - не только исправлены старые ошибки, но и добавлены НОВЫЕ. а вот их в списке изменений с вероятность в 99.99% не увидишь. +100500 если "инструмент" возврата к предыдущей прошивке будет без сохранения к себе на комп или телефон... возможно может на внешнюю флешку? будет иметь возможность вернуться по железу - кнопкой сброса вернуться к "заводским" - но предыдущей прошивке или командой с web/cli как циско свитч ко второму конфигу или второй биос на материнке....

в холодном можно и иметь usb 4Г свисток к примеру с тарифом билайна "простой", прикупив в нем бессрочный пакет инета.. ток надо всеравно его поддерживать раз в пару мес - через вэбку модема смс там отправить или еще чего. у меня на таком "холодном" - "Тариф Z", но он уже в архиве, хотя в принципе аналогичен новому и достать его можно если захотеть.

вообще интересует "именное" переадресование как dns так и исходящих соединений в установленные vpn туннели и ipip соединения. пример: dns запросы к локальным доменам в туннель, именное соединение по имени с локальными машинами в туннеле. сейчас такое при "основном" роутере кинетик и доменной иерархии хоть и можно организовать, но довольно затратно по усилиям... и не в динамике. желательно dns как прямые *.domain.local -> спрашивать у 192.168.11.2 (а дальше уже маршрутизация так и обратные запросы кто есть: 192.168.11.0/24 -> спрашивать у 192.168.11.2 ну и статические dns записи не помешает возможнось поправить через web интерфейс.