Werld

Я все равно не понимаю ваш посыл. Я думаю все считают как? Нельзя ли увидеть цитату, где я заявил: я думаю, все считают так-то и так-то. Если вас смущает информация, что мол 5 лет назад они обнаружили, что сайт майкрософт некорректно работает если обращаться к нему с ip оканчивающегося на 0, то нужно понимать что той теме более 9 лет. 9 лет + 5, о которых они говорят и получается, что более 14 лет назад кто-то имел проблемы с сайтом майкрософт. Вам самому не смешно? Согласно rfc, адреса с 0 на конце могут использоваться и должны нормально маршрутизироваться точка! Случаи когда это у кого-то где-то когда-то не работало лишь следствия некорректной настройки сетевого оборудования.

Я не понял ваш посыл. Вы пытаетесь доказать, что адрес с 0 на конце не должен быть использован? Даже по вашей же ссылке:

Скрин за который вы зацепились вообще не мой. Если внимательно прочитаете тему, то увидите, что это был ответ на первый пост.

А что вас удивляет? Бесклассовая адресация была принята аж в 93 году. IP адрес оканчивающийся на 0 абсолютно легален. https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing https://www.rfc-editor.org/rfc/rfc1519 https://stackoverflow.com/questions/14915188/ip-address-ending-with-zero The solution that the community created was to deprecate the Class A/B/C network address assignment system in favor of using "classless", hierarchical blocks of IP addresses (referred to as prefixes). https://www.rfc-editor.org/rfc/rfc4632

Если у вас построена именно wifi-система, то есть точка доступа "захвачена" в интерфейсе контроллера, то вывести на проводные порты точки доступа сегмент отличный от домашнего не получится. Неоднократно обсуждалось на форуме. Если вы хотите передавать на точку разные vlan и выводить их на проводные порты, то вам не нужно использовать wifi-систему. Настройка в таком случае будет инструкциям по ссылкам, которые вам привели.

Я если честно не думаю, что там именно урезанием скорости происходит ограничение. Я думаю,на брасе у провайдера навешивается политика и просто блокируется траффик определенного вида.

По моим наблюдениям, работает так как и описано в документации и changelog'e. В настроенном у себя профиле пинг-чека в режиме connect на кастомный порт на свой же удаленный ресурс, я сменил режим на tls. Пинг чек стал пытаться устанавливать поверх tcp соединения на этот порт еще и tls соединение. Прилетело tls client hello сообщение, но так как на том порту не было ничего что способно было ответить на tls handshake, то пинг-чек посчитал такую попытку неуспешной.

Вы в курсе что такое TLS и поверх какого протокола он работает? Пинг на порт использует не icmp, соответственно провайдер не примет это за "простой ping". Вы совершенно спокойно можете обойтись без entware. Возможно вам поможет даже уже существующий режим пинг-чека "Проверка TCP-порта". Если нет, попробуйте озвученный выше вариант с TLS, скорее всего с ним точно будет работать.

В KeeneticOS версии 3.9 появилось то что вам нужно: Новый режим TLS-проверка порта TCP улучшает работу механизма Проверка доступности интернета для обеспечения защиты от сбоев доступа в Интернет. Этот режим предотвратит ложноположительные результаты, если провайдер перенаправит трафик на авторизованный портал, например, на биллинговый сервис. [NDM-2094, NWI-1109] Используйте следующую команду CLI для установки: ping-check profile {name} mode tls — включить режим TLS для профиля Ping Check {name} Или настройте через веб-интерфейс:

Установка флажка "Добавлять автоматически" должна помочь

А ну и, кстати, Вы на обеих сторонах в разрешенных сетях оставьте только нужные подсети. Не надо на обеих сторонах указывать и 192.168.10.0/24 и 192.168.100.0/24. У вас на стороне клиента должны быть разрешенные сети: 172.16.82.2.32, 192.168.10.0/24 На стороне сервера разрешенные сети: 172.16.82.1.32, 192.168.100.0/24

Security-level интерфейсов wireguard ненароком руками не меняли? Какой он сейчас на обеих сторонах? Второй момент, смущает на вашем скрине какая реально сеть за клиентом, точно 192.168.100.0/24? так то и 192.168.10.0/24 и 192.168.100.0/24 оба входят в 192.168.0.0/16

Задаваемый в интерфейсе маршрут попадает в таблицу маршрутизации, если уж на то пошло. На стороне сервера нужен маршрут до сети за клиентом. На стороне клиента в межсетевом экране должны быть разрешены входящие на впн интерфейс. Когда пакет из сети за впн-клиентом уходит в туннель, происходит подмена адреса источника. Соответственно, устройствам в сети впн-сервера не нужно знать маршрут до сети за клиентом чтобы слать ответные пакеты.

Интерфейс выбран не правильно. Попробуйте тогда не указывать вообще интерфейс, если прошивка на xiaomi это позволяет.

Вы полмесяца ждете ответа, но не потрудились даже подробнее описать ситуацию. Из вашего сообщения вообще не ясно при чем здесь кинетик. Какие именно устройства выступают впн сервером и впн клиентом? Трассировки до адресов которые не доступны вы не представили. Ваш скрин с маршрутом явно не из веб интерфейса кинетика. Вообще маршрут на скрине не верный, там интерфейс указан LAN, а должен быть, видимо, vpn.

Доступ к вебдав: Доступ к обратному прокси: Вы об этом, или я не понял вопрос?

Я думаю, статью KB просто не обновили. ЕМНИП в какой-то из версий Keenetic ОС было сделано, чтобы доступы к конфигуратору, обратному прокси, вебдаву разрешался и запрещался раздельно для каждого

А вы пробовали? Возможно такое ограничениев режиме "через облако". У себя вот только что проверил, при отключении удаленки к веб-конфигуратору, доступ к вебдав сохраняется. Но у меня режим "прямой".

С чего вы взяли? Удаленный доступ к веб-конфигуратору и доступ к webdav'у это разные настройки

Закрыть удаленный доступ к веб конфигуратору.

Да вот так. ДНС указывать не обязательно, если не указан он автоматически раздает себя в качестве днс-сервера

В инструкции приведен пример для двух роутеров с некими сетями. Предполагается, что вы адаптируете этот пример под свой случай. У вас могут быть сети не обязательно как в инструкции. Главное чтобы они были разные на роутерах и настройки все нужно делать соответственно им.

В разделе Параметры IP на сервере у вас должно быть указано 192.168.22.1/24 и dhcp сервер должен выдавать адреса из этого диапазона. На клиенте соответственно 192.168.100.1/24. Обратите внимание доступ к роутерам из их сетей тоже изменится, они будут отвеать по указанным адресам

Мои сети и wifi --> домашняя сеть. На ваших устройствах должны быть разные сети. Если вы это не меняли, то не удивительно, что ничего не работает

А сети на роутерах вы верные прописали? Покажите настройки домашних сегментов на обоих роутерах