Valentin Barbolin

MAC адрес работает в L2 сегменте сети. Свичи это L2 устройства, RTA это L3 устройство к которому подключены две сети L2. Соответственно между ПК-Свич-RTA это одна L2 сеть, RTA -Свич-Сервер это вторая L2 сеть. Что бы пройти L3 устройство в пакете должен произойти подмена MAC адреса. Что бы RTA понял что пакет предназначен ему, в пакете от ПК в поле destination должен стоять его мак. Если в пакете будет стоять МАК сервера, то пакет дойдет до RTA и будет отброшен, до сервера пакет вообще не дойдет т.к. ARP не может проходить в другую L2 сеть, а RTA не перебрасывает ARP пакеты между L2 сетями.

В пакете есть IP и MAC.
MAC подменяется при переходе через L3 устройства, IP и MAC одновременно подменяются при переходе через NAT.

Есть такой механизм DHCP-Relay который должен быть настроен на L3 маршрутизаторе данной сети, как раз он и пересылает запросы из разных vlan на DHCP сервер, так же добавляет в него подсеть на основании который DHCP сервер понимает из какого пула надо выделить IP.

Если не использовать DHCP-Relay, то DHCP сервер должен иметь сетевой интерфейс в каждой из сетей.

VLAN это не только возможно разделить большие сети.
В обычной жизни 30+15+15=60 устройств это не много для офиса и администраторы редко заморачиваются vlan, т.к. не всегда есть возможно купить коммутаторы которые умеют работать с VLAN.

Но для курсовой можно выделить такие плюсы использования vlan
1. Безопасность. Хорошим тоном является выносить такие устройства как камер, телефоны, принтера, сервера в отдельную сеть (vlan) и настраивать ограниченный доступ. Что позволяет оградить потенциально любопытных пользователей, злоумышленников, зараженные ПК от возможности скомпрометировать сеть предприятия.
2. Qos. Разделение на vlan позволяет настроить приоритет трафика в этом vlan, что может быть актуально для VoIP трафика.
3. Сервера. Это так же связано с безопасность, часто сервера имеют публикацию, что потенциально открывает возможность взлома данного сервера из мира. Для повышения безопасности, сервера с публикацией необходимо размещать в отдельном VLAN так называемая зона DMZ, у которой нет или есть ограниченный доступ в локальную сеть. Так же использование одной сети открывает возможности для использования атак по типу MITM.
4. Диагностика. Гораздо проще найти виновника пакостей когда сеть сегментирована на VLAN. Например, если сервера и ПК будет в одной сети, то какакой-то пользователь назначит на свой ПК IP аналогичный серверу и все устройства в сети будут иметь проблемы с доступом к этому серверу.
5. Так же WIFI стоит разделять минимум на два VLAN, гостевой и рабочий. Гостевой соответственно не должен иметь доступа к внутренней сети. Рабочий должен иметь ограниченный доступ т.к. в него может подключаться устройства BYOD которые покидают компанию и могут потенциально нести(принести) угрозу.
6. VPN. Разделение на VLAN упрощает построение VPN сетей при маштабировании компании или предоставлении сотрудникам доступа из вне посредствам VPN.

Наверное самым оптимальный выбором будет VMware workstation, да она платная, но ключи можно найти.
Из плюсов
- скорость, да hyper-v не будет уступать как нативная платформа, но у VMware больше опыта на этом рынке
- поддержка образов, можно скачать уже готовый vmdk или OVA и в 2 нажатия развернуть.
- интеграция, можно легко подключить к vSphere и тягать машинки
- огромное сообщество где легко найти ответ на любой вопрос

Пробовал я Hyper-V но вернулся на VMware. На Hyper-V какие-то простые вещи надо делать через анус, открывать powershell, вводить неизвестные команды, самое главное тебе этот скил врятли еще где-то пригодится.

WSL - сырой, обязательно найдется софт который не будет работать.
VirtualBox - медленный и не стабильный, на длинный дистанция (когда машинка работает несколько дней-недель) течет по памяти.

Если что-то по серьезнее, то берем отдельный ПК и ставим
VMware ESXi, не все железо поддерживается, но это самый близкий вариант к боевым условиям
ProxMox

> хотелось бы сделать так, что бы нельзя было подключаться по RDP к коллегам из локальной сети.
Геморно конечно.

Вижу три варианта
1) По проще, можно создать две группы ТopRDP, UserRDP. Первой группе разрешить везде заходить, второй только на определенные ПК.

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

3) Мой любимый, написать костыль. При логоне выполнять скрипт который будет добавлять пользователя в группу удаленного рабочего стола, соответственно пользователь сможет подключиться только к тому ПК где заходил локально.

Два варианта
- bridge
- Неужели придётся каждый внешний ip прописывать в интерфейсе а потом в iptables прописывать правило?)

Второй вариант более правильный с точки зрения безопасности, т.к. при использовании bridge белый адрес будет назначаться непосредственно на ПК, соответственно ПК станет уязвим из интернета.

Тебе необходимо
- поднять VPN между 88.77.66.55 и 192.168.1.10
- пусть адреса внутри VPN будут 10.200.200.1 и 10.200.200.2
- настроить проброс с адреса 88.77.66.55 на 10.200.200.2

В качестве VPN рекомендую Wireguard, самый просто в настройке.

Ниже примерный минимального конфига, не забываем про безопасность (закрыть ненужные порты). Не забудь поменять $WAN$ на свой интерфейс. Важно, что бы при пробросе портов весь трафик от 192.168.1.10 ходил через VPN или использовать на 88.77.66.55 nginx-proxy.

Ходи сюды.

Спрятать RDP сервер... а как?

Что тут сложного? Достаточно 2х правил в iptables. Минус конечно есть - не будет видно IP клиента, на терминальном сервере все будут сидеть с IP VPS сервера (WAN_IP).

RDP_IP='192.43.76.78'
WAN_IP='54.23.45.43'
WAN_INTERFACE=ens33
SRC_PORT_FORWARD=3389
DST_PORT_FORWARD=3389
echo 1 > /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A PREROUTING -i $WAN_INTERFACE -p tcp  --dport $SRC_PORT_FORWARD -j DNAT --to-destination $RDP_IP
sudo iptables -t nat -A POSTROUTING -d $RDP_IP -p tcp  --dport $DST_PORT_FORWARD -j SNAT --to-source $WAN_IP

Почему бы не использовать 443 порт и настроить на web сервере с сайтом проксирование (nginx).

<audio >
  <source src="https://example.com/audio" >
</audio>

location ^~ /audio {
        proxy_pass https://192.168.0.100:8000/audio;
        proxy_read_timeout 3600;
        proxy_redirect off;
        proxy_request_buffering off;
        proxy_pass_header   Server;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        send_timeout 3600;
}

А в чем проблема поднять 2 тоннеля?

И потом настроить PolicyBaceRouting
https://wiki.mikrotik.com/wiki/Policy_Base_Routing