mrrc

Вы подключились к участию поназидать, я не пойму?) Или невнимательно читали все обсуждение выше) Контрпродуктивно.

Например? Работает, как выше приводилось. Это вы о чем?

Сейчас с точностью сценарий не вспомню, но удаленные маршрутизаторы в схеме не присутствовали, маршрутизация vlan-подсетей велась внутри самого маршрутизатора. Как раз по теме имела место быть базовая схема l2tp+ipsec тоннеля до удаленной стороны. Никакие обвязки в if_list-ы как выше упоминал не проканали, а тоннель как раз прокладывался через интернет-соединение через единый для всего wan-интерфейс.

@himikrzn да я ранее также придерживался аналогичной практики, а в данном конкретном случае вылезло то, что вылезло, поставив в тупик.

@himikrzn применительно к вопросу в теме if-листы с внешним ифейсом разумеется опробовались (как и прямое единичное указание ether1 собственно), но задача не решалась, иначе бы не было созданной темы. Только указание с отрицанием dst-address=!192.168.77.0/24 или dst-address=!192.168.0.0/16 возымело желаемый эффект.

Добро, какова best practices тогда в данном конкретном случае? Большую distance ставим на маршрут по умолчанию, верно? Да, я знаю. При src-nat частенько возникали сложности с внутренней маршрутизацией между подсетями, полагаю это связаного как раз с nat-ом без задания исключений и distance по абзацу выше. Нужно будет поработать в этом ключе для выхода на best practices. Вы же видели в конфиге отключенные для локализации болей непрохождения трафика правила для внешнего интерфейса, в продакшн такое конечно же не выпускается. Иначе и не поднялось, ну или как выше в обсуждении говорилось сращу на всю !192.168.0.0/16 целиком.

При нижеследующей подаче правила nat-а все работает как требуется, другое дело, я так пробовал изначально вроде ж и это не увенчалось успехом и почему вообще проблема вылезла на пустом месте на апробированных сценариях, не понятно. /ip firewall nat add action=masquerade chain=srcnat dst-address=!192.168.77.0/24 src-address=\ 192.168.130.0/24

@jffulcrum Казалось бы, проще некуда. Включаю nat - у пользователей "локалки" утрачивается связанность с удаленной подсетью 192.168.77.0/24 по ту сторону впн-тоннеля. # 2024-02-25 17:05:11 by RouterOS 7.13.5 # # model = RB4011iGS+ /interface bridge add name=bridge_lan /interface ethernet set [ find default-name=ether1 ] comment=WAN set [ find default-name=ether2 ] comment=LAN set [ find default-name=sfp-sfpplus1 ] disabled=yes /interface list add name=WAN_iface /ip pool add name=dhcp_lan ranges=192.168.130.1-192.168.130.253 /ip dhcp-server add address-pool=dhcp_lan interface=bridge_lan lease-time=1d name=dhcp_lan /port set 0 name=serial0 set 1 name=serial1 /interface l2tp-client add allow=mschap2 connect-to=xxx.xxx.xxx.8 disabled=no name=l2tp profile=\ default use-ipsec=yes user=sig /interface bridge port add bridge=bridge_lan interface=ether2 add bridge=bridge_lan interface=ether3 add bridge=bridge_lan interface=ether4 add bridge=bridge_lan interface=ether5 add bridge=bridge_lan interface=ether6 add bridge=bridge_lan interface=ether7 add bridge=bridge_lan interface=ether8 add bridge=bridge_lan interface=ether9 add bridge=bridge_lan interface=ether10 /ip neighbor discovery-settings set discover-interface-list=!WAN_iface /ipv6 settings set disable-ipv6=yes /interface list member add interface=ether1 list=WAN_iface /ip address add address=192.168.130.254/24 comment=Localnet interface=bridge_lan network=\ 192.168.130.0 add address=192.168.210.238/24 interface=ether1 network=192.168.210.0 /ip dhcp-client add disabled=yes interface=ether1 /ip dhcp-server network add address=192.168.130.0/24 dns-server=192.168.130.254 gateway=\ 192.168.130.254 /ip dns set allow-remote-requests=yes servers=192.168.210.1 /ip firewall address-list add address=192.168.77.0/24 list=Ask /ip firewall filter add action=drop chain=input comment="drop invalid connections" \ connection-state=invalid disabled=yes in-interface=ether1 add action=accept chain=input comment="allow related connections" \ connection-state=related disabled=yes in-interface=ether1 add action=accept chain=input comment="allow established connections" \ connection-state=established disabled=yes in-interface=ether1 add action=drop chain=input comment="drop everything else" disabled=yes \ in-interface=ether1 /ip firewall nat add action=masquerade chain=srcnat src-address=192.168.130.0/24 /ip route add comment="Route to Ask" disabled=no distance=1 dst-address=\ 192.168.77.0/24 gateway=192.168.33.1 pref-src="" routing-table=main \ scope=30 suppress-hw-offload=no target-scope=10 add disabled=no dst-address=0.0.0.0/0 gateway=192.168.210.1 routing-table=\ main suppress-hw-offload=no /ip service set telnet disabled=yes set ftp disabled=yes set www disabled=yes set ssh disabled=yes set api disabled=yes set api-ssl disabled=yes /system clock set time-zone-name=Europe/Moscow /system identity set name=GW /system note set show-at-login=no /system routerboard settings set enter-setup-on=delete-key

