3 секунды
https://help.mikrotik.com/docs/display/ROS/Netwatch#Netwatch-Properties
Спасибо
Alexei
Евгений
А не подскажите…
Было место, куда необходимо обращаться и подавать данные про впн сервисы.
Чтобы их не блочили.
Есть у кого ссылочка?
░▒▓ТрезвыйЕжик▓▒░
Sasha
Где то в канале минцифры было описание уведомления и внесением в белый список адресов юрлиц. Для трансграничных соединений. Для соеденения внутри страны к счастью этого делать не надо канал работает
Евгений
Нашел. Спасибо
Евгений
Евгений
Странно. У меня все виды каналов внутри рф работают
Проблема локальная
Скорее всего где-то магистрал тспу ставит
Alex
Добрый день.
Подскажите, заворачиваю для локальной сети на микроте выход в интернет через чистый IPsec без GRE: 192.168.177.0/24 -> 0.0.0.0/0.
Как правильно вычленить из 0.0.0.0/0 - 192.168.0.0/16 ?
Потому как 192.168.0.0/16 нужно маршрутизировать через next hop адрес.
Создать правило в фаерволле которое не будет заворачивать в IPsec ?
Eugene
Подскажите, а как правильно ipv6 настроить в случае, если ipv6 шлюз находится за пределами выделенной сети?
Для микротика выделена сеть: 2a00:abcd:def0:a1::/64. Шлюзом должен быть 2a00:abcd:def0::1 или же fe80::1. Ставлю так — шлюз не обнаруживается. Пробую автоматически шлюз находить, то есть ::/0 зароучиваю в ether1 без указания шлюза — так пингуется 2a00:abcd:def0::1, но дальше него no route to host
Innokentiy
Подскажите, а как правильно ipv6 настроить в случае, если ipv6 шлюз находится за пределами выделенной сети?
Для микротика выделена сеть: 2a00:abcd:def0:a1::/64. Шлюзом должен быть 2a00:abcd:def0::1 или же fe80::1. Ставлю так — шлюз не обнаруживается. Пробую автоматически шлюз находить, то есть ::/0 зароучиваю в ether1 без указания шлюза — так пингуется 2a00:abcd:def0::1, но дальше него no route to host
естественно, он же обязан быть в одной сети с клиентами
Eugene
естественно, он же обязан быть в одной сети с клиентами
так речь про шлюз, в ipv6 это не требуется же
Innokentiy
что именно не требуется?
Eugene
что именно не требуется?
чтобы шлюз обязательно был в одной сети. То есть в linux это спокойно работает, а в микротике - нет
Андрей
2a00:abcd:def0:a1::/64 - на бридж, на ether1 - 2a00:abcd:def0::2/64, gw - 2a00:abcd:def0::1/64
Innokentiy
чтобы шлюз обязательно был в одной сети. То есть в linux это спокойно работает, а в микротике - нет
я не понимаю, что вы пишете. буквы вроде все знакомые, но смысл от меня ускользает
Innokentiy
IP дает возможность межсетевого взаимодействия (такого, где коммуницирующие узлы не связаны прямыми каналами), он потому так и называется - InterNet Protocol
Eugene
2a00:abcd:def0:a1::/64 - на бридж, на ether1 - 2a00:abcd:def0::2/64, gw - 2a00:abcd:def0::1/64
нет доступа к 2a00:abcd:def0:: - это сеть провайдера. Выделена только 2a00:abcd:def0:a1::/64 со шлюзом 2a00:abcd:def0::1
Innokentiy
делает он это за счет того, что сообщения маршрутизируются по цепочке транзитных узлов, которые друг с другом связаны прямыми каналами
Eugene
вариант со шлюзом fe80::1 тоже не работает в микротике, хотя в линуксе работает
Innokentiy
нет доступа к 2a00:abcd:def0:: - это сеть провайдера. Выделена только 2a00:abcd:def0:a1::/64 со шлюзом 2a00:abcd:def0::1
вы из выданной вам сети /64 выделяете один адрес и вешаете его на «внутренний» интерфейс роутера, клиентам назначаете его шлюзом
Innokentiy
на микротике прописываете дефолт на шлюз провайдера
Innokentiy
вариант со шлюзом fe80::1 тоже не работает в микротике, хотя в линуксе работает
работает, просто его руками надо забить
Innokentiy
Innokentiy
вы попробуйте
Innokentiy
только лучше не ::2, а чонить порандомнее
Innokentiy
лучше указать саму сеть а кто мне даст использовать 2a00:abcd:def0::/64 в поле адреса и поставить галку еуи64
Innokentiy
1. есть риск, что уже занято
2. зарезервировано под эникаст (установить такой адрес позволит, но это нехорошо)
Андрей
1. есть риск, что уже занято
2. зарезервировано под эникаст (установить такой адрес позволит, но это нехорошо)
Есть вероятность, что у оператора роутинг не настроен:)
Eugene
Есть вероятность, что у оператора роутинг не настроен:)
а под линуксом почему тогда работает?
Eugene
там просто указываешь 2a00:abcd:def0:a1::/64 и шлюзом 2a00:abcd:def0::1
Innokentiy
проводя аналогию с ipv4 - вы утверждаете, что вы повесили на интерфейс адрес 10.1.1.0/24 и прописали шлюзом 10.0.0.0
Innokentiy
то ли у оператора настроено что-то ооооочень странное, то ли вы где-то ошиблись
Innokentiy
поскольку подозревать второе нет оснований, хочется разобраться, что там навертел провайдер
Eugene
скрины в студию
link/ether ca:00:00:54:77:76 brd ff:ff:ff:ff:ff:ff
altname enp1s0
inet6 2a00:abcd:def0:a1::/64 scope global
# ip -6 route show
2a00:abcd:def0:a1::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via 2a00:abcd:def0::1 dev eth0 metric 1024 onlink pref medium
Eugene
примерно так
Innokentiy
ip -6 neighbor еще пжлст
Eugene
ip -6 neighbor еще пжлст
fe80::4e00:82ff:fed2:bc dev eth0 lladdr 4c:00:82:d2:00:bc router REACHABLE
2a00:abcd:def0::1 dev eth0 lladdr 4c:00:82:d2:00:bc router REACHABLE
Eugene
прописал в микротик fe80::4e00:82ff:fed2:bc%ether1 шлюзом - так работает
Eugene
видимо, link local fe80::1 подох
Innokentiy
скорее в мт по умолчанию дефолт роутер через слаак при включенном форвардинге не принимает
Innokentiy
а в линукс вам его впихивали именно слааком
Eugene
нет там SLAAC, толко ручная конфигурация
Eugene
иначе бы линукс ipv6 спокойно получал в режиме auto
Eugene
просто линукс игнорирует нахождение шлюза вне сети /64 и спокойно его использует
Eugene
собственно, не важно где шлюз, если известен его мак
Innokentiy
просто линукс игнорирует нахождение шлюза вне сети /64 и спокойно его использует
чтобы его «использовать», надо чтобы на такой нд-запрос кто-то ответил
Innokentiy
в норме на такой кривой запрос никто отвечать не должен
Eugene
в норме на такой кривой запрос никто отвечать не должен
ну в общем-то верно, на стороне операторского шлюза link-local адрес не был выделен в fe80::1. Сейчас поменяли и заработали. Спасибо за помощь, расковыряли причины. Интересно оказалось, что это только на микротиках вылезло, а на линуксах вполне себе работал шлюз, который не находится в одной сети с выданным префиксом
Alex
Добрый день.
Подскажите, заворачиваю для локальной сети на микроте выход в интернет через чистый IPsec без GRE: 192.168.177.0/24 -> 0.0.0.0/0.
Как правильно вычленить из 0.0.0.0/0 - 192.168.0.0/16 ?
Потому как 192.168.0.0/16 нужно маршрутизировать через next hop адрес.
Создать правило в фаерволле которое не будет заворачивать в IPsec ?
или как добавить роут для источника, без подмены адресов, с маршрутизацией и что бы далее оно не попадало в IPsec ?\
Константин 🪬
или как добавить роут для источника, без подмены адресов, с маршрутизацией и что бы далее оно не попадало в IPsec ?\
поставить дистанцию на 0 больше чем в 192
Alex
поставить дистанцию на 0 больше чем в 192
так ipsec policy
add action=encrypt dst-address=0.0.0.0/0 src-address=192.168.177.0/24
Alex
так ipsec policy
add action=encrypt dst-address=0.0.0.0/0 src-address=192.168.177.0/24
и оно загребает в себя 192.168.0.0/16
Аникей
/report
/report
Спасибо за жалобу. Сообщение Дима [6281854874] отправлено администраторам на проверку.
Константин 🪬
так ipsec policy
add action=encrypt dst-address=0.0.0.0/0 src-address=192.168.177.0/24
я с ipsec мало работал но всё равно попробуй дистанцию 0 поставить больше чем 192 мб прокатит там 2 кнопки нажать )
Alex
я с ipsec мало работал но всё равно попробуй дистанцию 0 поставить больше чем 192 мб прокатит там 2 кнопки нажать )
врядли, политика ипсека забирает пакет в себя не смотря на то что есть деф роут например
Alex
вроде помогла полисия с action=none для 192.168.0.0/16
Олег
ну в общем-то верно, на стороне операторского шлюза link-local адрес не был выделен в fe80::1. Сейчас поменяли и заработали. Спасибо за помощь, расковыряли причины. Интересно оказалось, что это только на микротиках вылезло, а на линуксах вполне себе работал шлюз, который не находится в одной сети с выданным префиксом
на линуксах есть волшебное слово on-link, которое такое позволяет
Антон
ну в общем-то верно, на стороне операторского шлюза link-local адрес не был выделен в fe80::1. Сейчас поменяли и заработали. Спасибо за помощь, расковыряли причины. Интересно оказалось, что это только на микротиках вылезло, а на линуксах вполне себе работал шлюз, который не находится в одной сети с выданным префиксом
Мне кажется это бы вылезло ещё и на Alpine Linux.
Там как в микроте стандартная Си либа musl.
Спасибо за жалобу. Я отправила данный эпизод администраторам на проверку.
Alexey
Спасибо за жалобу. Я отправила данный эпизод администраторам на проверку.
нечаянно тапнул. прошу извинить
Eugene
Мне кажется это бы вылезло ещё и на Alpine Linux.
Там как в микроте стандартная Си либа musl.
а влияет либа разве? Мне кажется, это просто лимиты микротика такие. Ну да ладно, зато линк локал настроил
Антон
/report
/report
Спасибо за жалобу. Сообщение Милона Алексеева [5124477332] отправлено администраторам на проверку.
Антон
а влияет либа разве? Мне кажется, это просто лимиты микротика такие. Ну да ладно, зато линк локал настроил
Да библиотека си здесь тоже влияет.
Maxim
Коллеги, странная ситуация, есть CCR2116-12G-4S+, был подключен к CCR1009-8G-1S несколькими GRE туннелями с IPSec шифрованием. Внезапно выключили свет. Упал 2116 по свету. Воскрес.
Теперь он не может построить IPSec. Ругается на 2ю фазу и всё тут. Перезагрузить его пока не могу.
Что можете предложить сделать?
Константин 🪬
Коллеги, странная ситуация, есть CCR2116-12G-4S+, был подключен к CCR1009-8G-1S несколькими GRE туннелями с IPSec шифрованием. Внезапно выключили свет. Упал 2116 по свету. Воскрес.
Теперь он не может построить IPSec. Ругается на 2ю фазу и всё тут. Перезагрузить его пока не могу.
Что можете предложить сделать?
ну включить выключить ipsec но я думаю вы это сделали с 2 сторон
Константин 🪬
да, политики даже пересоздал
а свет моргнул везде в здании районе ? мб проблема не у вас а у провайдера свичи слетели на дефолт