Akina

pfSense
Интерфейс WAN, который должен смотреть в Инет - VMNet8 (NAT), адрес по DHCP, либо VMNet0 (direct), статический адрес.
Интерфейс LAN - любой внутренний VMNet (например, VMNet2), статический адрес.

Cервер Metasploitable, интерфейс в этом сегменте - тот же VMNet (VMNet2), адрес статический.
Клиенты Ubuntu и Kali - тот же VMNet, адреса статические либо динамические, дефолт-шлюзом LAN-адрес pfSense. Статический маршрут в подсеть частного клиента Ubuntu через адрес Metasploitable в этом сегменте.

Второй интерфейс сервера Metasploitable - в другой внутренний VMNet (скажем, VMNet3), статический адрес из другой подсети.
Клиент Ubuntu за ним - к тому же VMNet (VMNet3), адрес статика или динамика. Дефолтным шлюзом адрес Metasploitable из этого сегмента.

Пинг, вернее, ответ на него - самая низкоприоритетная из всех задач коммутатора. Так что если он занят чем-то более важным, то просто не ответит. Бывает, что даже на пинги устройству, подключенному непосредственно к коммутатору, получают только половину ответов. Это нормально.
А другие пингуемые нагружены, видимо, меньше, или производительность у них больше - вот потерь и нет.

WITH
cte AS (
  SELECT *, COALESCE(LEAD(id) OVER (ORDER BY id),
                     MIN(id) OVER ()) next_row_id
  FROM comments
)
SELECT * 
FROM cte

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

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

FROM post
JOIN user ON user_id = {текущий пользователь} AND FIND_IN_SET(post.group_id, user.group_ids_csv)

Однако функция в связи - это прощай индексы и здравствуй фуллскан.

ID username group
1 admin 1,2,3

Дурацкая схема хранения.
Если есть связь M:N, то должна быть связующая таблица (user_id, group_id).

Разумнее использовать WHERE NOT EXIST, который скорее всего будет более эффективен:

SELECT [DISTINCT] number
FROM table t1
WHERE service NOT IN (1,2,3)
  AND NOT EXISTS (
    SELECT NULL
    FROM table t2
    WHERE t1.number = t2.number
      AND t2.service IN (1,2,3)
)

Индекс по (number, service) - весьма желателен.

Если service - целочисленное поле со значениями от единицы и более, то для даных конкретных условий можно построить и более эффективный запрос:

SELECT number
FROM test
GROUP BY number
HAVING MIN(service) > 3

Пример

CREATE FUNCTION fn_test() 
RETURNS TRIGGER
AS $fn_test$
BEGIN
    IF OLD.val1 <> NEW.val1 THEN   -- задать условие
        NEW.id := NEW.id * 10;     -- выполнить действие
    END IF;
    RETURN NEW;
END;
$fn_test$ LANGUAGE plpgsql;

CREATE TRIGGER tr_test
BEFORE UPDATE ON test
FOR EACH ROW
EXECUTE FUNCTION fn_test();

DEMO

Или так:

CREATE FUNCTION fn_test() 
RETURNS TRIGGER
AS $fn_test$
BEGIN
    NEW.id := NEW.id * 10;     -- выполнить действие
    RETURN NEW;
END;
$fn_test$ LANGUAGE plpgsql;

CREATE TRIGGER tr_test
BEFORE UPDATE ON test
FOR EACH ROW
WHEN (OLD.val1 <> NEW.val1)   -- задать условие
EXECUTE FUNCTION fn_test();

DEMO

Официальный сайт реестра российской радиоэлектронной продукции (РРПО) — https://gisp.gov.ru/documents/10546664/

Выбирай всё, что душа пожелает... ну а что именно тебе нужно - коммутатор, маршрутизатор или ещё что,- разбирайся самостоятельно.

Но это такое убожество что я толком ничерта не понимаю

Не надо путать причину и следствие. Причина - это что ты ни хрена не понимаешь. А следствие - оно тебе кажется убожеством.

отличаются ли запросы sql MSSQL от Mysql

Да. Точнее, самые простейшие базовые запросы могут выглядеть одинаково. Но не более, чуть только хоть какая-то сложность, и одинаковость заканчивается. Синтаксис различается, и весьма сильно. А кое-где даже подходы к решению задачи различаются, и код с одной СУБД на другую не адаптируется совсем - только полное переписывание.

возможно ли сменить БД без нарушения функциональности софта.

Если запросы хардкодом - крайне маловероятно. Если тексты запросов - ресурс, вероятность несколько выше. Если вся лигика находится на сервере, общение с ним выполняется исключительно обращением к представлениям и вызовом процедур, а само приложение является чистым интерфейсом - скорее всего возможно.

Делаете следующее. В контроллер, который наделён ролью DHCP-сервера, втыкаете три сетевые карты. На каждой сетевой карте настраиваете свой скоп, и подключаете его к порту коммутатора с соответствующим VLANID. Всё, рабочие станции из этого VLAN будут получать адреса только из привязанного к данному интерфейсу скопа.

PS. Не мешайте VLAN и подсети - это вещи с разных уровней. Ничто не мешает нескольким подсетям бегать внутри одного VLAN. И даже наоборот.

Пример реализации "влоб" (синтаксис MySQL).

Структура:

CREATE TABLE test ( word0 VARCHAR(255),
                    word1 VARCHAR(255),
                    word2 VARCHAR(255),
                    word3 VARCHAR(255)
);

Запрос:

WITH 
cte1 AS (
    SELECT *, ROW_NUMBER() OVER () identity
    FROM test
),
cte2 AS (
    SELECT word0 word, identity FROM cte1 UNION ALL
    SELECT word1 word, identity FROM cte1 UNION ALL
    SELECT word2 word, identity FROM cte1 UNION ALL
    SELECT word3 word, identity FROM cte1 
)
SELECT LEAST(t1.word, t2.word), GREATEST(t1.word, t2.word), COUNT(DISTINCT identity)
FROM cte2 t1
JOIN cte2 t2 USING( identity )
WHERE t1.word > t2.word
GROUP BY 1, 2;

DEMO fiddle

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

Для того, чтобы получить хоть сколько-нибудь вменяемое время обработки, надо, во-первых, выполнить нормализацию (преобразование, которое выполняют оба CTE) в статическую проиндексированную таблицу, во-вторых, получать данные не для всего массива сразу, а для достаточно узкого набора слов.

SELECT t1.id, COALESCE(t1.f2, t2.f2) f2, t1.f3       
FROM test t1
LEFT JOIN test t2 ON t2.id = t1.f1

Если пустые ячейки - не NULL, а пустая строка, то COALESCE(NULLIF(t1.f2, ''), t2.f2).