Перейти к содержимому
Калькуляторы

mrrc

Пользователи
  • Публикации

    164
  • Зарегистрирован

  • Посещение

О mrrc

  • Звание
    Студент
    Студент

Контакты

  • ICQ
    Array
  1. Вы подключились к участию поназидать, я не пойму?) Или невнимательно читали все обсуждение выше) Контрпродуктивно.
  2. Например? Работает, как выше приводилось. Это вы о чем?
  3. Сейчас с точностью сценарий не вспомню, но удаленные маршрутизаторы в схеме не присутствовали, маршрутизация vlan-подсетей велась внутри самого маршрутизатора. Как раз по теме имела место быть базовая схема l2tp+ipsec тоннеля до удаленной стороны. Никакие обвязки в if_list-ы как выше упоминал не проканали, а тоннель как раз прокладывался через интернет-соединение через единый для всего wan-интерфейс.
  4. @himikrzn да я ранее также придерживался аналогичной практики, а в данном конкретном случае вылезло то, что вылезло, поставив в тупик.
  5. @himikrzn применительно к вопросу в теме if-листы с внешним ифейсом разумеется опробовались (как и прямое единичное указание ether1 собственно), но задача не решалась, иначе бы не было созданной темы. Только указание с отрицанием dst-address=!192.168.77.0/24 или dst-address=!192.168.0.0/16 возымело желаемый эффект.
  6. Добро, какова best practices тогда в данном конкретном случае? Большую distance ставим на маршрут по умолчанию, верно? Да, я знаю. При src-nat частенько возникали сложности с внутренней маршрутизацией между подсетями, полагаю это связаного как раз с nat-ом без задания исключений и distance по абзацу выше. Нужно будет поработать в этом ключе для выхода на best practices. Вы же видели в конфиге отключенные для локализации болей непрохождения трафика правила для внешнего интерфейса, в продакшн такое конечно же не выпускается. Иначе и не поднялось, ну или как выше в обсуждении говорилось сращу на всю !192.168.0.0/16 целиком.
  7. При нижеследующей подаче правила nat-а все работает как требуется, другое дело, я так пробовал изначально вроде ж и это не увенчалось успехом и почему вообще проблема вылезла на пустом месте на апробированных сценариях, не понятно. /ip firewall nat add action=masquerade chain=srcnat dst-address=!192.168.77.0/24 src-address=\ 192.168.130.0/24
  8. @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
  9. Воскресного дня, Что-то столкнулся с такой задачкой и не могу найти решения, которое при первом приближении находится на поверхности. Есть маршрутизатор, одним интерфейсом смотрящим наружу в интернет (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-назначения или различные варианты построения данного правила с отрицанием не привело к успеху. Даже написание поста, как зачастую бывает, не придало варианта решения задачки.
  10. А для 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 ...
  11. Для чего? Вопрос был задан по существу, причем тут тоннель, самостоятельное мониторирование и управление.
  12. Да проще будет другую железку под указанные цели отдать провайдеру. Тот же Zyxel USG FLEX. Жаль, что у нас на борту нет гибкости конфигурирования SNMP. С другой стороны, мониторишь обычно свою инфраструктуру, поэтому не так критично.
  13. Приветствую, встал вопрос поставить на мониторирование у провайдера одну нашу пограничную железку через SNMP. В качестве агрегатора данный рассмотрим PRTG (для проверки). На мониторинг хотелось бы отдавать только загрузку и доступность определенных сетевых наружных интерфейсов микрота. Остальная информация о состоянии железки доступна быть не должна. Вроде в ROS нет фильтров по OID, можно ли правильно сконфигурить SNMP на микроте, чтобы информировать только по требуемым значениям (сенсорам) и не позволяя получать считывающей стороне лишнего? Спасибо.
  14. Необоснованно усложнять и избыточно сепарировать сетевую инфраструктуру тоже неверно. Если в определенных случаях это и применимо, то не должно распространяться просто ради за компанию. По существу проблемы уже на самом объекте - все аплинки от оборудования с повышенной сетевой нагрузкой сведены на порты единого свиччипа, из бриджа с включенным vlan-filtering-ом выведены порты из соседних свитччипов, проапгрейдено до 7.7, принципиальной разницы по скоростным показателям с учетом проанонсированного в свое время HW offload support for vlan-filtering on RTL8367 switch chip не замечено, однако вопрос все же решается применением FastTrack-а, накладываемого на созданные интерфейс-листы задействованных во внутрисетевом обмене vlan-интерфейсов. Дальше наблюдение.
  15. Вы стали бы собственноручно делать подобную реализацию, интересно знать.