Коллеги, такой вот вопрос... Есть нат-правило: chain=srcnat action=src-nat to-addresses=10.100.55.1 src-address=!192.168.0.0/16 dst-address=192.168.0.0/16 Его смысл в том, что оно натит все запросы из интернета. Но есть два IP-адреса, запросы от которых натиться не должны... Скажем 4.4.4.4 и 5.5.5.5 Как бы это провернуть, какое правило ещё добавить или первое изменить? То есть чтобы запросы от этих двух айпи не натились, а от всех остальных натились?

Коллеги, такой вот вопрос... Есть нат-правило: chain=srcnat action=src-nat to-addresses=10.100.55.1 src-address=!192.168.0.0/16 dst-address=192.168.0.0/16 Его смысл в том, что оно натит все запросы из интернета. Но есть два IP-адреса, запросы от которых натиться не должны... Скажем 4.4.4.4 и 5.5.5.5 Как бы это провернуть, какое правило ещё добавить или первое изменить? То есть чтобы запросы от этих двух айпи не натились, а от всех остальных натились?

Коллеги, такой вот вопрос... Есть нат-правило: chain=srcnat action=src-nat to-addresses=10.100.55.1 src-address=!192.168.0.0/16 dst-address=192.168.0.0/16 Его смысл в том, что оно натит все запросы из интернета. Но есть два IP-адреса, запросы от которых натиться не должны... Скажем 4.4.4.4 и 5.5.5.5 Как бы это провернуть, какое правило ещё добавить или первое изменить? То есть чтобы запросы от этих двух айпи не натились, а от всех остальных натились?

А если src заменить на адресс лист и туда указать то что не надо натить ?

без схемы сети с указанием адресов на интерфейсах (или хотя бы текстового описания) вообще непонятно зачем это правило нужно

я просто не хотел грузить коллег инфой... Но сейчас распишу! Есть микротик1 с серым внешним IP-адресом и локальная сеть за ним. В этой сети есть девайсы, которые должны быть доступны извне (видеорегистратор в частности). Есть микротик2 (chr в vps) с белым внешним IP-адресом, до которого микротик1 строит l2tp-туннель, и настроена маршрутизация. Идея в том, чтобы внешние запросы из интернета приземлялись на микротик2, и потом маршрутизировались до микротика1 туда и обратно. И правило на мироктике2: chain=srcnat action=src-nat to-addresses=10.100.55.1 src-address=!192.168.0.0/16 dst-address=192.168.0.0/16 это обеспечивает! Всё работает. —— НО в локалке есть ещё зловредная АТС-ка. И вот ей прям НУЖНО получать запросы с тех же IP (4.4.4.4 и 5.5.5.5 условно), куда она строит SIP-транк свой. Я очень плохо разбираюсь в телефонии, и в общем обмануть АТС не смог. Поэтому и возникла необходимость ещё в одном нат-правиле: чтобы запросы от 4.4.4.4 и 5.5.5.5 не натились. Что касается АТС-ки, то её трафик будет маршрутизироваться через микротик2 сразу, благодаря mangle-правилу route

попробуйте как я написал выше

да, спасибо, прямо сейчас буду пробовать! @Prislonsky Владимир вашу рекомендацию тоже увидел, попробую и этот вариант, спасибо!

я просто не хотел грузить коллег инфой... Но сейчас распишу! Есть микротик1 с серым внешним IP-адресом и локальная сеть за ним. В этой сети есть девайсы, которые должны быть доступны извне (видеорегистратор в частности). Есть микротик2 (chr в vps) с белым внешним IP-адресом, до которого микротик1 строит l2tp-туннель, и настроена маршрутизация. Идея в том, чтобы внешние запросы из интернета приземлялись на микротик2, и потом маршрутизировались до микротика1 туда и обратно. И правило на мироктике2: chain=srcnat action=src-nat to-addresses=10.100.55.1 src-address=!192.168.0.0/16 dst-address=192.168.0.0/16 это обеспечивает! Всё работает. —— НО в локалке есть ещё зловредная АТС-ка. И вот ей прям НУЖНО получать запросы с тех же IP (4.4.4.4 и 5.5.5.5 условно), куда она строит SIP-транк свой. Я очень плохо разбираюсь в телефонии, и в общем обмануть АТС не смог. Поэтому и возникла необходимость ещё в одном нат-правиле: чтобы запросы от 4.4.4.4 и 5.5.5.5 не натились. Что касается АТС-ки, то её трафик будет маршрутизироваться через микротик2 сразу, благодаря mangle-правилу route

я просто не хотел грузить коллег инфой... Но сейчас распишу! Есть микротик1 с серым внешним IP-адресом и локальная сеть за ним. В этой сети есть девайсы, которые должны быть доступны извне (видеорегистратор в частности). Есть микротик2 (chr в vps) с белым внешним IP-адресом, до которого микротик1 строит l2tp-туннель, и настроена маршрутизация. Идея в том, чтобы внешние запросы из интернета приземлялись на микротик2, и потом маршрутизировались до микротика1 туда и обратно. И правило на мироктике2: chain=srcnat action=src-nat to-addresses=10.100.55.1 src-address=!192.168.0.0/16 dst-address=192.168.0.0/16 это обеспечивает! Всё работает. —— НО в локалке есть ещё зловредная АТС-ка. И вот ей прям НУЖНО получать запросы с тех же IP (4.4.4.4 и 5.5.5.5 условно), куда она строит SIP-транк свой. Я очень плохо разбираюсь в телефонии, и в общем обмануть АТС не смог. Поэтому и возникла необходимость ещё в одном нат-правиле: чтобы запросы от 4.4.4.4 и 5.5.5.5 не натились. Что касается АТС-ки, то её трафик будет маршрутизироваться через микротик2 сразу, благодаря mangle-правилу route

