вообще цепочки форвард нет.
Она есть всегда в iptables и в RouterOS default policy accept.
Roman
M.
Cumberbatch
Volodymyr
Какая именно часть моего высказывания?
"в RouterOS default policy accept." Она местами акцепт. )
Roman
"в RouterOS default policy accept." Она местами акцепт. )
Для filter table accept для всех трёх цепочек по умолчанию, для других таблиц согласен, могут быть нюансы. 😃
Cumberbatch
Volodymyr
Для filter table accept для всех трёх цепочек по умолчанию, для других таблиц согласен, могут быть нюансы. 😃
В айпитейблс - да. И это можно увидеть. В роутерос - пусто. Там нет явного accept.
Возможно из-за этого появились "костыли" в виде разрешений на инпуте для локального капсмена. Но это только предположение.
Roman
В айпитейблс - да. И это можно увидеть. В роутерос - пусто. Там нет явного accept.
Возможно из-за этого появились "костыли" в виде разрешений на инпуте для локального капсмена. Но это только предположение.
В ядре в любом случае будет либо NF_ACCEPT, либо NF_DROP, либо NF_STOLEN, etc.
Но спорить не буду, исходный код ядра RouterOS я не видел, может быть они что-то изменили.
Volodymyr
Геннадий
Таки у циски тоже черный ящик, но все знают что там дефаулт дроп в конце, даже если не написано.
Геннадий
У тика наоборот.
Volodymyr
Таки у циски тоже черный ящик, но все знают что там дефаулт дроп в конце, даже если не написано.
Мне такой подход больше импонирует.
Roman
Таки у циски тоже черный ящик, но все знают что там дефаулт дроп в конце, даже если не написано.
Не согласен, у Cisco столько документации по низкоуровневым вещам, что можно жить на всяких BRK, да иногда это всё в виде презентаций на Cisco Live! но главное результат.
Andrey
Кто-нибудь в курсе, микроты voip не собираются внедрять в свои решения?
Andrey
Навеяло сравнением циско - микрот
Roman
Кто-нибудь в курсе, микроты voip не собираются внедрять в свои решения?
Что вы под этим подразумеваете? Конкурента CUCME создать?
Cumberbatch
В айпитейблс - да. И это можно увидеть. В роутерос - пусто. Там нет явного accept.
Возможно из-за этого появились "костыли" в виде разрешений на инпуте для локального капсмена. Но это только предположение.
Локальный capsman что бы работал. Иначе дроп инпут!лан не даст.
Volodymyr
Локальный capsman что бы работал. Иначе дроп инпут!лан не даст.
В том и дело. ) Какой интерфейс мне добавить в список LAN, чтобы не нужно было бы IP писать? По идее тут сокет должен открываться. Раз интерфейса нет и по умолчанию accept, то... Некая неопределенность. )
Cumberbatch
В том и дело. ) Какой интерфейс мне добавить в список LAN, чтобы не нужно было бы IP писать? По идее тут сокет должен открываться. Раз интерфейса нет и по умолчанию accept, то... Некая неопределенность. )
Если бы не было дроп !лан то все бы работало и без явного разрешения.
Roman
В том и дело. ) Какой интерфейс мне добавить в список LAN, чтобы не нужно было бы IP писать? По идее тут сокет должен открываться. Раз интерфейса нет и по умолчанию accept, то... Некая неопределенность. )
Та же история с RADIUS локальным, accept для IP интерфейса с которого запрос и приходит.
Правда drop all в конце input цепочки есть явный.
Это какая-то особенность реализации именно в Mikrotik некоторых сервисов, причин не смог найти, может в каком-то MUM освещали.
Volodymyr
Если бы не было дроп !лан то все бы работало и без явного разрешения.
Да кто ж спорит. И тем не менее - если нет ЯВНОГО запрета (интерфейса же входящего нет), то почему не работает? Такое вот у производителя трактование. )
Cumberbatch
Да кто ж спорит. И тем не менее - если нет ЯВНОГО запрета (интерфейса же входящего нет), то почему не работает? Такое вот у производителя трактование. )
То что адрес 127.0.0.1 висит на каком то скрытом интерфейсе я просто уверен. Зачем так? Вопрос открытый. :)
Volodymyr
То что адрес 127.0.0.1 висит на каком то скрытом интерфейсе я просто уверен. Зачем так? Вопрос открытый. :)
Потому и "черный ящик" (
Геннадий
Потому и "черный ящик" (
потому что линукс, и многие вендоры пингуют этот адрес, даже если он не назначен явно
Геннадий
RFC 5735
Геннадий
ping 127.0.0.1
Обмен пакетами с 127.0.0.1 по с 32 байтами данных:
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Геннадий
винда, хотя этого адреса нигде не стоит
Volodymyr
потому что линукс, и многие вендоры пингуют этот адрес, даже если он не назначен явно
Речь об интерфейсах. С адресом никто и не спорит.
Геннадий
ну вот например, есть вендор файберхоум, там есть не удаляемый лупбак-0 с этим адресом
Геннадий
циска не светит интерфейс и пингует
Геннадий
винда не светит интефейс и пингует
Геннадий
про микрот уже сказали... не светит и пингует, хотя лупбак на нем не реализован как таковой как отдельный вид интерфейсов
Oleg
ip вроде принадлежит хосту, а не интерфейсу. Согласно какому-то RFC, у хоста он должен быть, даже если нет интерфейсов (в дауне, например)
Roman
Дмитрий
да именно так он и написал
Геннадий
только надо понимать, что этот адрес в любом случае висит на интерфейсе. пусть даже виртуальном.
если у вас сетевой стек загнулся - то не будет работать 127.0.0.1
Геннадий
это минимальная стартовая диагностика. пингуя этот адрес вы убеждаетесь что ваш сетевой стек живой.
Roman
RFC 12122: “(g) { 127, <any> }
Internal host loopback address. Addresses of this form MUST NOT appear outside a host.”
И да, Геннадий прав, в TCP/IP адрес всегда принадлежит интерфейсу, а вот в OSI узлу целиком.
Геннадий
Геннадий
т.е. он лишь ОПИСЫВАЕТ, что происходит и где
Roman
OSI настолько призрачна и эфемерна...
Я про конкретную реализацию CLNS/CLNP протокола в рамках OSI стэка протоколов, да и IS-IS в частности.
Innokentiy
1. не путайте модель OSI и стек протоколов OSI
2. да, в CLNS адрес назначается на entity
3. да, в типичных сценариях entity - это весь хост, в отличие от IP, где каждый интерфейс обладает отдельным (и зачастую не одним) адресом
4. но в нетипичных конфигурациях все может быть и наоборот: в CLNS никто не мешает назначить адреса на entity - отдельные интерфейсы, и равно в IP повесить один общий адрес на весь хост
Innokentiy
более того, сегодня очень часто встречается как раз модель, при которой у каждого сетевого узла есть только один маршрутизируемый адрес, не зависящий от интерфейса
Cooler3D
Вопрос:
Есть ли разница при назначении адреса локальной сети Микротика, BRIDGE я выберу в качестве интерфейса, либо же какой нибуль ETHERNET из тех интерфейсов что состоит в BRIDGE?
Cooler3D
Кстати, у RB4011+WIFI десяток ETH портов, при этом первые 5 обслуживаются 1 свитч-процессором, остальные 5 другим. Имеет ли смысл при объединении всех портов в BRIDGE - создать два отдельных BRIDGE, по 1 на группу портов? Или это ничего не даст?
Владимир
А никто не ваерШарчил? Если адрес назначен интерфейсу, а не бриджу... На бродкаст ответит мак бриджа или интерфейса?
Cumberbatch
Cooler3D
А никто не ваерШарчил? Если адрес назначен интерфейсу, а не бриджу... На бродкаст ответит мак бриджа или интерфейса?
В моем случае я изначально выбрал интерфейсом BRIDGE.
Cumberbatch
Ну вот это и интересно...
Ответит. И мак будет порта если на нем адрес или бриджа если на бридже
Cumberbatch
Владимир
Грац
Иван
народ у микротика 2 версии заводского фаерволла, я прав?
Михаил
народ у микротика 2 версии заводского фаерволла, я прав?
И сразу вдогонку вопрос про правила фаервола "по умолчанию" - есть ли где-нить описание "на пальцах", какое дефолтное правило фаервола для чего предназначено?
Если известно про такое - скиньте пожалуйста ссылку.
Михаил
Я понимаю, что краткое описание правил содержится в комментариях к ним, и что каждый админ настраивает фаервол согласно стоящим перед ним задачам. Но создатели RouterOS тоже неглупые люди и, создавая дефолтный конфиг, руководствовались чем-то. Хотелось бы про это почитать.
Заранее спасибо.
Cumberbatch
Я понимаю, что краткое описание правил содержится в комментариях к ним, и что каждый админ настраивает фаервол согласно стоящим перед ним задачам. Но создатели RouterOS тоже неглупые люди и, создавая дефолтный конфиг, руководствовались чем-то. Хотелось бы про это почитать.
Заранее спасибо.
А что тут не понятно?
https://t.me/mikrotikclub/143660
Михаил
А что тут не понятно?
https://t.me/mikrotikclub/143660
Ок, тогда переформулирую вопрос: существует ли описание "Mikrotik: дефолтные правила фаервола для чайников"?
Cumberbatch
Ок, тогда переформулирую вопрос: существует ли описание "Mikrotik: дефолтные правила фаервола для чайников"?
Может кто-то и написал. Вы сами подумайте что они означают. Если не понятно то спрашивайте
Михаил
Может кто-то и написал. Вы сами подумайте что они означают. Если не понятно то спрашивайте
Спасибо, буду иметь в виду, обращусь в случае возникновения вопросов.
Но повторюсь - создатели RouterOS неглупые люди и, создавая дефолтный конфиг, чем-то руководствовались.
В частности, для Mikrotil RB750-r2 (hEX lite) в версии прошивки 6.38 в дефолтном фаерволе 7 правил, а в версии 6.48 - уже 12. Возможно, с этим связан вопрос Ивана, интересующегося про две версии заводского фаервола.
Михаил
Михаил
Ник
Всем привет. Никто с таким не сталкивался, случаем:
Mikrotik на RouterOS 6.48. В сеть спокойно выходят все подключённые устройства, друг друга видят тоже. Но при попытке синхронизации iOS устройств с macOS синхронизация начинается и при начале передачи данных прерывается. Так же не происходит резервное копирование macOS на сетевой диск, подключённый к Mikrotik по LAN. Копирование файлов на сетевой диск тоже не происходит. Может кто знает решение данной проблемы?
Экспериментально удалось выяснить, что небольшие пакеты данных пересылаются (можно создать папку на сетевом диске, например), а передача файлов не происходит.
На Keenetic таких проблем не наблюдается.
Заранее спасибо за помощь.
Sergio
Денис
Денис
Денис
Вопрос снят - заработало.
Ник
Не используй в продакшене стейбл, только лонг-терн
Дело в том, что на другом Mikrotik всё тоже самое, там версия прошивки пониже была, когда тестировал. С насройками по умолчанию не устанавливаются ли какие-нибудь правила для Огненой стены, которые припятствуют передаче данных между устройствами в локальной сети?