Werld
-
Posts
436 -
Joined
-
Last visited
-
Days Won
6
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Werld
-
-
SNAT
in Обмен опытом
3 минуты назад, gaaronk сказал:Печально что тема 2017 года, а изменений нет =(
Согласен. Особенно учитывая, что под капотом то по сути нетфильтр, где все это элементарно выполняется. Ну, допустим, есть проблема с интерпретацией команды ip static, слишком она сложная и универсальная, ну так сделали бы две отдельные ip snat и ip dnat.
-
SNAT
in Обмен опытом
6 минут назад, r13 сказал:Возможно поэтому:
Ничего себе какие дела. Очень плохо, что такие замечания к работе не записаны в cli manual'e. Полагаю, в данном конкретном случае, должна сработать как нужно только ip static Wireguard0 PPPoE0
-
SNAT
in Обмен опытом
Тут пришло в голову. Раз у вас интерфейс wireguard, так сделайте ip static Wireguard0 PPPoE0
-
SNAT
in Обмен опытом
15 минут назад, gaaronk сказал:О какой сети/интерфейсе идет речь?
Общий вид команды ip static ‹protocol› ( ‹interface› | ( ‹address› ‹mask›) ) ( ‹port› through ‹end-port› (‹to-address› | ‹to-host›) | [port] (‹to-address› | ‹to-host›) [to-port] | ‹to-address› | ‹to-host› | ‹to-interface›) Соответственно речь о 192.168.0.0/16, когда в описании упоминается interface или network. И речь о PPPoE, когда в описании сказано to-address | to-interface
15 минут назад, gaaronk сказал:Вот это "network соответствует интерфейсу c уровнем безопасности public" крайне расплывчато. Назначена на интерфейсе? Маршрутизируется в интерфейс?
Ну не знаю. На мой взгляд, все же проблема именно в том, что роутер считает 192.168.0.0/16 соответствующей public. Поэтому и создаются два правила. Попробуйте в официальную поддержку обратиться, возможно они смогут подсказать решения для такой ситуации.
-
SNAT
in Обмен опытом
Интересно. Видимо сеть 192.168.0.0/16 у вас соответствует public интерфейсу, поэтому роутер и создает правило dnat заодно с snat. Т.к. судя по справочнику "Если interface или network соответствует интерфейсу c уровнем безопасности public, то будет выполняться трансляция адреса назначения (DNAT). Если to-address соответствует интерфейсу c уровнем безопасности public, то будет выполняться трансляция адреса источника (SNAT)." У вас, видимо, получается выполняются оба условия вот и создаются сразу два правила. Как выход, что если попробовать интерфейсу, за которым у вас сеть 192.168.0.0/16 (я так понимаю, это впн интерфейс), присвоить security-level private?
-
9 часов назад, Alex M. Jake сказал:
А L2TP/IPSec клиент на Air KN-1611 аппаратно ускоряется? Объединил 3 сети по инструкции, используя L2TP/IPSec в качестве транспорта, "сервер" Giga KN-1010, "клиенты" Air. "ppe" и "crypto engine" нигде не отключал. Тариф везде 100 Мбит/с, Speedtest приблизительно так и показывает. Однако iperf3 с хоста из сети "клиента" до хоста в сети "сервера" показывает приблизительно 30 Мбит/с, при этом вёбморда Air не открывается и интернет не работает, вообще. Налицо 100% загрузка процессора на Air и отсутствие аппаратной акселерации, хотя статья "Типы VPN-соединений в Keenetic" утверждает обратное.
Переходить на WireGuard?
На Air стоит MT7628, там ускоряется только AES. Ну и, соответственно, 30 Мбит/с - это нормально для этого устройства. По отзывам на форуме, WG на MT7628 должен быть побыстрее, так что да, имеет смысл попробовать на нем.
-
А какое устройство клиент? Если это кинетик, маршрут будет выглядеть так, шлюз можно не указывать:
-
2
-
-
Для начала, убедиться, что на устройстве впн-клиенте (за которым сеть 192.168.2.0/24) есть маршрут до 172.16.2.0/24 (или какой там диапазон у вас для впн клиентов) через впн интерфейс.
-
1 час назад, SecretSanta сказал:
Невозможность изоляции внутри L2-сегмента без peer-isolation - это архитектурная фишка самого стека или особенность реализации в Keenetic'ах?
Можно сказать, это особенность аппаратной реализации любого маршрутизатора, не только на Кинетиках. Все описанное далее мое ИМХО, так сказать, как я это вижу) Вот возьмем маршрутизатор, у него есть ЦП и есть чип коммутатора. Отдельный чип коммутатора нужен чтобы локальный трафик проводных клиентов не грузил ЦП. Т.е. локальный трафик проводных клиентов нагружает только аппаратный чип свича, соответственно любая фильтрация этого трафика может осуществляться только силами этого чипа, если он такое умеет. По типу, как в некоторых железных управляемых коммутаторах есть опции навроде Traffic segmentation для l2 трафика. Аналогично с wireless чипом. Трафик беспроводных клиентов обрабатывается этим wifi чипом. В отличие от чипа свича, используемый в Кинетике wifi чип имеет функцию изоляции клиентов, что и выведено в настройку peer-isolation. А вот трафик между сетями (например между локальной и глобальной) задействует уже обработку процессором, а значит может быть обработан пакетным фильтром в ядре ОС роутера.
-
1 час назад, SecretSanta сказал:
Мне не нужно запрещать ТОЛЬКО доступ к интерфейсу, а нужно изолировать всех клиентов друг от друга и от роутера (кроме от 192.168.1.2 к web-интерфейсу). Именно поэтому я пишу это правило в Out. Использовать peer-isolation я не могу, потому что эта опция приоритетнее любого разрешающего правила файерволла (как подсказали выше). Скорее всего, мне понадобится позже между отдельными хостами в локалке разрешить траффик на отдельных портах.
Изолировать друг от друга хосты одного l2-сегмента хоть проводные хоть беспроводные (без peer-isolation) не получится никак, не зависимо от того делаете вы правила на in, out или даже nearby)).
Доступ к самому роутеру при этом запретить можно, в том числе выборочно. Использовать для этого правила на out для интерфейса home концептуально не принято. Но если только так вам удалось добиться желаемой фильтрации доступа к роутеру, то и ладно)1 час назад, SecretSanta сказал:Суть моего предыдущего комментария была в том, что написанное в доках и в комменте KorDen (второй абзац) не соответствует дейсвительности (или я неправильно интерпретирую, что имеется в виду) - если разрешить входящий траффик (первое правило In), то исходящий в рамках установленного соединения должен идти нормально и не подпадать уже под правила файерволла (под правило Out), но это не так. Об этом говорит то, что я не могу зайти в интерфейс и что происходит мгновенный разрыв telnet-соединения после привязки правила из Out к интерфейсу (хотя это установленная tcp-сессия).
Вы интерпретируете неправильно. "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" означает, что если имеет место некий, каким каким-то образом разрешенный, исходящий траффик, то в рамках установленного соединения не требуется отдельно разрешать входящий трафик этого соединения. А вот в цепочке OUTPUT нет правила всегда разрешающего уже установленные соединения.
Поэтому когда вы вдруг создаете запрещающее правило на out, то оно запрещает)). Т.е. происходит следующее, хост отправляет трафик на роутер, роутер его принимает, обрабатывает формирует ответ и отправляет назад, только вот из-за появившегося запрещающего правила ответ не доходит. Поэтому я и написал, что концептуально неверно для данного случая запрещающие правила вешать на out. Запрещать надо in, чтобы роутер зря не принимал и не обрабатывал запросы к себе, ответ на которые все равно не дойдет. -
В 31.12.2020 в 19:51, SecretSanta сказал:
Что если на 192.168.1.2 поднят web-сервер, и я делаю запрос к нему с 192.168.1.3? По логике в моей бошке это должно подподать под In и Out (так как пакеты идут до роутера, а потом от него). Например, я пытался заблочить в качестве эксперимента такой путь только в In правилах, и это не сработало. Значит ли это, что в таких случаях (когда пакеты идут через роутер, а не инициированы им или он является пунктом назначение - как в п. 1 и п. 2) мы выбираем направление (In или Out) по конечному узлу (то бишь это будет Out, так как последнее направление - от роутера к 192.168.1.2)? Или мы пишем правила и в In, и в Out?
Во-первых, соединение между проводными хостами одного l2-сегмента, как уже написано выше, не заблочить правилами фаерволла на роутере. Поэтому у вас не получилось в качестве эксперимента "заблочить в качестве эксперимента такой путь только в In правилах". Во-вторых, если пакеты все же идут через роутер транзитом не в пределах одной l2, а между сетями (например, когда у вас два сегмента 192.168.1.0/24 и 192.168.2.0/24, или между локальной и глобальной сетью), то запрещающее правило в фаерволле роутера достаточно на in (если запретить инициацию соединения, то никакого ответа и не последует).
-
16 часов назад, SecretSanta сказал:
Хорошо, допустим, я хочу изолировать всех от всех в локалке (хосты друг от друга, хосты от роутера, роутер от хостов... ну вы поняли) за одним исключением - один хост с ip 192.168.1.2 должен иметь доступ к web-морде на роутере с ip 192.168.1.1. Пишу следующие правила:
1. In:
permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80
deny ip 192.168.1.0/24 192.168.1.1/322. Out:
deny ip 192.168.1.0/24 192.168.1.0/24
И я не могу зайти в web-интерфейс с 192.168.1.2. Более того, как только я привязываю второе правило (acl) к интерфейсу, тут же теряется telnet-соединение. То есть либо я что-то делаю неправильно (чего я не исключаю), либо никакого правила вида "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" нет, либо это правило перезаписывается правилом из списка out.
Для запрета доступа к админке роутера всем, кроме 192.168.1.2 достаточно двух правил на in для интерфейса home.
permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80
deny tcp 192.168.1.0/24 192.168.1.1/32 port eq 80
На out никаких правил при этом не нужно. Правилом deny ip 192.168.1.0/24 192.168.1.1/32 вы зарежете не только вообще весь доступ к роутеру, включая телнет и проч, но еще и форвард для устройств заодно. Такое правило использовать не надо.Далее, запретить проводным устройствам общаться между собой правилами фаерволла не получится, т.к.между проводными устройствами ходят кадры через l2-свитч. Запретить беспроводным клиентам общение между собой и проводным сегментом при этом возможно, с помощью peer-isolation.
-
В 29.12.2020 в 21:19, SecretSanta сказал:
Отсюда первый вопрос: protected security level помимо запрета на уровне файерволла еще и добавляет запрет на уровне веб-сервера
Видимо так и есть. Как один из вариантов решения :возвращать на сегмент security-level private, А затем уже в правилах фаерволла для этого сегмента указать разрешающее Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80. И следом запрещающее Source IP - 192.168.1.0/24, Destination IP - 192.168.1.1, Destination port - 80. Если кроме веб-морды надо запрещать доступ к другим службам роутера, также создавать правила запрета на порт 23 (telnet), 22 (ssh) и т.д.
В 29.12.2020 в 21:19, SecretSanta сказал:При включенной изоляции, допустим, я хочу разрешить взаимодействие между двумя IP-адресами. Для проверки добавил правила, разрешающие пинговать друг дружку, но не работает. Отсюда второй вопрос: peer-isolation или правила файерволла приоритетнее?
Из описания опции peer-isolation "Блокирует передачу трафика от беспроводных клиентов внутри L2-сети." Фаерволл работает на L3, поэтому и не отрабатывают эти правила. Можно сказать, что peer-isolation приорететнее.
В 29.12.2020 в 21:19, SecretSanta сказал:P.S. Правила делал через WEB-интерфейс, не CLI. Есть ли разница?
Через веб-конфигуратор создаются правила только к входящему трафику интерфейсов.
Через CLI можно создавать правила и навешивать их на любое направление. -
50 минут назад, Лиза Шустрая сказал:
Значит надо делать роутер основным устройством. А что то нужно будет настраивать для безопасности локальной сети, сетевого хранилища ? Чтобы доступа извне интернета не было, просто в плане безопасности даже не представляю что можно, а что нельзя делать. Это будет мой первый домашний сервер=) Там нужно настроить медиа сервер, торрент, удаленный доступ к файлам но только для локалки, и с такой топологией вроде можно было не беспокоится о безопасности.
Используя роутер как пограничное устройство, т.е. интернет-шлюз, вы не беспокоитесь о безопасности, о ней за вас беспокоится производитель роутера.)) У Кинетика с этим все в порядке, Можете смело ставить speedster основным устройством, из коробки там все достаточно хорошо закрыто от доступа в локалку извне. В этом вы, кстати, убедились, когда вам пришлось настривать разрешающее правило в межсетевом экране, чтобы дать доступ ПК-1 в локалку за роутером.
-
Если на ПК-1 винда, то это имхо в целом так себе затея использовать ее как шлюз, как раз из-за всяких возможных глюков подобных. Если хочется стабильности, рекомендую подумать о смене топологии, чтобы шлюзом был роутер, если есть такая возможность. Конкретных шагов по решению таких проблем windows в качестве сетевого шлюза, я, увы, подсказать не могу, т.к. всегда избегал использовать ее в такой роли.
-
1
-
1
-
-
36 минут назад, Лиза Шустрая сказал:
И вот если не сложно в межсетевом экране правильная настройка?
Да, только протокол выберите IP, а не TCP, тогда пинг тоже заработает.
-
1
-
-
3 часа назад, Лиза Шустрая сказал:
Возможно ли это как то собрать и настроить так, чтобы ПК-1 мог видеть по сети Server и устройства из wi-fi сети ?
На ПК-1 нужен маршрут до сети 192.168.1.0/24 через шлюз 192.168.159.2 Далее в веб-морде роутера, в межсетевом экране для интерфейса isp разрешить протокол ip с адреса источника 192.168.159.1/32 . Этого должно быть достаточно.
-
1
-
-
5 часов назад, Mamay сказал:
4 последних сообщения говорят об обратном...
InternetChecker и ping check - это разные вещи.
-
1
-
-
6 часов назад, SEngel сказал:
Попробовал - не работает.
VPN клиент подсоединяется с IP адресом 172.16.1.2 в отдельно созданный сегмент VPNSeg по L2TP/IPSec. Сегменту установлен security-level private. Подсеть сегмента 192.168.2.0.
В подсеть VPNSeg по проводу подключен ноут с IP адресом 192.168.2.6. В Web интерфейсе VPN сервера установлено, что VPN клиенты заходят в данный сегмент. Пинг на 192.168.2.6 ни в какую не проходит.
При этом, если в настройках сервера установить, что VPN клиенты попадают в домашнюю сеть, то в домашней сети все пинги проходят.
Опишите, какие шаги вы пробовали. Как вы можете видеть из приведенной темы, можно даже поставить впн-клиентам доступ в домашнюю сеть и дополнительно к этому организовать доступ в дополнительно созданный сегмент. При правильной настройке все должно работать.
-
20 часов назад, SEngel сказал:
Нужны ли какие доп настройки чтобы VPN устройства видели хосты в сегменте и пинг проходил?
-
11 час назад, Varo сказал:
Как итог: pptp клиенты потеряли возможность выходить в интернет через ddwrt
Видимо на ddwrt включен нат только для адресов 192.168.0.0/24 Поэтому в приведенной вами документации рекомендовано впн-клиентам назначать адреса оттуда же.
В принципе, раз адреса впн-клиентов не пересекаются с пулом dhcp сервера, то можно оставить как было у вас в первом посте. Проблема все равно не в этом, у вас нет нужных маршрутов, по крайней мере на кинетике. На кинетике у вас должен быть маршрут вида.
На впн-сервере должен быть маршрут в сеть клиента, т.е. маршрут до сети 192.168.1.0/24 через шлюз 192.168.0.ххх - адрес, получаемый кинетиком от впн-сервера ( например 192.168.0.103)
При наличии двух этих маршрутов (один на сервер и один на клиенте) все должно работать.
-
36 минут назад, alkho сказал:
С предыдущем вопросом пока не разобраться, хочу бросить настройки VPN серверов (L2TP/IPSec и IPsec), есть ли такая команда в cli? Сбрасывать все настройки роутера не хочется, много настроено. Переустановка компонентов настройки не сбрасывает.
В конфиге руками удалить...
-
4 часа назад, Fatih сказал:
There are many differences between the Internet and your country in turkey
for example the internet in turkey litter..
Consider us too, keep the dB adjustment accordinglyThis thread discusses adjusting the wireless driver to prevent wireless clients from dropping to 40 MHz bandwidth. If you are experiencing problems with the noise margin of the dsl connection in new firmware versions, you need to contact the support service.
-
14 часа назад, AlexUnder2010 сказал:
Имеется следующий зоопарк:
1. Микротик 951, который "главный", который идёт на вход из мира и не имеет Wifi. У него своя сеть (192.168.88.1) и он раздает по шнуркам\коммутаторам интернет проводным устройствам.
2. Keenetic Ultra II в режиме роутера, который подключен по WAN к Микротику из пункта 1.
3. Два KN-1010, которые подключены в режиме репитера\ретранслятора к Ultra II по LAN (из пункта 2) и втроем они составляют меш-систему с одним ссидом в своей сети (192.168.3.1).
Можно ли объединить их в одну сеть (микротика), и сохранить меш, чтобы не возникало коллизий? Если да, то как? Пробовал DHCP Relay, но сломал иерархию сети, что пришлось всё настраивать с нуля (бэкап конфига был).
-
1
-
2.07.C.1.0-2 (официальный релиз) - Вопросы
in Обмен опытом
Posted
https://forum.keenetic.net/announcement/5-где-взять-тестовые-прошивки/