Общего ответа тут вряд ли получится дать. Конкретно здесь я посмотрел html-код страницы, увидел, что движок - Drupal, и нагуглил дефолтный URL для RSS у этого движка. Это сработало.
Павел, количество ядер, которые фактически будут выделены виртуалке, определяется как произведение указанных в настройках виртуалки количества ядер на количество сокетов.
Павел, зависит от того, сколько задача требует. В большинстве случаев достаточно 1-2 ядра (1 сокет, N ядер), если нужно больше, то обычно это явно указано в требованиях разворачиваемого образа виртуалки или софта, который будет в ней работать. Больше 8 ядер нужно каким-то специфическим высоконагруженным сервисам.
Я думаю, проблема в том, что когда прилетает обратный трафик от промаркированного соединения, микротик не понимает, что это соединение уже промаркировано, и переназначает метку в соответствии с правилом, которому соответствует пакет. Т.е. на исходящий трафик срабатывает то правило, которое ожидалось, на ответный - маркирующее трафик по умолчанию. Чтобы этого не было, должно быть либо условие connection-state=new на всех правилах, маркирущих соединения, либо как вариант, должно быть добавлено условие connection-mark=no-mark ко всем таким правилам. Первый вариант конечно лучше. Соединение должно маркироваться в момент его создания, а не при получении каждого относящегося к нему пакета.
У меня была мысль подобные сложные временные условия записывать как SQL-выражения, с использованием операторов сравнения и функций для работы с датой. Например, для SQLite нет необходимости подклчать реальную базу для выполнения SQL-выражений, можно создать пустую базу в памяти с помощью конструкции $pdo = new PDO('sqlite::memory:');
И дальше выполнять SQL-запросы в её контексте, которые будут проверять, попадает время в нужный диапазон или нет. https://www.sqlite.org/lang_datefunc.html
Похожий эффект может быть из-за присутствия NAT или межсетевого экрана, который пропускает трафик только в одну сторону (обратный проходит, если в таблице соединений файрвола есть GRE-туннель). Как только запись об установленном соединении самоудаляется по неактивности, восстановить работу туннеля можно только с одной стороны.
iptables + ipset
Примера, к сожалению, под рукой нет, делал на прошлой работе правила фильтрафции по десяткам тысяч ip-адресов (списки Роскомнадзора), но он без проблем гуглится.
Списки ipset можно перезагружать независимо от правил iptables
Может и для сайта на поддомене получится URL подобрать