hint000

(с учётом уточнений в комментариях)
Это совершенно не зависит от использования NGINX, ASP.NET и т.п.
1. поднять VPNC (инструкцию нагуглить);
2. прописать маршрут к серверу (где лежат данные) через настроенный VPN.
Как бы всё.
Первоначальный вопрос неправильно сформулирован. Не часть пакетов\запросов через VPN, а доступ к конкретному серверу через VPN. Задача типовая и простая, вот только цисковский VPN - дикая экзотика.

У каждого конкретного сайта могут быть какие-то свои особенности, про которые никто ни в одном руководстве не напишет, и здесь заранее никто не угадает. Поэтому гарантированной 100%-победной последовательности действий не существует. Поэтому админа с головой пока не могут заменить скрипты. Вам нужно переносить так, чтобы вы могли протестировать сайт на новом месте до того, как отрубите на старом. В этом плане совершенно верно вы ставите работу с DNS последним пунктом. Но между 4 и 5 должно быть тестирование.
Если у вас домен zxcvbnm.tld, то можете сперва назначить новому серверу test.zxcvbnm.tld, добавить это имя в конфиг nginx и тестировать, заходя по этому имени. Если что-то не работает, то обнаруживаете те самые нюансы, про которые не пишут в руководствах, но которые есть именно у вас. Будем считать, что тестирование прошло удачно.
5.1. добавляете в DNS новый адрес для zxcvbnm.tld. Старый пока не убираете. Т.е. zxcvbnm.tld будет резолвиться в два адреса.
5.2. Идёте пить чай,

пока записи в DNS не обновятся.

5.3. Смотрите логи на новом сервере, убеждаетесь, что пара юзеров (или пара тысяч...) уже попали на новый сервер, и явных ошибок не заметно (если посыпались ошибки, то откатываете изменения DNS и разбираетесь с ошибками).
5.4. Всё нормально - убираете из DNS адрес старого сервера.
5.5. Если срочности нет, то лучше оставить в этом состоянии хотя бы на несколько часов а то и до следующего дня. Обязательно найдутся юзеры, у которых DNS крепко закэшировался, и обновится позже положенного срока.
5.5. Смотрите логи на старом сервере, убеждаетесь, что поток юзеров прекратился, выключаете там сайт.

P.S. Это всё годится в случае, если БД не содержит чего-то, что всегда должно быть в актуальном состоянии (я про всякие интернет-магазины, соц.сети и т.п.), там перенос БД был бы самым замороченным пунктом.

стоит ли перед этим закрывать сайт на техническое обслуживание?

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

Предположу, что gnome-system-monitor показывает сумму used + buffers + cache, а htop у вас показывает только used. Настройте htop как у меня (в части Mem) - будет интереснее. :)

Upd. xolst9,

но никак не кеш (+cache)

пожалуй, вы правы, зачеркнул в ответе.

user@localhost:/sbin$ ls -l poweroff
lrwxrwxrwx 1 root root 14 Sep  5 18:01 poweroff -> /bin/systemctl

user@localhost:/sbin$ ls -l shutdown 
lrwxrwxrwx 1 root root 14 Sep  5 18:01 shutdown -> /bin/systemctl

Почти никакой разницы, обе команды - всего лишь симлинки на один и тот же файл. Но shutdown позволяет задать время, а в poweroff (согласно man'у) такой параметр не предусмотрен.

#!/bin/bash
DOMAIN="roga-i-kopyta.com"
USER="V.Pupkin"
PASS="Pa$$w0rd"
HOST="192.168.77.66"
net rpc shutdown -f -U "$DOMAIN"'\'"$USER"'%'"$PASS" -t 2 -I "$HOST"

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

Это называется доступом по белому списку. Ниже пример, как можно это сделать. Только у меня это не в формате исполняемого шелл-скрипта, а в формате конфига, загружаемого командой iptables-restore.

# example

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# WhiteList (разрешенные внешние клиенты)
-N Wht
-A Wht -s 1.2.3.4      -j RETURN
-A Wht -s 2.3.4.5      -j RETURN
# разрешенная подсеть
-A Wht -s 3.4.5.0/24 -j RETURN
# ...

# go to hell
-A Wht  -j DNAT --to-destination 192.168.99.99

-A PREROUTING ! -s 192.168.0.0/16 -p tcp --dport 22 -j Wht
-A PREROUTING ! -s 192.168.0.0/16 -p tcp --dport 22 -j ACCEPT

-A PREROUTING ! -s 192.168.0.0/16 -p tcp --dport 80 -j Wht
-A PREROUTING ! -s 192.168.0.0/16 -p tcp --dport 80 -j DNAT --to-destination 192.168.42.18:80

-A PREROUTING ! -s 192.168.0.0/16 -p tcp --dport 8080 -j Wht
-A PREROUTING ! -s 192.168.0.0/16 -p tcp --dport 8080 -j DNAT --to-destination 192.168.42.19:80

-A PREROUTING -s 192.168.0.0/16 -j ACCEPT

COMMIT

поясню насчёт 192.168.99.99 - этот адрес я выбрал (произвольно, можно любой другой) в качестве "чёрной дыры", куда можно невозбранно отправлять ненужные пакеты. Прописана "дыра" командой ip route add blackhole 192.168.99.99

Проверьте, что после COMMIT перевод строки есть.

добавить
-A FORWARD -d 192.168.42.10 -p tcp -m tcp --dport 3389 -j ACCEPT
в любом месте выше этой строки:
-A FORWARD -j DROP
обратите внимание, что в форварде порт уже проброшенный, т.е. 3389, а не 55658