Воскресного дня, Что-то столкнулся с такой задачкой и не могу найти решения, которое при первом приближении находится на поверхности. Есть маршрутизатор, одним интерфейсом смотрящим наружу в интернет (ether1) и внутренней пользовательской подсеткой (10.1.10.0/24). Также на маршрутизаторе поднят l2tp+ipsec впн-тоннель до удаленного офиса для связанности с одной удаленной подсетью (192.168.10.0/24), на которую поставлен маршрут через впн-тоннель, которая должна быть доступна здешним локальным пользователям наряду с доступом в интернет. Если не включать nat для пользовательской подсетки (10.1.10.0/24), пакеты с удаленной подсетью (192.168.10.0/24) через впн-соединение ходят исправно. Если же включить masquerade или src-nat для пользовательской подсетки (10.1.10.0/24) для возможности пользователям иметь доступ к интернет, утрачивается доступность удаленной подсети (192.168.10.0/24). Дайте мысль, как обеспечить одновременный доступ в интернет и доступность уделенного сегмента подсети через впн-канал. Исключение в правиле нат-а сетевого сегмента (192.168.10.0/24) в качестве dst-назначения или различные варианты построения данного правила с отрицанием не привело к успеху. Даже написание поста, как зачастую бывает, не придало варианта решения задачки.

А для Sendmail примеры адаптации fail2ban есть? Возможность прохождения SMTP-аутентификации требуется не более 10% пользователей, прописываю их в отдельной базе sasldb2. После перехода на FreeBSD 13.2 с Sendmail 8.17.1 эти записи очень перенасыщают maillog мусором. На более старых системах с Sendmail 8.14.6, 8.15.2 понятно тычки были, но хотя бы без дополнительного логирования в основной журнал работы сервера. Банить подсетями, как выше предлагалось, возможно слишком радикально, вшивая овца может подставить и оградить надолго вполне честный диапазон. Думал уменьшить уровень логирования или разделить его вывод в разные файлы (если возможно), но вариант с fail2ban более верный. В общем полезно услышать мнения и как решали схожий вопрос. ... ... Jan 13 18:44:38 sm-mta[11029]: 40DFiXAC011029: AUTH failure (CRAM-MD5): user not found (-20) SASL(-13): user not found: user: sed@mydomain.com property: cmusaslsecretCRAM-MD5 not found in sasldb /usr/local/etc/sasldb2, user=sed, relay=[121.162.147.204] Jan 13 18:44:40 sm-mta[11029]: 40DFiXAC011029: [121.162.147.204] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA Jan 13 18:44:53 sm-mta[11038]: 40DFioDX011038: AUTH failure (CRAM-MD5): user not found (-20) SASL(-13): user not found: user: usenet@mydomain.com property: cmusaslsecretCRAM-MD5 not found in sasldb /usr/local/etc/sasldb2, user=usenet@mydomain.com, relay=[216.126.65.186] Jan 13 18:44:54 sm-mta[11038]: 40DFioDX011038: [216.126.65.186] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA ...

Для чего? Вопрос был задан по существу, причем тут тоннель, самостоятельное мониторирование и управление.

Да проще будет другую железку под указанные цели отдать провайдеру. Тот же Zyxel USG FLEX. Жаль, что у нас на борту нет гибкости конфигурирования SNMP. С другой стороны, мониторишь обычно свою инфраструктуру, поэтому не так критично.

Приветствую, встал вопрос поставить на мониторирование у провайдера одну нашу пограничную железку через SNMP. В качестве агрегатора данный рассмотрим PRTG (для проверки). На мониторинг хотелось бы отдавать только загрузку и доступность определенных сетевых наружных интерфейсов микрота. Остальная информация о состоянии железки доступна быть не должна. Вроде в ROS нет фильтров по OID, можно ли правильно сконфигурить SNMP на микроте, чтобы информировать только по требуемым значениям (сенсорам) и не позволяя получать считывающей стороне лишнего? Спасибо.

