Werld

https://help.keenetic.com/hc/ru/articles/360014436120-Возможно-ли-использовать-контроллер-Wi-Fi-системы-в-режиме-обычной-точки-доступа-

Посмотрите здесь. Там хоть речь не о sstp, но действия потребуются абсолютно такие же.

В кинетикОС у интерфейсов есть такая характеристика как security-level. Если у интерфейса security-level private, то на него разрешены входящие. Если seciruty-level public, то входящие запрещены. Из интерфейса с security-level private разрешен форвард в интерфейс с security-level public. Из public в private - нет. Между интерфейсами c security-level private форвард, по-умолчанию, тоже запрещен. От впн-клиентов l2tp, sstp и pptp серверов разрешен форвард в интерфейс, указанный в настройках в пункте "Доступ к сети", а также к любым интерфейсам с security-level public и признаком ip global (это галочка в настройках интерфейса "Использовать для выхода в интернет"). У любого создаваемого интерфейса по умолчанию seciruty-levle public. Так и у созданного вами wireguard интерфейса, если вы сами не меняли руками. Если у такого public wireguard интерфейса выставить в настройках галочку "Использовать для выхода в интернет" (признак ip global), то создавать разрешающие правила черел cli бы не пришлось. Подробнее можно почитать в базе знаний: https://help.keenetic.com/hc/ru/articles/360001434079

Обратите внимание на это сообщение. Только вам нужно будет привязывать acl к интерфейсу Wireguard, а не Bridge, но точно так же на OUT. Ну и сами правила в acl'e у вас должны быть разрешающие. Например permit ip 192.168.1.32/27 0.0.0.0/0

Можно

Потому что вы создаете правило для пакетов, у которых входящий интерфейс Bridge. У пакетов от vpn-клиентов входящий интерфейс ppp, а Bridge - исходящий. Через веб вам такое правило не создать, только в cli. Создаете acl и привязываете его к нужному bridge на out. Команды средующие: access-list vpn - создаем acl с именем "vpn" deny tcp 192.168.1.64/27 192.168.1.1/32 port range 80 443 - например, создаем правило запрещающее tcp с адресов 192.168.1.64/27 на адрес 192.168.1.1 на порты в диапазоне 80-443. Вам нужно правило для адресов, l2tp клиентов, которым нужно запретить доступ, также нужно указать нужные вам протоколы и порты. Можно создать несколько правил. exit - Выходим из подгруппы команд создания acl interface Bridge0 ip access-group vpn out - Привязываем acl с именем vpn на out к интерфейсу, к которому включен доступ в настройках l2tp сервера. По умолчанию это "Домашняя сеть", то есть Bridge0. system configuration save

Судя по предоставленным логам, падает pppoe, в первом логе даже падение линка есть. Каким боком здесь может помочь замена днс?

Попробуйте в cli: ip nat <сеть A> , должно помочь. А вообще, лучше чтобы Wg клиент натил свою сеть А при выходе в WG-туннель.

Так получается наоборот, это вы продолжаете жить 93 годом, если отрицаете изменения произошедшие с тех пор. В общем-то продолжайте оставаться при своем мнении, если вам rfc не указ. Можете и дальше удивляться, когда еще у кого-нибудь увидите такие ip-адреса, как у создателя темы.

Это вопрос не ко мне а к авторам этих калькуляторов. На вашем скрине видно, что они до сих пор пишут class c, при том, что как я уже говорил, бесклассовая адресация введена в 93 году. А насчет шашечки или ехать, я привел реальный пинг до реального адреса в реальном интернете, если по вашему это не подпадает под понятие "ехать", то я даже не знаю.

Спасибо за совет. Порекомендую вам того же, далеко, кстати говоря, ходить не надо. Вон у ТС на скринах таблицы маршрутизации как раз адреса с 0 на конце увидите. То, что этот адрес маршрутизируется наверное мне привиделось да? Обмен пакетами с 188.168.15.0 по с 32 байтами данных: Ответ от 188.168.15.0: число байт=32 время=18мс TTL=58 Ответ от 188.168.15.0: число байт=32 время=18мс TTL=58 Ответ от 188.168.15.0: число байт=32 время=18мс TTL=58 Ответ от 188.168.15.0: число байт=32 время=18мс TTL=58 Статистика Ping для 188.168.15.0: Пакетов: отправлено = 4, получено = 4, потеряно = 0

По поводу видео со вторым вашим вопросом, которое вы оставили в другой теме: А вы на кинетике icmp протокол в межсетевом экране на интерфейсе pppoe разрешить на вход не забыли?

Ответ на вапш вопрос гуглится за секунду: https://wiki.wireshark.org/SLL#linux-cooked-mode-capture-sll

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

Я все равно не понимаю ваш посыл. Я думаю все считают как? Нельзя ли увидеть цитату, где я заявил: я думаю, все считают так-то и так-то. Если вас смущает информация, что мол 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} Или настройте через веб-интерфейс: