Valentin Barbolin

Надо воткнуть что-то между ноутом и интернетом.

Возьми mikrotik ac2.
Почему? Mikrotik умеет 99% VPN протоколав. Это максимально гибкое и доступное по цене устройство.
- у него два радиомодуля (2.4 и 5)
- есть USB порт в который можно включить USB модем.
- есть 5 портов Gbit/s

Получается две схемы.
1. Mikrotik модулем 2.4 вешает на wifi в гостиннице, поднимает VPN, через 5-ку раздает интернет.
2. Mikrotik через USB модем получает через wifi раздает.

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.

Есть такой механизм 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.

После поднятия 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.

Что подразумевается под доступом? Доступ из мира? Поставь на оба ПК VPN zerotier и подключайся откуда хочешь.

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

Тебе точно выделеный железный сервер дают, а не виртуальный. Потому как с виртуальным у тебя получиться вложенная виртуализация. 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/

Такие решения называются SD-WAN.

Если грубо описать его работу, то выглядит это так.
Есть роутер с поддержкой SD-WAN, есть сервер в облаке с хорошим интернет каналом. К роутеру подключено несколько интернет каналов, не важно каким образом, это так же могу быть модемы USB. Роутер строить через каждый интернет канала туннель в облаков и балансирует трафик между этими туннелями, так же роутер контролирует качество, стабильной работы каждого такого туннеля. Сервер собирает трафик со всех туннелей и уже пуляет в интернет.

Да, при таком подходе можно суммировать трафик со всех интернет каналов, ограничение будет на стороне сервера, сколько он пропустит через себя.

Как пример.
https://5gstore.co.uk/sd-wan-pro-bonded-4g-5g-internet/

https://mobileproxy.space/en/pages/ustanovka-3prox...

> 80 порт по протоколу http перенаправить на нестандартный порт https?
Почему бы не переложить эту роль на плечи прокси (nginx). Ставим на входе nginx, он может делать редирект с 80 на 443 и разделить трафик на одном порту на основании домена.
webmail.domain.ru - все на почтовик
cms.domain.ru - на сms

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

Проблема 444 в том, что все браузеры будут ругать на недоверие к сертификату.