Le ecureuil
-
Постов
10 800 -
Зарегистрирован
-
Посещение
-
Победитель дней
632
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
Какой security-level у Bridge1? Это влияет на NAT. Попробуйте сделать его public.
-
IKEv2 MSCHAP должен работать нормально с последними версиями Android с IKEv2 сервером. Какая версия Android у вас?
-
Этот интерфейс не относится к IKEv2-серверу. -
Нет, это не работает. И у нас не ntfs-3g.
-
У вас очень слабое устройство, потому нужно быть очень аккуратным при использовании Opkg.
-
Эта функция не относится к IKE-серверу. Вам же нужно обратиться в opkg, стандартными средствами это невозможно.
-
Покажите self-test.
-
Самое правильное - сделать для каждого из них свою политику доступа. И уже в ней привязать нужные WG-соединения.
-
Только на 4.3, на 4.2 не нужно.
-
Еще раз проверил - у вас соединение почему-то не доходит до конца и зависает на полпути. Можете пожалуйста еще раз переснять отладочную информацию, но только выключив все остальные IPsec и L2TP-клиенты и серверы?
-
Пока не встречалось MBIM-модема, который не умел бы в QMI или в AT. Модем в посте выше не факт что вообще умеет USB, нужно смотреть.
-
Каждый раз пробую - и никогда не воспроизводится. Судя по self-test у вас пропадает адрес на сегменте Home в ядре, но это почему-то остается незамеченным. Постараемся решить подобную ситуацию.
-
Слишком много конфигураций, которые невозможно придумать с разбега. Вот предположим есть такой стенд, у человека к нему подключается и работает, а к своему устройству - вообще нет. И что? Это, по сути, дает ровно ноль новой информации и не упрощает отладку.
-
Не вижу никакой разницы в нетфильтре, и не воспроизводится.
-
Не очень понимаю, чем это лучше любого из наших встроенных VPN-серверов.
-
Хуки всегда выполняются асинхронно, и именно на них стоит ориентироваться, чтобы не было race condition. Так работает и вся система. Разумеется они всегда будут отставать от того, что показывает вывод команды, потому что она меняется синхронно. Все события ставятся в упорядоченную очередь, и исполняются одно за одним.
-
Если не готовы продолжать на 4.3, тогда просто обождите пока она не станет стабильной. Полный дебаг никогда без явной просьбы включать не надо, не понимаю зачем все в него лезут. Залог быстрого решения проблем - четкое следование инструкциям, если не готовы - значит только ждать.
-
Все так, потому что вашу ситуацию и ситуацию с трансляцией отличить внешне невозможно. При этом трансляция маков встречается в жизни чаще, потому логика и сделана, что в таких случаях подозревает ее.
-
Так это вы вопрос задайте своему провайдерскому роутеру на предмет реализации nat loopback.
-
Может быть ну куча причин. Сперва стоит проверить на версии 4.3 и приложить self-test в момент проблем.
-
Если у вас хост в локальной сети, на который проброшен порт из WG тоже находится в системной политике, то все должно работать само - проброс порта на соединение в резерве работает уже больше пяти лет.
-
Если при ручном добавлении сервера вы укажете домен, то все запросы на него будут идти именно по этому правилу. Как раз так специально и сделано.
-
Это, скорее, особенность работы измерителя кабеля. 1 Гигабит не может чисто теоретически даже подняться, если нет всех 4 пар в активной работе. А значит, что если гигабит на порту явно показывается, то с кабелем все хорошо.
-
Так у нас с вами ничего не выйдет, на версии 4.2 проверять уже нет смысла, равно как и без debug.
