Le ecureuil
-
Постов
10 813 -
Зарегистрирован
-
Посещение
-
Победитель дней
632
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
Хуки всегда выполняются асинхронно, и именно на них стоит ориентироваться, чтобы не было race condition. Так работает и вся система. Разумеется они всегда будут отставать от того, что показывает вывод команды, потому что она меняется синхронно. Все события ставятся в упорядоченную очередь, и исполняются одно за одним. -
Если не готовы продолжать на 4.3, тогда просто обождите пока она не станет стабильной. Полный дебаг никогда без явной просьбы включать не надо, не понимаю зачем все в него лезут. Залог быстрого решения проблем - четкое следование инструкциям, если не готовы - значит только ждать.
-
Все так, потому что вашу ситуацию и ситуацию с трансляцией отличить внешне невозможно. При этом трансляция маков встречается в жизни чаще, потому логика и сделана, что в таких случаях подозревает ее.
-
Так это вы вопрос задайте своему провайдерскому роутеру на предмет реализации nat loopback.
-
Может быть ну куча причин. Сперва стоит проверить на версии 4.3 и приложить self-test в момент проблем.
-
Если у вас хост в локальной сети, на который проброшен порт из WG тоже находится в системной политике, то все должно работать само - проброс порта на соединение в резерве работает уже больше пяти лет.
-
Если при ручном добавлении сервера вы укажете домен, то все запросы на него будут идти именно по этому правилу. Как раз так специально и сделано.
-
Это, скорее, особенность работы измерителя кабеля. 1 Гигабит не может чисто теоретически даже подняться, если нет всех 4 пар в активной работе. А значит, что если гигабит на порту явно показывается, то с кабелем все хорошо.
-
Так у нас с вами ничего не выйдет, на версии 4.2 проверять уже нет смысла, равно как и без debug.
-
Не обращайте внимания, оно потом перезапросит. Изменением MTU это не решается, просто повезло и стало запрашивать чуть позже, но решение не тут.
-
Такая ситуация может сложиться, и это не совсем баг. Кинетик ее распознал как то, что у устройства настоящий mac указан в статике, но в реальности он сидит за mac-транслятором. С внешней точки зрения эти ситуации видимо неразличимы.
-
У вас стандартный iOS клиент на 18.3?
-
Снимите self-test на 4.3, перед этим включив > crypto ipsec debug в командной строке.
-
Версии W11 и на Keenetic какие?
-
Вероятно у вас в сети есть еще один DHCP сервер, потому так и выходит. Это всегда очень плохая конфигурация, нужно разобраться чтобы такого не было.
-
Чей mac e0:51:d8:18:26:ea? Похоже на то, что у вас Proxmox находится за Mac address translator, часто это точки доступа и рипитеры.
-
Сделать этот WG основным на 1810.
-
То есть сигнала нет, по в интерфейсах везде показывает 1 гигабит?
-
Подключение к VPN SSTP Keenetic из OC Ubuntu
Le ecureuil ответил iContemplator вопрос в Обмен опытом
Подключаетесь по какому адресу? -
Вы пришли в тему про Multiwan и политики доступа, так чего ж удивляетесь вопросам по сути?
-
Пока нет.
-
@Владислав В. не нужно ничего упрощать, ставить 4.2 или делать другие непрошенные вещи. Нужно простое - на версии 4.3 включить oc-server debug и показать что происходит при подключении в виде селф-теста.
-
На старый Air поставьте delta 4.1.
-
Отключите ppe hardware, вероятно станет лучше.
-
Да, еще с версии 2.12 это можно. Смотрите в мануале про политики доступа, привяжите политику к гостевому сегменту и будет как хотите.
