Le ecureuil Posted April 19, 2017 Share Posted April 19, 2017 10 минут назад, Finish25 сказал: В конфиге есть такая строчка crypto ipsec mtu auto, вопрос- какой будет итоговый mtu ipsec канала от giga2 если выход в интернет идет через L2TP c mtu 1460(по умолчанию роутер создает подключение L2TP c mtu 1400) параметры подключения фаза1 AES-256 SHA1 DH5, фаза 2 AES-128 SHA1 DH5 MTU у IPsec канала не бывает. Эта настройка включает подстройку TCP MSS согласно MTU на WAN. Quote Link to comment Share on other sites More sharing options...
Finish25 Posted April 19, 2017 Share Posted April 19, 2017 2 минуты назад, Le ecureuil сказал: MTU у IPsec канала не бывает. Эта настройка включает подстройку TCP MSS согласно MTU на WAN. Тогда для чего там же set-tcpmss pmtu? На WAN стоит mtu 1500, учитывается ли, что выход в инет идет через L2TP с mtu 1460. Методом тыка выяснил, что без фрагментации через канал проходит только 1390, все что больше- фрагментируется после шифрования(я так понимаю не пролазит по L2TP), роутер на другом конце перед расшифровкой собирает пакеты. Quote Link to comment Share on other sites More sharing options...
Finish25 Posted April 19, 2017 Share Posted April 19, 2017 Вот тут IP MTU и туннели IPSec и GRE считают что есть mtu Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted April 21, 2017 Share Posted April 21, 2017 В 4/19/2017 в 18:44, Finish25 сказал: Вот тут IP MTU и туннели IPSec и GRE считают что есть mtu MTU есть, но на интерфейсах (собственно, по ссылке так и говорят). А у IPsec XFRM нет интерфейсов. Quote Link to comment Share on other sites More sharing options...
JIABP Posted April 21, 2017 Share Posted April 21, 2017 (edited) В 13.03.2017 в 13:23, Finish25 сказал: kernel: EIP93: PE ring[56] error: AUTH_ERR(весь лог быстро забивается) @Le ecureuil У меня тоже самое - вчера роутер без видимой причины (ни впн соединений активных ни прочих игрищ не устраивал - серфил интернет и слушал онлайн радио с Win10 ноутбука) ребутнулся. Я уже поставил Kisi Syslog Server и буду собирать инфо, если ещё ребут будет. Что нибудь с меня надо? Тред создать, селф-тест снять и т.д.? P.S. Giga 3, K+DSL, K+DECT, HDD. Edited April 21, 2017 by JIABP Quote Link to comment Share on other sites More sharing options...
Finish25 Posted April 22, 2017 Share Posted April 22, 2017 (edited) kernel: EIP93: PE ring[56] error: AUTH_ERR сегодня так же без видимых причин посыпались ошибки. v2.08(AAFS.0)C1 Edited April 22, 2017 by Finish25 Quote Link to comment Share on other sites More sharing options...
chikavladimir Posted April 23, 2017 Share Posted April 23, 2017 (edited) Добрый день. Имеется два keenetic viva прошивка v2.08(AANT.0)C2, на которых поднят IPsec vpn (в режиме тоннеля). В подсети 1 сидит контроллер домена и DNS, в подсети 2 есть клиенты которым нужен этот DNS. Канал сам по себе отлично работает, сети друг друга видят. Но как только я включаю на роутере подсети 1 настройку Yandex DNS или SKYDns весь трафик UDP 53 который нужен для запросов к серверу DNS перехватывается и уходит непонятно куда. Перехват пакетов вообще ничего не видит, соответственно домен перестает работать. Можно как-то завернуть трафик для запросов к моему DNS мимо яндекса? Спасибо! Edited April 23, 2017 by chikavladimir Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted April 24, 2017 Share Posted April 24, 2017 12 часа назад, chikavladimir сказал: Добрый день. Имеется два keenetic viva прошивка v2.08(AANT.0)C2, на которых поднят IPsec vpn (в режиме тоннеля). В подсети 1 сидит контроллер домена и DNS, в подсети 2 есть клиенты которым нужен этот DNS. Канал сам по себе отлично работает, сети друг друга видят. Но как только я включаю на роутере подсети 1 настройку Yandex DNS или SKYDns весь трафик UDP 53 который нужен для запросов к серверу DNS перехватывается и уходит непонятно куда. Перехват пакетов вообще ничего не видит, соответственно домен перестает работать. Можно как-то завернуть трафик для запросов к моему DNS мимо яндекса? Спасибо! Прямо сейчас это невозможно. Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted April 24, 2017 Share Posted April 24, 2017 @Finish25 @JIABP AUTH_ERR говорит о потере пакетов или об их повреждении при передаче через сеть. Quote Link to comment Share on other sites More sharing options...
chikavladimir Posted April 24, 2017 Share Posted April 24, 2017 4 hours ago, Le ecureuil said: Прямо сейчас это невозможно. Понятно, спасибо за информацию, думал что я что-то не то делаю. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 27, 2017 Share Posted May 27, 2017 В 2.09.A.9.0-0 сломали ручные transport туннели На большом сервер я вижу keen-tun[455]: ESTABLISHED 32 seconds ago, 2.2.2.2[first.test.com]...1.1.1.1[keen.test.com] keen-tun[455]: IKEv2 SPIs: 32915b5f5a09ff39_i 389258019666757e_r*, pre-shared key reauthentication in 23 hours keen-tun[455]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 keen-tun{358}: INSTALLED, TRANSPORT, reqid 2, ESP SPIs: c1ef525e_i cddfb68e_o keen-tun{358}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 588 bytes_o (7 pkts, 32s ago), rekeying in 5 hours keen-tun{358}: 2.2.2.2/32[gre] === 1.1.1.10/32[gre] При этом на кинетике туннель висит в состоянии first-tunnel[96]: CONNECTING, 1.1.1.1[keen.test.com]...2.2.2.2[first.test.com] first-tunnel[96]: IKEv2 SPIs: 32915b5f5a09ff39_i* 389258019666757e_r first-tunnel[96]: IKE proposal: AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048/# first-tunnel[96]: Tasks active: IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME и #ip x s src 2.2.2.2 dst 1.1.1.1 proto esp spi 0xcddfb68e reqid 0 mode tunnel replay-window 0 sel src 2.2.2.2/32 dst 1.1.1.1/32 src 1.1.1.1 dst 2.2.2.2 proto esp spi 0x00000000 reqid 35 mode transport replay-window 0 sel src 1.1.1.1/32 dst 2.2.2.2/32 proto gre key 0 Почему моде тунель, хотя должен быть транспорт? Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 27, 2017 Share Posted May 27, 2017 (edited) Извините, был напуган. Это все мои кривые руки. Туннели работают нормально. UPD как я добился такого странного эффекта могу рассказать. Обычный пользователь такого конечно не сделает. Но на swan на x86 машине это к такому не приводит. Edited May 27, 2017 by gaaronk Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 27, 2017 Share Posted May 27, 2017 А вот не кривые руки На вкладке /#security.ipsec есть только туннели и кнопка Add для нового туннеля. А опции VPN Server нет вообще Страничка выглядит так Quote Link to comment Share on other sites More sharing options...
r13 Posted May 27, 2017 Share Posted May 27, 2017 (edited) 1 час назад, gaaronk сказал: А вот не кривые руки На вкладке /#security.ipsec есть только туннели и кнопка Add для нового туннеля. А опции VPN Server нет вообще Страничка выглядит так Сервер переехал в приложения ЗЫ и в системном мониторе теперь virtualip тоже показывается. Edited May 27, 2017 by r13 Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted May 27, 2017 Share Posted May 27, 2017 3 часа назад, gaaronk сказал: А вот не кривые руки На вкладке /#security.ipsec есть только туннели и кнопка Add для нового туннеля. А опции VPN Server нет вообще Страничка выглядит так Все верно, это новый дизайн этой страницы. IPsec Xauth PSK сервер переехал в "Приложения". Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted May 27, 2017 Share Posted May 27, 2017 3 часа назад, gaaronk сказал: Извините, был напуган. Это все мои кривые руки. Туннели работают нормально. UPD как я добился такого странного эффекта могу рассказать. Обычный пользователь такого конечно не сделает. Но на swan на x86 машине это к такому не приводит. Опишите, интересно. Возможно добавим защиту "от дурака", если это и впрямь невалидные действия. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 27, 2017 Share Posted May 27, 2017 15 minutes ago, Le ecureuil said: Опишите, интересно. Возможно добавим защиту "от дурака", если это и впрямь невалидные действия. Это разве что от совсем инициативного дурака. в конфиг стронгсавна было добавлено charon { threads = 10 } Quote Link to comment Share on other sites More sharing options...
timon348 Posted July 4, 2017 Share Posted July 4, 2017 (edited) Товарищи, пишу мольбу, сил больше моих нет)) 4 дня ломаю голову, через почту с техподдержкой больше не могу общаться, ответ через день. А времени в обрез. Картина такая... Имеется в офисе Giga III (v2.08(AAUW.0)C2), статический белый ip адрес. Два склада, в одном Omni II (v2.08(AAUS.0)C2), во втором 4G III (v2.08(AAUR.0)C2), на обоих роутерах висят модемы Yota, с динамическими ip. Третьи день не могу настроить ipsec тунели, чтобы работали оба)) Соответственно Giga в роли сервера, склады клиенты. Для первого туннеля (giga-omni) идентичные настройки клиент/сервер (шифрование, время ключей и т.п.), для второго (giga-4g) тоже. Версия протокола ikev2. У этих двух туннелей разные локальные ID и PSK ключи, все остальное одинаково, разумеется не берем в расчет подсети, они разные. Все настроил, оба туннеля поднялись. Изначально стояла смена ключей фаза1 через 3600сек. Как только этот час подошел, один туннель отваливается на Omni II и больше не подключается (кусок лога ниже), на 4G III держит вроде норм соединение. Куда глядеть? Или сразу застрелиться)) Ну реально чертовщина.. UDP... Удалил с Giga III настройки туннеля до склада с Omni II, и на Omni тоже... Заново создал туннель, изменил локальный id и ключ psk, установил время жизни ike 86400. Туннель поднялся) Оба туннеля работают. НО! Что ждет после того как пройдут сутки. Снова отвалится какой нить из этих туннелей и останется только один. Что же это может быть??? Edited July 4, 2017 by timon348 udp. изменил настройки Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 4, 2017 Share Posted July 4, 2017 1 час назад, timon348 сказал: Товарищи, пишу мольбу, сил больше моих нет)) 4 дня ломаю голову, через почту с техподдержкой больше не могу общаться, ответ через день. А времени в обрез. Картина такая... Имеется в офисе Giga III (v2.08(AAUW.0)C2), статический белый ip адрес. Два склада, в одном Omni II (v2.08(AAUS.0)C2), во втором 4G III (v2.08(AAUR.0)C2), на обоих роутерах висят модемы Yota, с динамическими ip. Третьи день не могу настроить ipsec тунели, чтобы работали оба)) Соответственно Giga в роли сервера, склады клиенты. Для первого туннеля (giga-omni) идентичные настройки клиент/сервер (шифрование, время ключей и т.п.), для второго (giga-4g) тоже. Версия протокола ikev2. У этих двух туннелей разные локальные ID и PSK ключи, все остальное одинаково, разумеется не берем в расчет подсети, они разные. Все настроил, оба туннеля поднялись. Изначально стояла смена ключей фаза1 через 3600сек. Как только этот час подошел, один туннель отваливается на Omni II и больше не подключается (кусок лога ниже), на 4G III держит вроде норм соединение. Куда глядеть? Или сразу застрелиться)) Ну реально чертовщина.. UDP... Удалил с Giga III настройки туннеля до склада с Omni II, и на Omni тоже... Заново создал туннель, изменил локальный id и ключ psk, установил время жизни ike 86400. Туннель поднялся) Оба туннеля работают. НО! Что ждет после того как пройдут сутки. Снова отвалится какой нить из этих туннелей и останется только один. Что же это может быть??? И где self-test со всех трех устройств? Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 4, 2017 Share Posted July 4, 2017 @timon348 Вот смотрите. У вас на клиенте с 4G так: identity-local email 7443434@mail.ru match-identity-remote email 7443434@mail.ru А на сервере так: crypto ipsec profile Office-Bakaleya dpd-interval 130 identity-local email 7443438@mail.ru match-identity-remote any authentication-local pre-share mode tunnel policy Office-Bakaleya ! crypto ipsec profile Office-Myaso dpd-interval 130 identity-local email 7443434@mail.ru match-identity-remote any authentication-local pre-share mode tunnel policy Office-Myaso ! А должно быть на сервере вот так: crypto ipsec profile Office-Bakaleya dpd-interval 130 identity-local email 7443438@mail.ru match-identity-remote email 7443438@mail.ru authentication-local pre-share mode tunnel policy Office-Bakaleya ! crypto ipsec profile Office-Myaso dpd-interval 130 identity-local email 7443434@mail.ru match-identity-remote email 7443438@mail.ru authentication-local pre-share mode tunnel policy Office-Myaso ! То есть ID сторон должны быть заполнены и совпадать с каждым из клиентов. Quote Link to comment Share on other sites More sharing options...
timon348 Posted July 4, 2017 Share Posted July 4, 2017 (edited) 33 минуты назад, Le ecureuil сказал: @timon348 Вот смотрите. У вас на клиенте с 4G так: identity-local email 7443434@mail.ru match-identity-remote email 7443434@mail.ru А на сервере так: crypto ipsec profile Office-Bakaleya dpd-interval 130 identity-local email 7443438@mail.ru match-identity-remote any authentication-local pre-share mode tunnel policy Office-Bakaleya ! crypto ipsec profile Office-Myaso dpd-interval 130 identity-local email 7443434@mail.ru match-identity-remote any authentication-local pre-share mode tunnel policy Office-Myaso ! А должно быть на сервере вот так: crypto ipsec profile Office-Bakaleya dpd-interval 130 identity-local email 7443438@mail.ru match-identity-remote email 7443438@mail.ru authentication-local pre-share mode tunnel policy Office-Bakaleya ! crypto ipsec profile Office-Myaso dpd-interval 130 identity-local email 7443434@mail.ru match-identity-remote email 7443438@mail.ru authentication-local pre-share mode tunnel policy Office-Myaso ! То есть ID сторон должны быть заполнены и совпадать с каждым из клиентов. Но, как я их смогу заполнить, если на стороне сервера "Идентификатор удаленного шлюза" стоит "Any" и он не активен, т.е. изменить нельзя. Можно, если убрать галочку "Ожидать подключение от удаленного пира", но тогда надо вписать удаленный шлюз, но как? если на удаленном складе динамические ip. Вписать 0.0.0.0?) И у меня 2 туннеля. Т.е. локальный идентификатор на сервере для обоих туннелей должен быть одинаковый, а удаленные разные? Но все равно остается вопрос как их вписать, если идентификатор уд.шлюза не активен Edited July 4, 2017 by timon348 Quote Link to comment Share on other sites More sharing options...
KorDen Posted July 4, 2017 Share Posted July 4, 2017 23 минуты назад, timon348 сказал: на стороне сервера "Идентификатор удаленного шлюза" стоит "Any" и он не активен, т.е. изменить нельзя. Он не активен если стоит IKEv1, при IKEv2 он доступен Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 4, 2017 Share Posted July 4, 2017 30 минут назад, timon348 сказал: Но, как я их смогу заполнить, если на стороне сервера "Идентификатор удаленного шлюза" стоит "Any" и он не активен, т.е. изменить нельзя. Можно, если убрать галочку "Ожидать подключение от удаленного пира", но тогда надо вписать удаленный шлюз, но как? если на удаленном складе динамические ip. Вписать 0.0.0.0?) И у меня 2 туннеля. Т.е. локальный идентификатор на сервере для обоих туннелей должен быть одинаковый, а удаленные разные? Но все равно остается вопрос как их вписать, если идентификатор уд.шлюза не активен Поставьте везде 2.09 или 2.10. Этот баг в Web уже давно поправлен в них. Quote Link to comment Share on other sites More sharing options...
timon348 Posted July 4, 2017 Share Posted July 4, 2017 2 минуты назад, KorDen сказал: Он не активен если стоит IKEv1, при IKEv2 он доступен сервер, ikev2 Quote Link to comment Share on other sites More sharing options...
timon348 Posted July 4, 2017 Share Posted July 4, 2017 6 минут назад, Le ecureuil сказал: Поставьте везде 2.09 или 2.10. Этот баг в Web уже давно поправлен в них. т.е. beta-версию? сейчас последние релизы стоят Quote Link to comment Share on other sites More sharing options...
KorDen Posted July 4, 2017 Share Posted July 4, 2017 (edited) 9 минут назад, timon348 сказал: сервер, ikev2 2.10 draft, аналогично на 2.09.B.0.0-1 beta А вот на v2.08.C действительно как у вас Edited July 4, 2017 by KorDen Quote Link to comment Share on other sites More sharing options...
timon348 Posted July 4, 2017 Share Posted July 4, 2017 2 часа назад, Le ecureuil сказал: Поставьте везде 2.09 или 2.10. Этот баг в Web уже давно поправлен в них. обновил Giga до 2.09.B.0.0-1, теперь могу менять идентификатор удаленного шлюза. Ок) Т.е для корректной работы мне надо для обоих туннелей прописать на стороне сервера Giga III одинаковый локальный ID (к примеру 7443438@mail.ru), а удаленный соответственно прописать как на удаленных клиентах? И разный ключ PSK? Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 5, 2017 Share Posted July 5, 2017 8 часов назад, timon348 сказал: обновил Giga до 2.09.B.0.0-1, теперь могу менять идентификатор удаленного шлюза. Ок) Т.е для корректной работы мне надо для обоих туннелей прописать на стороне сервера Giga III одинаковый локальный ID (к примеру 7443438@mail.ru), а удаленный соответственно прописать как на удаленных клиентах? И разный ключ PSK? Ключ может быть любой, в том числе и одинаковый. Правило такое - локальный для одной стороны должен совпадать с удаленным для другой стороны. Все. В итоге у роутеров GIGA и 4G идентификаторы должны быть прописаны так: на GIGA: local: GIGA, remote: 4G; на 4G: local: 4G, remote: GIGA. Quote Link to comment Share on other sites More sharing options...
timon348 Posted July 6, 2017 Share Posted July 6, 2017 В 05.07.2017 в 09:56, Le ecureuil сказал: Ключ может быть любой, в том числе и одинаковый. Правило такое - локальный для одной стороны должен совпадать с удаленным для другой стороны. Все. В итоге у роутеров GIGA и 4G идентификаторы должны быть прописаны так: на GIGA: local: GIGA, remote: 4G; на 4G: local: 4G, remote: GIGA. Огромное спасибо за помощь!!! Уже сутки коннект на обоих туннелях держится)) Проблема решена! А ломал бы голову еще долго) Значит релиз 2.08 на Giga III был косячный в этом плане, из-за невозможности указать удаленный id в режиме ожидания подключения. Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted July 6, 2017 Share Posted July 6, 2017 12 минуты назад, timon348 сказал: Огромное спасибо за помощь!!! Уже сутки коннект на обоих туннелях держится)) Проблема решена! А ломал бы голову еще долго) Значит релиз 2.08 на Giga III был косячный в этом плане, из-за невозможности указать удаленный id в режиме ожидания подключения. Да, но скоро выйдет официальный релиз 2.09, и потому решили в 2.08 из-за этого не переносить исправление. Причем через cli задать можно было всегда, это всего лишь особенность веба. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.