« Rev
@mikrotikclub   2069
Fwd »


Anonymous
а в чём причина зависания уже понятно ?
как раз кусок скрипта снизу - workaround, но не нравится поиск в цикле. может кто-то подскажет как сделать три условия в find? тогда можно было бы отказаться от поиска в цикле
УДАВ
Спасайте, как петлю предотвратить на микроте
долго бить по рукам линейкой тому, кто втыкает сетевые кабели без спроса. если это ты сам - промаркировать кабели сделать карту подключений. не делать петель.
УДАВ
/rules
Андрей
Коллеги, есть способ посмотреть, какие процеесы потребляют РАМ?
Andrey
Ребят, подскажите пожалуйста, у меня есть ключ посл MUM Захожу на страничку Convert prepaid key to licence key и ввожу softwareID новенького CHR и иду лесом, что я пропустил? You have entered wrong format for Software ID. Please check your router or consult with our support!
Andrey
Andrey
ок, похоже надо сначала триал получить..
Кирилл
Могу ошибаться, но думаю не зря в ЛК CHR licences выделены отдельно от Routers key - вывод: он не подойдет.
Evg_Evg
Подскажите если настроить IGMP Proxy для айпитв от ртк, на этом порту будет работать и интернет и тв? А домашний телефон будет?
Станислав
igmp по идее просто позволяет к мультикстной группе подключиться и на юникастные айпы не влияет
Sasha
По идее нет. Т.к. рт вещает свой иптв в другом vlan и есть ли там инет нужно проверять
Anton
Под внешней антенной Вы подразумеваете ACGPSA, mANT, SXT или что то другое?
Anton
Можно подключить в mini-PCIe слот плату (например R11e-LTE) и c этой платы вывести провода наружу подключив к антенне
Maxim
Всем привет. Коллеги, есть маленький вопрос. Есть web сервер, сидит за NATом. Нужно разрешить ему отвечать на запросы из внешки по проброшенным портам, но запретить самому ходить в интернеты. Как бы это аккуратно сделать быстро придумать не могу. Подскажите пожалуйста.
Artem
добавил одно правило в форвард, с src ip:80 accept. Вроде заработало.
как вариант еще поставить чек бокс connection nat state - dstnat
Artem
всё что dst-nat уже не new получается?
Владимир кажется сказал что соединение "В" интернет - тобишь я понял что подразумевается также указание направления трафика
Олимп
/rules
Volodymyr
всё что dst-nat уже не new получается?
Вы с сервера дстнат не делаете. Причем тут это?
Artem
по типу src - ip сервера - dst - !LAN - connection state new
Maxim
Не надо "все". Надо "new"
переделал, заработало, спасибо. Теперь пытаюсь понять, что после того как прилетел пакет dst-nat то ответ на него уже не new и оно пролетает это правило
Dmitry
уже ответили, но на фото видны выламываемые разъемы для вывода пигтейлов (SMA наверное)
Maxim
Да. Ответ уже не new
Вот это я и пытался осознать)
Evg_Evg
По идее нет. Т.к. рт вещает свой иптв в другом vlan и есть ли там инет нужно проверять
У меня один порт смотрит бриджом на прямую в порт где кабель ртк воткнут, с него работает иптв, остальные в бридж с пппое соединением, там инет работает. Если порт сделать с двумя вланами, один в один бридж смотрит другой в другой?
УДАВ
Я тут видел рекомендацию микротика в файрволе фильтровать только соединения со статусом new - слыхали о таком?
УДАВ
Так вот. Предположим юзер А обращается к серверу Б сквозь микротик. Первый пакет от юзера к серверу матчнется в правило со статусом new это понятно Вопрос в том почему в статус new матчится так же обратный пакет от сервера к юзеру? Это же уже известная микроту тсп-сессия. Да, пакет с флагами SYN и ACK ну и что
УДАВ
Почему я спрашиваю? Стоит задача пропускать ответы сервера, но задерживать попытки сервера самому открыть tcp сессию. А микротик убивает и то и другое если фильтровать форвард со статусом new на in_интерфейсе за которым живет сервер
УДАВ
ему без разницы пакет только с флагом SYN идет или с SYN ACK - и то и это микрот считает за new сессию )
УДАВ
Потому, что фильтровать надо на out, а не на in
у меня порядка трех сотен вланов с юзерами (условно) и один влан с серверами (условно). Мне предлагается сделать 300 фильтров на аут что бы не дать серверу поднимать сессии до юзерей?
УДАВ
Нет.
еще как да, я ж логирую то что дропается. и вижу как дропаются ОТВЕТЫ сервера. они почему то микроту в новинку хотя запрос прошел через него же
УДАВ
если нечего сказать по существу, воздержитесь от бесполезных советов. спасибо
УДАВ
я не слепой и прекрасно вижу что ответы сервера попадают в правило с условием new
УДАВ
ОТВЕТЫ. в new.
УДАВ
конечно всегда можно дорисовать но мне интересно это так задумано или просто микрот кривой и не запоминает сессию по первому SYN пакету
Volodymyr
я не слепой и прекрасно вижу что ответы сервера попадают в правило с условием new
Раз Вы так уверены, то Вам надо писать багрепотры микротику, создателям нетфильтра, айпитейблса и далее по списку. )
УДАВ
Раз Вы так уверены, то Вам надо писать багрепотры микротику, создателям нетфильтра, айпитейблса и далее по списку. )
я не уверен что это баг. возможно латыши так и задумывали, вот и спрашиваю может кто уже сталкивался
Volodymyr
я не уверен что это баг. возможно латыши так и задумывали, вот и спрашиваю может кто уже сталкивался
Вот я и отвечаю. Бага нет. Соединения с нью прекрасно ловятся и фильтруются. ищите ошибку в логике
УДАВ
Может микрот специально вносит сессию в список сессий только когда она прошла все три стадии "рукопожатия"
УДАВ
Вот я и отвечаю. Бага нет. Соединения с нью прекрасно ловятся и фильтруются. ищите ошибку в логике
они СЛИШКОМ прекрасно ловятся. проблема ж не в том что они не ловятся
УДАВ
а в том что микрот считает за new ответ сервера, хотя перед этим через тот же микрот прошел к этому серверу запрос. это по вашему нормальное поведение - оно так и задумывалось? (потому что на сиске это не так работает)
УДАВ
Roman
Может микрот специально вносит сессию в список сессий только когда она прошла все три стадии "рукопожатия"
https://github.com/torvalds/linux/blob/master/net/netfilter/nf_conntrack_proto_tcp.c Вряд ли Mikrotik что-то переопределял в connection tracking в ядре Linux.
УДАВ
Предлагаете спросить у линуксоидов? В принципе здравая мысль
Roman
Предлагаете спросить у линуксоидов? В принципе здравая мысль
case TCP_CONNTRACK_SYN_RECV: if (dir == IP_CT_DIR_REPLY && index == TCP_ACK_SET && ct->proto.tcp.last_flags & IP_CT_TCP_SIMULTANEOUS_OPEN) new_state = TCP_CONNTRACK_ESTABLISHED; break;
Volodymyr
Предлагаете спросить у линуксоидов? В принципе здравая мысль
Еще раз повторюсь - внимательно поищите ошибку. )
УДАВ
Еще раз повторюсь - внимательно поищите ошибку. )
ее там негде искать. в правиле только in интерфейс state new и block cуть в том что бы все что за этим интерфейсом не могло само иннициировать сессии. никуда.
УДАВ
Cм. выше. Должен быть OUT интерфейс.
мне надо фильтровать приходящие из конкретного влана, пакеты.
Volodymyr
мне надо фильтровать приходящие из конкретного влана, пакеты.
Вы себе противоречите. Если Вам надо фильтровать ответы сервера, то все с точностью до наоборот. А лучше, как я говорил выше, в условие поставить не интерфейс, а соурсадрес сервера
УДАВ
case TCP_CONNTRACK_SYN_RECV: if (dir == IP_CT_DIR_REPLY && index == TCP_ACK_SET && ct->proto.tcp.last_flags & IP_CT_TCP_SIMULTANEOUS_OPEN) new_state = TCP_CONNTRACK_ESTABLISHED; break;
судя по этому одного пакета с SYN микроту должно хватить что бы запомнить сессию
Volodymyr
мне надо фильтровать ЗАПРОСЫ сервера. но пропускать ответы сервера.
Именно это я и говорю. Перечитайте мое сообщение еще раз.
Roman
судя по этому одного пакета с SYN микроту должно хватить что бы запомнить сессию
Но State будет NEW, до момента получения SYN,ACK или SYN от обратной стороны, только после этого соединение перейдёт в состояние ESTABLISHED.
УДАВ
Именно это я и говорю. Перечитайте мое сообщение еще раз.
да, вы предлагаете фильтровать пакеты указывая только аут-интерфейсы. мне это не подходит
Volodymyr
да, вы предлагаете фильтровать пакеты указывая только аут-интерфейсы. мне это не подходит
Я предлагаю указать соурсадрес сервера, стейт нью и экшен=дроп. Все. Что ж не понятного-то? )))
УДАВ
Я предлагаю указать соурсадрес сервера, стейт нью и экшен=дроп. Все. Что ж не понятного-то? )))
ответ сервера тоже попадет под это правило и дропнется. а мне ответы сервера желательно как раз не дропать
УДАВ
Вы упертый. Я повторять устал. Не фантазируйте то ,чего нет. )
я могу собрать лабу и продемонстрировать это на видео. вы, к слову, тоже
УДАВ
ответ сервера - это же established
я тоже так думал. пока сам не споткнулся о то, что САМЫЙ ПЕРВЫЙ ответ сервера по факту new что бы он стал эстеблишед микрот должен пропустить пакет с ответом сервера хотя бы раз но микрот его дропает как new и круг замыкается сессия established не становится
УДАВ
а задачка то плевая, пропускать только ответы сервера на запросы )
УДАВ
ну может я загнался, реально соберу лабу на чистой пустой конфе
УДАВ
а может дело в не очень стандартной реализации протокола мускулем. посмотрим.
« Rev
@mikrotikclub   2069
Fwd »