Grims,
1. Какие сети BOGON, которые могут инициировать обращение из-вне, не окажутся заблокированными правилом, которое блокирует invalid-трафик? Ответ: никакие. Вывод: блокировка BOGON смысла не имеет, если уже имеется правило, которое блокирует invalid-трафик. А наличие этого правила является правилом хорошего тона.
2. То, что RFC регламентирует, что такое BOGON не дает ответ на поставленный вопрос. Так же напоминаю, что часть сетей не являются постоянными и могут динамически изменятся со временем.
3. Аргумент про то, что надо надо читать официальную документацию очень хороший. Но еще лучше аргумент про то, что надо не просто слепо следовать рекомендациям, но и понимать, что и зачем делается. К сожалению, на официальной англоязычной Wiki не на 100% все гладко. Я сам несколько раз находил неточности на ней. К счастью, вендор обсуждает такие вопросы и при необходимости вносит правки.
Списка вопросов у тренеров нет. Так же у тренеров нет доступа к правильным ответам на вопросы. Это я говорю как тренер MikroTik. Другое дело, что тренера часто многие вопросы видят и понимают, что уже встречали их. Соглашусь с тем, что если изучать материал, то сдадите.
1. Отключите правило FastTrack. Вы скорее всего слышали, что оно дает бешеный прирост производительности и маршрутизатор начинает работать, как на стероидах, но Вы должны понимать, что за все надо платить. А платите Вы тем, что при FastTrack перестает работать львиная доля функционала. Подробнее можно почитать здесь: https://mikrotik.vetriks.ru/wiki/Межсетевой_экран:... . Обычно это правило мешать не должно, но лучше привести в порядок.
2. Перезагрузите устройство, т. к. правило Dummy уходит только после перезагрузки.
3. Если не помогло, то отключите вообще все правила файервола.
4. Если не помогло, то скорее всего ошибку надо искать на устройстве куда идет проброс портов. Возможно на нем не прописан шлюз или прописан не верный шлюз.
Так же в качестве входящего интерфейса надо указывать виртуальный интерфейс, если используется виртуальный интерфейс (PPPoE или что-то подобное)
Правильно поставленный вопрос - это на половину полученный ответ.
Ваш вопрос: "Как с наименьшими трудо и деньгозатратами реализовать доступ к серверу?"
Я ответил по существу Вашего вопроса. То, что я посоветовал это быстро и бесплатно.
Если Вы не знаете, чем публичный IP-адрес отличается от приватного, то так и надо было писать сразу. Я Вам в соседнем посте уже написал, что если Вы хотите, что бы Вам помогали, то Вам надо разговаривать вежливее. Я Вам дальше помогать не стану.
copenhagen72, прежде всего Вам надо понять, что люди здесь помогают на безвозмездной основе и хорошо бы общаться с ними с уважением. В своем сообщении Вы много чего описали не понятно. Если Вы так будете писать, то я не удивлюсь, если Вам перестанут отвечать.
Вам надо выяснить какие порты используют Ваши сервисы и сделать на них пробросы портов. Инструкция есть в сообщении выше. Так же в файерволе должно быть сделано исключение для правила проброса портов.
Что я рекомендую я написал выше. Если вообще лень возиться с настройкой то:
1. В IP => DHCP-server выключите все сервера.
2. В IP => Firewall => Filter выключите все правила.
3. В IP => Firewall => NAT выключите все правила.
Шамиль, к сожалению, сейчас загрузка увеличилась и внимательно проверить не успеваю. Прежде всего благодарю, что конфигурацию вставили отформатированную. Это заметно облегчает чтение.
То, что обнаружили опишу ниже. Не факт, что это поможет с Вашей проблемой, но тем не менее может оказаться полезным.
1. В Файерволе у Вас жесткий бардак. В цепочке Forward, если не считать правила блокирующего invalid трафик у Вас правила пустышки. Вообще советую внимательно прочесть всю статью.
2. Возможно торопился, но не понял назначение этого правила "add action=masquerade chain=srcnat out-interface=ether1"
3. Рекомендую указать исходящий интерфейс в этом правиле "add action=masquerade chain=srcnat comment="vpn_clients NAT rule" src-address=192.168.192.0/24"
4. Кажется у Вас есть проблемы с маршрутизацией. Есть отсылки к маркированным маршрутам "wan2_route" и "wan1_route". При этом самих маршрутов нет. Есть и другие подозрительные моменты.
Рекомендации:
Выполняйте именно в том порядке, как они будут идти.
1. Сделайте полную резервную копию.
2. Оставьте только одного Интернет-провайдера. Любого.
3. Отключите все, что касается маркировки маршрутов в /ip route, /ip route rule и /ip firewall mangle
4. Сбросьте все соединения в Connection Tracker и проверьте работу.
5. Разберитесь с правилами NAT. Больше всего меня смущает это правило "add action=masquerade chain=srcnat out-interface=ether1"
6. Сбросьте все соединения в Connection Tracker и проверьте работу.
Если говорить про блокировку лишнего трафика без относительно Вашей ситуации, то рекомендуется использовать нормально закрытый файрвол для цепочки Input и нормально закрытый для трафика из WAN для цепочки Forward, для трафика из LAN для цепочки Forward опционально.
Обычно это выглядит так: 1-е правило: разрешить established & related трафик 2-е правило: заблокировать invalid трафик промежуточные правила: разрешить нужный трафик. последнее правило: запретить весь трафик
QoS надо уметь правильно настраивать. Если маршрутизатор многоядерный и не оптимально настроить QoS, то может получиться так, что будет загружено всего одно ядро, а остальные простаивают. При этом будет принцип бутылочного горлышка. Тут главное правильно настроить.
1. Какие сети BOGON, которые могут инициировать обращение из-вне, не окажутся заблокированными правилом, которое блокирует invalid-трафик? Ответ: никакие. Вывод: блокировка BOGON смысла не имеет, если уже имеется правило, которое блокирует invalid-трафик. А наличие этого правила является правилом хорошего тона.
2. То, что RFC регламентирует, что такое BOGON не дает ответ на поставленный вопрос. Так же напоминаю, что часть сетей не являются постоянными и могут динамически изменятся со временем.
3. Аргумент про то, что надо надо читать официальную документацию очень хороший. Но еще лучше аргумент про то, что надо не просто слепо следовать рекомендациям, но и понимать, что и зачем делается. К сожалению, на официальной англоязычной Wiki не на 100% все гладко. Я сам несколько раз находил неточности на ней. К счастью, вендор обсуждает такие вопросы и при необходимости вносит правки.