Так и пытаюсь вникать, но не имея базы сложно понять о чем речь

так стройте базу, читая/слушая ссна (и делая лабы)

у многих фундамент из песка и глины, ничего, латаем по пути )

?

Да не в сойдёт дело

а в том, что когда не понятно чего сделал, не ясно что сделал не так, что бы исправить

?

а в том, что когда не понятно чего сделал, не ясно что сделал не так, что бы исправить

Пройди ccna - теоретическую базу там дают наилучшим образом

прослушать icnd для начала, если ещё нет. Потом уже к ccna

На русском всё?

На русском всё?

ну разумеется

более того, даже первое открытые источники

Ну мало ли? есть такие, кто не гнушаются и англокурсами

Ну мало ли? есть такие, кто не гнушаются и англокурсами

https://www.youtube.com/watch?v=-aq-Vy9wEQY

Благодарю всех, накидали кучу всего, буду изучать?

надеюсь придет осознание

Благодарю всех, накидали кучу всего, буду изучать?

всегда совмещай теорию с лабами в эмуляторе или на железках

Да, именно этого и не хватает

без эмуляторов тяжко

на рабочей сети не очень приятно эксперементировать

Кинул в ЛС готовую ВМ с Евой и тиками на борту

Жаль что не под гипервизор

Жаль что не под гипервизор

сысле? Виртуалка же.

ну так ставить вмварь над же

всем привет. по поводу вчерашнего моего вопроса про l2tp ipsec и маркировку соединений для loadbalancing на два инет канала. нашел вот такую тему: https://forum.mikrotik.com/viewtopic.php?t=58233 а особенно вот это: One thing I stumbled across is that if you want to use IPSec, a route for the IPSec packet must exist that HAS NO ROUTING-MARK, even if you want to policy-route it later anyway. So in this example if you disbale the default route on eth1, it will stop working although technically it still COULD work. The routing-decisions done before IPSec encryption already seem to take into account that the packet will be encrypted, and look for a possible route for the encrypted packet. But they do not take routes with routing marks into account. I wish it would be implemented differently, but then again I may not see the bigger picture here и точно, если оставить дефаулт роут для немаркированого трафика, то все работает. кто что скажет?

а гипервизор стоит

ну так ставить вмварь над же

запусти под чем хочешь, если стартанёт - ок будет

?

попробую

а гипервизор стоит

не гипервизар, а Hyper-V. Они как бы все гипервизары. Это класс ПО, а не название конкретного продукта

Ну я имел ввиду его

Сомневаюсь что он пожхватит виртуалку от вмвари

всем привет. по поводу вчерашнего моего вопроса про l2tp ipsec и маркировку соединений для loadbalancing на два инет канала. нашел вот такую тему: https://forum.mikrotik.com/viewtopic.php?t=58233 а особенно вот это: One thing I stumbled across is that if you want to use IPSec, a route for the IPSec packet must exist that HAS NO ROUTING-MARK, even if you want to policy-route it later anyway. So in this example if you disbale the default route on eth1, it will stop working although technically it still COULD work. The routing-decisions done before IPSec encryption already seem to take into account that the packet will be encrypted, and look for a possible route for the encrypted packet. But they do not take routes with routing marks into account. I wish it would be implemented differently, but then again I may not see the bigger picture here и точно, если оставить дефаулт роут для немаркированого трафика, то все работает. кто что скажет?

приходите на MUG как раз буду расказывать об этом

Ну я имел ввиду его

ну как бы, это тоже самое что сказать: "Жаль, не под операционную систему программа" а я спрашиваю в ответ "всмысле не под операционку?" А ты отвечаешь "ну не под винду я имел в виду"

?) ок

приходите на MUG как раз буду расказывать об этом

именно про этот кейс?

именно про этот кейс?

Именно почему нужен маршрут без маркировки

Втыкай в флоу.

кирилл, есть еще картинки из той книжки ? )

всем привет. по поводу вчерашнего моего вопроса про l2tp ipsec и маркировку соединений для loadbalancing на два инет канала. нашел вот такую тему: https://forum.mikrotik.com/viewtopic.php?t=58233 а особенно вот это: One thing I stumbled across is that if you want to use IPSec, a route for the IPSec packet must exist that HAS NO ROUTING-MARK, even if you want to policy-route it later anyway. So in this example if you disbale the default route on eth1, it will stop working although technically it still COULD work. The routing-decisions done before IPSec encryption already seem to take into account that the packet will be encrypted, and look for a possible route for the encrypted packet. But they do not take routes with routing marks into account. I wish it would be implemented differently, but then again I may not see the bigger picture here и точно, если оставить дефаулт роут для немаркированого трафика, то все работает. кто что скажет?

На схеме выше, local process - это процессы ipsec в том числе.

Кинул в ЛС готовую ВМ с Евой и тиками на борту

Можно и мне.

Можно и мне.

забирай

кирилл, есть еще картинки из той книжки ? )

Да, mcna материалы есть, но там нет ничего чего бы не было на Вики.

я в курсе откуда эта картинка ) можете поделиться ? )

На схеме выше, local process - это процессы ipsec в том числе.

а вчера так никто и не сазал что нужно бы включить дефроут без маркировки

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

посмотрите ppp profile limits idle timeout

забирай

и мне =)

кинуто

благодарочка

посмотрите ppp profile limits idle timeout

там по умолчанию - не настроено

поставил 30 мин. посмотрим

@moneron , можно вас в личку про курсы поспрашивать?

товарищи есть еще вопрос по маркировке. чтобы не маркировались соединения, которые идут между локальными сетями. в правиле маркировке указал dst-address-type=!local но все равно весь трафик впн-клиента в локальную сеть офиса маркируется и отправляется через nat в инет.. что не так сделал? вот полное правило: add action=mark-routing chain=prerouting dst-address-type=!local new-routing-mark=wan2-rout-mark passthrough=no src-address=192.168.55.0/24

192.168.55.0/24 это впн-клиенты

tracert 192.168.255.221 Трассировка маршрута к SRV21 [192.168.255.221] с максимальным числом прыжков 30: 1 82 ms 82 ms 82 ms 192.168.55.201 2 83 ms 82 ms 82 ms 192.168.77.1 3 *

192.168.77.1 это шлюз wan2 ..

зачем использовать 255 в адресе?

зачем использовать 255 в адресе?

потому что можно

почему бы и нет..

это /24

почему бы и нет..

вот жа если это не 24

я спросил зачем) а не почему)

если сеть /16 можно

ну раз так то всё сразу понятно.

ERROR: S client not available

0 тоже используете, наверное?

я спросил зачем) а не почему)

а вот ЗАЧЕМ. Это знаешь, это от лукавого вопрос =)

0 тоже используете, наверное?

вот щас был слишком тонкий юмор, я не смог.

Наверно дст-тайп !локал это локал в рамках интерфейса

Наверно дст-тайп !локал это локал в рамках интерфейса

но написано так: local - if dst-address is assigned to one of router's interfaces

0 тоже используете, наверное?

почему бы и нет?

и 0 и 255 используем

циферки стерпят всё

а в чем страх использования 192.168.255.0/24 ?

типа по краю ходите? )))

а в чем страх использования 192.168.255.0/24 ?

"боязнь крайних состояний"

угу

а 192.168.0.0/24 не боятся

хотя это тоже край

а 192.168.0.0/24 не боятся

192.168.0.255/23 чотче

под хост, норм

часто жи спрашивают на собеседованиях

часто жи спрашивают на собеседованиях

ответов, правда не часто услышишь.

не, ну 255 как то неаккуратненько просто

ну, тревога какая то, что дальше ничего нет

такое состояние, ну, беспокойное штали

а 0 тоже, такое типа, что до 0 ничего нет

страх, вот истинный мотив

чувство внутреннего дискомфорта )

не аккуратненько как то )

не аккуратненько как то )

как в анекдоте про яички

алсег в теме )

но бывает кстати что появляются в плане адресации подсеточки 256 и даже 267

267!

проблема ipv4 рещена!

это вселенная не выдерживает напряжения в этих местах

проблема ipv4 рещена!

вот! а то кто придумал еще эти 255 и всё. продолжить надо