Valentin Barbolin

Можно указать второй IP на интерфейсе и прописать маршрут, для DNS настроить nrpt policy.

Допустимо ли в принципе настраивать NAT на сервере, где установлены AD DC, DNS и DHCP?

Не допустимо даже иметь два сетевый интерфейса на контроллере домена, особенно если один из интерфейсов будет не доступен в пределах локальной сети. Просто вдумайся что ты сделал, у тебя тачка введенная в домен будет делать DNS запрос на доменные ресурсы и в ответ получать внешний адрес (да, не всегда внешний, но ты не может это контролировать) который ей не доступен или не будет отвечать, что в свою очередь приведет замедление и лагам на всех ПК в домене.

Если это железный сервер, поставь на него ProxMox и уже на нем сделай вирталками AD и маршрутизатор. Но как показывает практика, маршрутизатор лушче железный.

Что бы при адресацию по всем доменам ru трафик шёл вне X шлюзу, иначе по Y шлюзу.

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

Что-то типа такого
/etc/systemd/network/99-static-dns.network:

[Match]
Name=eth0 #имя твоего интерфейса

[Network]
DNS=8.8.8.8 #  если DNS по DHCP то, можно убрать этот параметр.
Domains=~.ru

ip neighbor
Нажимаем Discovery Setting и настраиваем на свой вкус.

При такой схеме на WAN интерфейса используем Gateway, а на LAN убираем Gateway и пишем нужные маршруты.

Зачем тебе это

routes:
             -   to: default
             via: 89.218.165.97

Почему не просто Gateway: 89.218.165.97 ?

Покажи что там в ip ro при таких настройках.

167.ХХ.ХХ.X

скорее всего ноутбук самоназначает себе IP т.к. не видит DHCP сервер.

Далее от Mikrotika идет кабель к умному коммутатору D-Link DGS-1210-52/ME, в котором я физическому порту присвоил ID 1005.

Ты на микротик отдает тегированный трафик, значит и принимать надо тегированный. Соответственно на D-link порт должен быть в режиме транк, а порты куда подключены клиенты в access в 1005 vlan. Или отдавай ассess на микротике. Если на этом порту микротика только этот D-link то тебе и vlan не нужен, просто выдерни этот порт из бриджа и назнач ему IP и настрой DHCP.

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.

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.

После поднятия VPN на Cisco Any Connect на VPS появляется сетевой интерфейс с IP ?

Все достаточно стандартно
1. На HOST PC весь трафик завернуть в тунель или только сети которые надо.
Так же надо что-то решить с DNS 20.20.20.20, тут
- либо все запросы на него заворачивать
- либо настроить политику NRPT на windows
- либо использовать VPN (openVPN, ZeroTier) которые умеет разделять DNS запросы на основании домена
- либо поднять на VPS сервер DNS типа unbound и на нем настроить правила пересылки, соответственно все свои запросы заворачивать на этот DNS

2. На VPS включить форвард и маскарад.
echo 1 > /proc/sys/net/ipv4/ip_forward # включаем форвард
iptables -I FORWARD -i wg0 -j ACCEPT # разрешаем все что приходит c wg0 интерфейс
iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE # натим все что приходит с wg0 и уходит в тунель Cisco, тут вместо tun0 yказать интерфейс который светить в системе VPS после поднятия туннеля на Cisco.

никогда не имел дела с выделенными серверами,

Тебе точно выделеный железный сервер дают, а не виртуальный. Потому как с виртуальным у тебя получиться вложенная виртуализация. Windows VM уже не запустяться.

Тут два+1 варианта
1) Белый IP закрепить за ProxMox, на нем настроить NAT и форвард портов. Получиться так же как у тебя сейчас.
2) Поднять на ProxMox одну ВМ которая будет в роли маршрутизатора и ей отдать белый IP и NAT, тут придется поморочиться с маршрутами, что бы зайти на туже WEB ProxMox. Так же геморой с доступом, пока эта ВМ выключена у тебя нет доступа к ProxMox, разве что хостер предоставляет KVM.

+1 я бы перевел все на докер если нет необходимости в windows VM.

Все правильно написал Виктор, это в первую очередь коммутатор, он без проблем справляется с L3 уровнем, но NAT это не его задача про VPN я вообще молчу.

Да, на нем есть такой функционал как NAT, но этого хватит от силы для нормальной работы 5-10 пользователей, но точно не 70.

Даже mikrotik hap ac2 справиться лучше чем CRS317.
Я бы посоветовал 4011 или хотябы ax2.

Строй по класике три уровня, L3 и NAT должны делать разные устройства
- роутер
- l3 коммутатор
- l2 коммутатор

Берешь, один коммутатор, возлогаешь на него роль l3, все остальные L2. На l3 настраиваешь маршрутизацию между сетями и firewall по надобности, на нем делаешь маршрут defaul gw на роутер. На роутере настраиваешь правила для мутивана.

192.168.0.0/16 не использую эту подсеть для локальной сети, бери адреса из 10.0.0.0/8

Mikrotik с этим плохо справиться, на сайте так же подгружаются другие ресурсы которые так же надо разрешать.
Для этого нужен прокси, например kerio или squid.

Есть микротики с поддержкой docker в котором можно запустить squid, возможно это твой случай.
https://habr.com/ru/company/selectel/blog/694436/

Чисто технически может возникнуть конфлик IP адресов т.к. в стеке у них один адрес, так же STP брыкнет.

В теории надо выдернуть один коммутатор из стека, подцепиться консолью, поменять IP, приоритет STP и hostname (что бы discovery не ругался). Но ты все равно не сможешь собрать стек без полной перезагрузки, так же потребуется засинхронить конфиг с мастера, когда оба будут в новой локации.

У тебя один стек? Если нет, возможно получить переносить по одному стеку целиком.