Алексей

В таких случаях (если Windows уже стоит) уменьшают один из разделов, дабы выделить место под установку Linux. Это свободное место будет обнаружено установщиком Linux, как и факт того, что на ПК уже установлен Windows. В таком случае относительно безопасно, этот же установщик поставит Linux рядом, а загрузчик Windows добавит одним из пунктов в Grub.
Всё есть на сайте Debian.

На практике встречалась проблема "нет интернета". Это как видят пользователи. Позвали разобраться, но до этого люди купили Mikrotik hEXs + CRS326 (до того у них стояла гирлянда неуправляемых свитчей). Так вот, после настройки всего этого хозяйства, первым делом разбили сеть на 3 vlan, разделив отделы и ограничив скорости при помощи Queues. Достаточно быстро выявился виновник - забытый в закрытой комнате D-Link DSL-500T на котором был DHCP сервер смотрящий в один из vlan.
Часто помогает в поиске (если это возможно в ваших условиях) - отключение разных сегментов сети, чтобы понимать откуда источник проблемы. Но обычно это очень легко, когда все коммутаторы управляемы, когда нет - физическое отключение аплинка на некую подсеть.
А вообще же, коллеги всё уже расписали выше.

Важно понимать, что ВМ с астериском находится на гипервизоре и вынуждена делить ресурсы с другими ВМ на сервере. Предполагаю, что что-то изменилось, что возможно ВМ не достаётся процессорного времени или достаётся с задержкой. А тут каждая миллисекунда на счетах.
Не знаю, я бы посмотрел общую ситуацию на гипервизоре по уровням загрузок.

Выше уже написали, что нужно помимо правила проброса портов, в цепочке forward нужно прописать, чтобы система пропускала трафик, который удовлетворит условию:
- входящий адрес/порт на внешнем интерфейсе
- назначение = ваш сервер
Советую в каждое правило временно (!) добавить логирование (галочка log в Winbox, или параметры log и log-prefix в консоли) и добавить префикс, чтобы можно было увидеть трафик с журнале и отследить отработку правила. Также можно сбросить счётчики трафика, чтобы увидеть работу конкретных правил по наращиванию этого счётчика.

Пытаюсь изложить, как я это понял:
1. некое устройство снаружи пытается достучаться до какого-то устройства внутри сети за микротиком;
2. требуется предоставить доступ к этому устройству с внешнего устройства с белым IP?
3. требуется ограничить доступ внутреннего устройства к некоему внешнему по его белому IP?
Как и обычно, пункт 1 решается правилом DSTNAT в цепочке NAT. Пункт 2 решается в цепочке forward, где указать кому куда. Пункт 3 аналогично пункту 2.

Всё подробно расписал коллега rainhog. В своё время ещё на Debian сделал балансировку по типу трафика. Т.е например, почтовый трафик, телефонию я направил (опираясь на диапазоны портов) на одного поставщика, сайты - на другого. Всё отлично. Это же повторил на RB3011Ui. Практика показала, что распределение по количеству пакетов, в зависимости от "толщины" канала, как также указал коллега, не всегда хорошо и приводит к странному результату. Сложно рекомендовать.

Вот как оказывается! Мне тут 40 лет скоро, а тут уже в 35 паника. )) Однако, ситуация у меня чем-то сходная. Также на перепутье в плане "куда дальше" и "чем заниматься". Но подбадриваю себя, стараюсь не унывать.
Что касается "возьмут старика", то вот мне люди на 5 лет младше, ну никак стариками не кажутся )) Если речь о эйджизме, то да, весьма вероятно, что где-то в компаниях он неявно, но присутствует. Тем не менее, с годами приходит опыт, а это ценится куда больше.

Всё странно в этой ситуации, но железо есть железо...
Сама задумка по удалённой перенастройке безусловно верная, но по себе знаю, что увы бывают случаи, когда требуется физическое присутствие (или присутствие помощника, который в телефонном режиме сможет сделать некие манипуляции).
Прописывание маршрута в этой ситуации на mikrotik ситуацию не спасает, т.к устройство на котором собственно и слетел IP ничего не знает про шлюз, которым в вашем случае выступает этот mikrotik. Следовательно маршрут на 10.90.90.90 есть, но в обратку по сути ничего нет, т.к все пакеты будут ходить в этой подсети но не попадут в подсеть 192.168.10.0/24. ((
Таким образом, на интерфейс, смотрящий в сторону этих коммутаторов, нужно повесить ещё один IP адрес той же подсети (т.е 10.90.90.95 например). В этом случае устройства будут друг друга видеть, поскольку находятся уже в одной подсети.
Ну а вообще конечно надо разобраться в причинах потери интерфейсами правильных IP адресов...

Как сказали выше, ПК вводимый в домен и контроллер домена должны видеть друг друга. Должна быть корректна SRV запись для контроллера, т.к запросом от ПК контроллер и будет искаться по этой записи. Безусловно в пределах одной сети с этим проблем не возникает. Эти условия должны выполняться и в вашем случае, иначе не сработает.

Советовать что-либо конкретное тут сложно, поскольку скажем Cisco и Mikrotik это немного разные "весовые категории". Тем не менее, во многих местах (а это в том числе зависит и от бюджета) их ниши пересекаются. На своём предприятии решили не упираться в одного вендора и не переплачивать и имеем фактически только нескольких: D-Link, Mikrotik (CRS, RB серии, hAP и т.д.), SNR. Основным коммутатором был как Mikrotik CRS326 так и D-Link DGS-1210 (ротация на момент сбоя D-Link), что для наших задач хватило полностью. Сеть также разделена виланами, а вся маршрутизация на RB3011. Нет отказоустойчивости, но нет и большого запроса на неё в нашем конкретном случае.