Max Zia
-
Posts
21 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Max Zia
-
-
по скринам настроек клиента и сервера было бы гораздо проще догадаться о причине
-
3 hours ago, Parashutik said:
Здравствуйт! Проблема такая. Установил все по инструкции (роутер новый OMNI), раньше делал на GIGA. При подключении на порт 222 отбрасывает. Подключается на 22 порт. (Это при условии что запущен SSH сервер, если нет , то отбрасывает и на этом порту). Логин : root. Пароль либо keenetic, либо zuxel ответ один "Доступ запрещен". Подскажите куда смотреть и что делать? Ветку эту прочитал.
А что в ssh -v видно?
SSH-сервер в UI это просто cli. Чтобы полноценно шатать файловую систему, надо OPKG предварительно поставить.
-
On 3/24/2021 at 7:24 AM, danil-v said:
Зная, что EoIP поднимается только на двух белых адресах, делаю следующее:
EoIP отлично работает и с одним белым адресом:
Сервер
tunnel source ISP
Клиент:
tunnel destination внешний_hostname_сервера
-
1
-
-
2 hours ago, zyxmon said:
Отредактируйте S51dropbear и пропишите в нем `PIDFILE="/tmp/dropbear.pid"`
так и сделал, наблюдаю 👌🏻
-
всё так. Получилось стечение факторов: S51* определяет статус демона по пид-файлу, в то же время, пид-файл по дефолту хранится на том же разделе, что и opkg.
-
похоже, при обновлении не удаляется файл /opt/var/run/dropbear.pid, поэтому dropbear_status (всегда) =1.
Удаление файла вручную и рестарт помогли друпберу запуститься успешно
-
On 10/9/2020 at 11:14 PM, r13 said:
Тот же адрес сервера впишите(keendns)
22 hours ago, Le ecureuil said:У iOS и macOS remote id == fqdn.
спасибо, отлично заработало
скорость, кстати, радует - при том, что только одно ядро нагружается меньше чем на половину, вся полоса, доступная удалённому клиенту (40мбс @ 4G) добросовестно выбирается полностью 👌🏻 -
Макось требует какой-то Remote ID:
без этого не создаёт соединение 🤔
Чем её накормить здесь можно?
-
On 7/24/2019 at 5:27 PM, Leks said:
3) Создаем правила:
~ # ebtables -A INPUT -i EoIP0 -p ipv4 --ip-proto udp --ip-sport 67:68 -j DROP
~ # ebtables -A INPUT -i EoIP0 -p ipv4 --ip-proto udp --ip-sport 67:68 -j DROP
здесь опечатки нет?
строки одинаковы, а для FORWARD одна — с ключём --ip-dport 🤔
не должно быть так?
~ # ebtables -A INPUT -i EoIP0 -p ipv4 --ip-proto udp --ip-dport 67:68 -j DROP
-
@Le ecureuil однако, помогло. Правда, не понял, что именно.
1. установил тот же psk на l2tp/ipsec (ключ автоматом проставился на ipsec vi) - не помогло
2. выключил оба vpn сервера - не помогло
3. удалил l2tp/ipsec сервер, роутер автоматом перезагрузился - помогло
не уверен, что это правильный ответ, ибо наводит на мысль, что crypto map существует только в единственном экземпляре и используется вообще для всего, что обращается к ipsec.
В планах поднять второй eoip бридж, и очень уж не хочется расшаривать тот же psk 😒
зы: свежий st в аттаче
-
1
-
-
Привет.
Не могу забодать вроде бы простой сетап.
EoIP между Ultra и 4G. У первого белый адрес, у второго - серый.
Делаю настройку EoIP с IPsec по мануалу https://help.keenetic.com/hc/ru/articles/115002715029-Настройка-туннелей-IPIP-GRE-и-EoIP
Туннель не поднимается с сообщениями на сервере:
15[IKE] linked key for crypto map 'EoIP0' is not found, still searching 15[IKE] tried 2 shared keys for 'EoIP0' - 'EoIP0', but MAC mismatched IpSec::Configurator: unable to authenticate remote peer for crypto map "EoIP0". IpSec::Configurator: (possibly because of wrong local/remote ID).
на клиенте:
06[IKE] received AUTHENTICATION_FAILED notify error IpSec::Configurator: remote peer rejects to authenticate our crypto map "EoIP0". IpSec::Configurator: (possibly because of wrong local/remote ID).
eoip id, и psk, естественно, одинаковые
Из самостоятельной правки - ip mtu на сервере приведено в соответствие с клиентом.
-
да, разобрался
я пытался сначала сконфигурить L3 туннель, а потом в него засунуть EoIP, но потом смекнул, что можно проще, просто добавив инструкции ipsec к EoIP интерфейсу -
нэвэрмайнд, разобрался
при включении EoIP0 в существующий бридж, ему собственный IP-адрес уже и не нужен. -
up
на чём душа успокоилась? Решаю такую же задачу.
При поднятии интерфейса получаю:
Network::Interface::Ip error[72220686]: "EoIP0": network 192.168.97.0/24 conflicts with interface "Home".
-
On 8/29/2019 at 5:19 PM, karimovrt said:
Не соглашусь) 3 недели полёт превосходный. eoip+ipsec. После решения первоначальных неполадок с mtu и прочим, всё работает прекрасно)
а сетапом не поделитесь?
-
On 6/2/2020 at 7:38 PM, Кинетиковод said:
Сбрасывать не надо. Надо просто бриджануть ещё раз и перезагрузиться для проверки.
Или наоборот — выставить правильную последовательность, обновиться, проверить последовательность.
-
3 hours ago, mpi said:
interface Bridge0 include OpenVPN0 в версии 3.4.3 расположен выше, чем определение блока interface OpenVPN0. Из-за этого он скорее всего после перезагрузки и не применяется, и потом исчезает после любых изменений, т.к. отсутствует в running-config
в самом деле, команда include выполняется до того, как инициализируется интерфейс OpenVPN0, поэтому она из running-config в итоге выбрасывается
это также объясняет, почему после ручного приджевания, как показано здесь, копирование running-config в startup-config не приводит к желаемому результату при следующей перезагрузке.
И, так как предположение оказалось абсолютно верным, вот этот воркараунд сработал отлично:
3 hours ago, mpi said:Как временное решение можно вручную отредактировать и залить файл startup-config с правильным порядком инициализации интерфейсов - блок interface Bridge0 должен быть ниже блока interface OpenVPN0. И после этого ничего в настройках не менять, т.к. тогда эту операцию нужно будет делать снова.
3 hours ago, mpi said:Так же судя по этому репорту, баг присутствует и в версии 3.5, и не только с OpenVPN
Это, конечно, печально. Выходит, проблема будет наблюдаться на любом интерфейсе, создаваемом пользователем из веб-морды, так как бридж в любом случае создаётся раньше.
Покуда 3.5 не вышла в паблик, может быть, можно зарепортить дефект, чтобы успели поправить?
-
1
-
-
On 3/14/2020 at 10:24 PM, Oleg Nekrylov said:
Делал, но при подключении клиента (Windows, Linux, второй keenetic), клиенты не получают адрес. По идее адрес должен прилетать от dhcp-сервера с Bridge0, но почему-то этого не происходит
У вас DHCP в каждом сегменте свой или один на всю сеть?
У себя адресное пространство поделил на диапазоны и в каждом сегменте использую свой диапазон, как раз на такие случаи. На сервере, при этом, DHCP трафик по tap-интерфейсам режется. Правда, это гарантированно работает только если юзера все "свои", и никто вручную установленными адресами не балуется.
-
Присоединяюсь к потерпевшим.
Omni и 4G: оба коннектятся к одному и тому же Асусу с мерлиновской прошивкой. Клиентские конфиги полностью идентичны, с разницей только в сертификатах.
На Omni на 3.4.1 всё работало хорошо: OpenVPN0 при поднятии автоматом включался в Bridge0. На 4G с той же прошивкой даже этого не происходило, проблема была с самого начала.
Сейчас на Omni бридж также начал разваливаться при каждом переподключении. Вручную бридж успешно собирается на обоих роутерах, но вручную не набегаешься...
С апгрейдом обоих на 3.4.3 ситуация не поменялась
Можно было бы заворкараундить каким-нть interface-up скриптом, как у Мерлина, но таковых в кинетиках не нахожу 😒
Не восстанавливается EoIP/IPSec бридж после сброса WAN подключения на клиенте
in Обсуждение IPsec, OpenVPN и других туннелей
Posted
Между двумя устройствами прокинут EoIP бридж.
Сервер (KN-1810) подключен по кабелю с белым адресом.
Клиент (KN-2310) имеет основное (Yota) и резервное (другая WiFi точка доступа) подключения.
После первой установки соединения при включении мост на клиенте поднимается успешно. Если происходит сброс WAN (перезагрузка модема или переключение на резервное), мост не восстанавливается.
После перезагрузки клиента бридж поднимается штатно.
Момент переподключения клиента в логах: