Он не сильно ресурсоемкий. Оборудование надо выбирать под задачу. Если вы собираетесь сотрудников на софтфоны посадить, тогда из оборудования только сервер, и гарнитуры. А так все как обычно надо: ip-телефоны, sip-линии, возможно запись голосового меню диктором.
Доработки обычно это как раз настройка логики, кому переходит звонок, голосовое меню, автоответчики и т.п.
Попробуйте подключиться по VPN, затем посмотрите, что у вас за сервера прописаны в /etc/resolv.conf. Если не те, что в офисе, попробуйте прописать руками в этот файл офисные вместо дефолтных провайдера. И проверьте резолвятся ли ваши доменные адреса сети офиса.
Также попробуйте выполнить команду dig нужный_хост.company.local @ip_address_dns_сервера_вашего_офиса.
Последние коментарии @edinorog не видел, пока писал предыдущее сообщение. Возможен еще вариант когда прописаны DNS-сервера верные, но на них нет разрешения отвечать на запросы из подсети vpn-клиентов. проверятеся это как уже было предложено выше командой nslookup или dig.
Предположим есть сеть офиса 192.168.1.0/24. В ней поднят локальный DNS (192.168.1.1) и все клиенты в офисе используют его как основной. На этом DNS-сервере подняты зоны, которых нет "в миру", в том числе и company.local. То-есть они прекрасно резолвятся внутри офиса, так как в качестве основного DNS прописан наш локальный сервер.
Теперь мы настраиваем vpn, который предоставляет доступ в сеть офиса. У клиентов ip из другой подсети, например стандартно 10.8.0.0/24 и пушим мы всего один маршрут на клиенты, в нашу подсеть офиса 192.168.1.0/24, дефолтный маршрут остается как был, мы же не хотим чтобы весь киентский трафик пошел через канал офиса. Если теперь в настройках клиента не указать правильные DNS (/etc/resolv.conf), то о локальных зонах офиса он знать не будет (в том числе и company.local ), при этом остальные зоны будут резолвится DNS-ми провайдера как обычно.
С чего вы взяли что все маршруты ушли на vpn?
Почему company.local заглушка, а не реальная зона на локальном DNS-сервере в сети компании, о котором клиент подключенный по vpn просто не знает?
Первый вариант, по сути такой же как я вам предложил.
Второй более красивый. Не знаю правда отработает ли $scheme, надо пробовать. Но в документации нашел обработку подобной ситуации через return: nginx.org/en/docs/http/converting_rewrite_rules.html
А если попробовать передать в try_files в конце именнованый location?
location / {
access_log /var/log/nginx/access-01.log main;
try_files $uri $uri/ @rewriter;
expires 72h;
}
Чтобы увидеть, попадает запрос в нужный location или нет, добавьте в нужный location запись в access_log. Можно даже на время дебага для каждого location прописать свой access_log.