Необоснованно усложнять и избыточно сепарировать сетевую инфраструктуру тоже неверно. Если в определенных случаях это и применимо, то не должно распространяться просто ради за компанию. По существу проблемы уже на самом объекте - все аплинки от оборудования с повышенной сетевой нагрузкой сведены на порты единого свиччипа, из бриджа с включенным vlan-filtering-ом выведены порты из соседних свитччипов, проапгрейдено до 7.7, принципиальной разницы по скоростным показателям с учетом проанонсированного в свое время HW offload support for vlan-filtering on RTL8367 switch chip не замечено, однако вопрос все же решается применением FastTrack-а, накладываемого на созданные интерфейс-листы задействованных во внутрисетевом обмене vlan-интерфейсов. Дальше наблюдение.

Вы стали бы собственноручно делать подобную реализацию, интересно знать.

Вернулись к тому, с чего начинали - маршрутизатор. Либо обеспечиваем условия для FastTrack между влан-подсетями, либо оборудование с запасом.

Тогда маршрутизацию между подсетями vlan на кого воскладываете?

Соглашусь, кесарю - кесарево. Но тогда вопрос, кто должен осуществлять маршрутизацию подсетей vlan. Коммутатор L3, получается, лишенный обременений в виде FW и т.п., на который переносится и терминирование vlan в таковом случае с маршрутизатора.

А ничем. Очередными дебатами с саабом. У меня возможность применения FastTrack-а в решении задачи направлено именно на внутрисетевой обмен, задействуя быстрый путь только для общения подсетей vlan-интерфейсов между собой. И оно работает, на имеющемся стенде, во всяком случае. Но поднялось только после отключения влан фильтеринга на бридже и переноса с него vlan-ов на свиччип (изменения парадигмы настройки vlan на маршрутизаторе). Для чего включается и где о об этом говорится в документации по FastTrack? Быстрый путь нужен мне для обмена непосредственно между подсетями интерфейсов, через которые происходит высокая нагрузка.

@SUrov_IBM Добрый вечер, спасибо за информацию! Тут проблема скорее в ограничениях от Fast Path-а, который не дружит с vlan-filtering, а из-за этого не отрабатывают правила FastTrack-а. Сам по себе HW offload support for vlan-filtering может и не сделать существенной погоды. Но все это предположения, лишенные практики. Думаю, разумно будет пойти по пути перевода вланов с бриджа на чип, а если на RB1100AHx4 это не сработает (хотя странно, с более младшей моделью RB1100AHx2 все удалось), тогда смотреть в сторону перехода на 7.х, просто если уходить на эту ветку, скорее всего потянет за собой апгрейд и всего комплекса остального оборудования, от 6.х хотя бы точнее знаешь, чего ожидать, так сказать. Про обвязку ресурсоемкого обмена в рамках одного чипа я понял, вписываюсь в его пять портов. Но что я не питаю особой надежды:

На RB1100AHx2 добился результата, переведя на нем vlan-ы с бриджа на Switch Chip заработал и FastTrack, почти удвоив скорость обмена между подсетями вланов, не повредив функциональность ros. Но на продакшн устройстве RB1100AHx4 другие Switch-chip-ы используются, а они согласно wiki не поддерживают VLAN-таблиц и взлетит ли решение там еще не пробовал.

Ну на стенде с RB1100AHx2 пока два свиччипа. То есть для терминирования серверной группы и порт от пользовательских подсетей завести на один из свитччипов (чтобы обмен обвязать в рамках одного чипа), а вход провайдеров и нетребовательного к нагрузкам подключения сделать на втором, если я верно улавливанию вашу мысль. Ну трафик по L2 в рамках вилана (подсети) у меня и не загружает процессор на всем вовлеченном оборудовании, загружает процессор трафик по L3 как раз между посетями виланов при внутренней маршрутизации на маршрутизаторе.

Шейперов нет, FW, да, это рабочий инструмент, манглы только для реализации файловера, заворачивания запросов dns на себя любимого и блокировки софта неконтролируемых доступов. Все это необходимо в решении задач. Никто и не говорил, что вилана добавляются в бридж. Они именно и терминируются на маршрутизаторе. Виланы развернуты на бридже, на котором включен VLAN filtering, такова парадигма настройки и далее раздаются на коммутаторы. Отсюда я и задавался вопросом, что может конкретно на маршрутизаторе перестроить vlan-ы с бриджа на Switch Chip (вроде эти два варианта увязываемы между оборудованием), дабы отказаться от VLAN filtering на бридже, а далее опять же с помощью FastTrack (который может все же заработает?) упростить проход трафика между вовлеченными во внутренний обмен vlan-интерфейсами, как выше приводил пример.

Torch не включал (трафик при транзитной перекачке наблюдал в правилах), FastPath включен, там все по дефолту. В мане по FastPath имеется такое: Но т.к. vlan-ы у меня на бридже и разумеется задействован VLAN filtering, это может являться причиной неработоспособности FastTrack-а? Еще все же действие динамических правил passthrough вместо accept непонятно.

@jffulcrum не очень понял в части приведенной утилиты. Если чем я проверял скоростные показатели - то банально перекачка исошника на 1,5 гига между узлами, находящимися в разных подсетях.