😅🥲 а зачем вы натите с CHR в локалку.... ??? через SRC......

ничего лучше не придумал( У самого ощущения колхоза и кривизны( Я не настоящий сварщик( Но какие есть ещё варианты? Просто допустим мне нужно открыть в интернет порт 80 с устройства 192.168.0.100 У микротика1 серый IP - открыть ничего не получится априори Значит открываем порт на микротике2, он получает пакет из интернета скажем с 7.7.7.7, шлёт его на 192.168.0.100 192.168.0.100 получив пакет от 7.7.7.7 отвечает ему через свою шлюз 192.168.0.1, то есть микротик1 Соотвественно коннекта нет...

ничего лучше не придумал( У самого ощущения колхоза и кривизны( Я не настоящий сварщик( Но какие есть ещё варианты? Просто допустим мне нужно открыть в интернет порт 80 с устройства 192.168.0.100 У микротика1 серый IP - открыть ничего не получится априори Значит открываем порт на микротике2, он получает пакет из интернета скажем с 7.7.7.7, шлёт его на 192.168.0.100 192.168.0.100 получив пакет от 7.7.7.7 отвечает ему через свою шлюз 192.168.0.1, то есть микротик1 Соотвественно коннекта нет...

Читайте мультиWAN !

просто помечаете коннекты из ВПН и потом ответ заводите в другую таблицу маршрутизации

я жёстко туплю, да?😟

я жёстко туплю, да?😟

вот я так и думал, что не тем путём иду. Спасибо, буду копать сейчас эту тему

я жёстко туплю, да?😟

погодите, мультиван? а чем мне поможет микроавтобус от Вольксвагенf? шутка) простите! Уже нагуглил тему, разбираюсь. Может получится за вечер перелопатить схему, и сделать нормально.

У вас есть возможность и бюджет взять второй IP ? на VPS

да, конечно, уже два доп IP есть

вы их можете напрямую отдать в микротик1

это в рамках multiWAN так можно сделать, или другая отдельная технология? Я просто ещё не успел вникнуть

это в рамках multiWAN так можно сделать, или другая отдельная технология? Я просто ещё не успел вникнуть

Вы можете дополнительный IP отдать прям профилю впн клиента в remote IP, разрешить forward на тот айпи, и вы напрямую на клиенте ВПН получите публичный Айпи, делаете в сторону впн нат и всё (на клиенте)

в итоге у вас только 1 dst nat, и один src маскарад на выход. или по обычному делаете тоже самое но у вас src маскарад на CHR и 2 DST NAT выходит.....

Вы можете дополнительный IP отдать прям профилю впн клиента в remote IP, разрешить forward на тот айпи, и вы напрямую на клиенте ВПН получите публичный Айпи, делаете в сторону впн нат и всё (на клиенте)

хотя я туплю во втором варианте тоже один DST NAT же... если все правильно сделать, это меня уже глючит изза тех кто кидает маскарад даже в сторону бриджа....

вроде почти всё понял, но не могу врубиться в это момент: »дополнительный IP отдать прям профилю впн клиента в remote IP Это то есть в качестве Remote Address я указываю один из дополнительных IP chr`а?

вроде почти всё понял, но не могу врубиться в это момент: »дополнительный IP отдать прям профилю впн клиента в remote IP Это то есть в качестве Remote Address я указываю один из дополнительных IP chr`а?

вроде почти всё понял, но не могу врубиться в это момент: »дополнительный IP отдать прям профилю впн клиента в remote IP Это то есть в качестве Remote Address я указываю один из дополнительных IP chr`а?

простите( Вот знал же, что не надо сюда постить свою халтуру

Добрый день! С CCR2004-1G-2XS-PCIe кто нибудь уже игрался?

Товарищи подскажите... я правильно понимаю что производительность у CRS112 не более 300 мегабит в режиме обычного свича?

Товарищи подскажите... я правильно понимаю что производительность у CRS112 не более 300 мегабит в режиме обычного свича?

Приветствую! Прошу помочь, кто знает. L2TP+IPsec на Android. Проблема следующего характера: Приобрем смартфон на android MIUMI 13. в MIUMI 12,5 был большой перечень выбора VPN. На MIUMI 13 их всего-то только три. Есть MIKROTIK 2011 Настроена L2TP+IPsec С работы подключаюсь с ПК по L2TP+IPsec без проблем. А со смартфона на MIUMI 13 нет поддержки L2TP+IPsec, где ввожу пароль ipsec логин и пароль пользователя. Может кто знает, какие есть альтернативные приложения для android MIUMI 13 для подключения по L2TP+IPsec? Или может быть другие варианты использования Mikrotik? Благодарю.

Android 12,5 MIUMI 13

Каждую пятницу, выходя из офиса, он громко изрекал: «ЖОПИЗДАН!» Охрана заметно напрягалась… Уборщица крестила его вслед… И только Лида-переводчица тихонько поправляла: «Job is done…» минутку юмора ребятки !!!

🤣 Я подумал про кучу шкафов, чтобы отрубание питания любого шкафа не меняло топологию сети

запитать железку от самой себя?

https://www.youtube.com/watch?v=3NaomsfbE34

А как на это влияет роутер?

Где нужно много PoE, обычно удобно использовать PoE свич

меня заинтересовал вариант, что 2 таких железки, соединённые между собой будут питать друг друга, если пропадёт питание на одной из них

тут четко проговорено голосом и прописано буквами, что на всех портах есть и пое ин, и пое аут

довольно востребованная фича у провайдеров