Werld

В cli кинетика выполнить: no ip nat Home - отключает snat для всех пакетов из сети Home. ip static Home ISP - включаем snat для пакетов из сети Home, уходящих в интерфейс ISP. Если соединение с провайдером организвано по протоколу pppoe, то еще понадобится правило ip static Home PPPoE0. Подробнее по всем командам в cli-manual.

Такое правило нужно было бы добавлять на in для интерфейса впн-клиента. Но, к сожалению, применять правила для интерфейсов впн-клиентов в текущей реализации keenetic os невозможно. Поэтому ограничить доступ именно к ресурсам самого роутера, для впн клиента средствами межсетевого экрана нельзя. Используйте отдельную учетку для впн-клиентов и не сообщайте им учетки для доступа к к шарам роутера и другим сервисам.

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, то пинг-чек посчитал такую попытку неуспешной.