hint000

Почти правильно.

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.70 --dport 80 -j DNAT --to 192.168.1.45:31280

iptables -t nat -A OUTPUT -p tcp -d 192.168.1.70 --dport 80 -j DNAT --to 192.168.1.45:31280

hotspot костылю

мой случай предполагает использование этого в пределах одной сети

В этих условиях достаточно на web-сервере выполнить системную команду arp и отфильтровать вывод по известному ip-адресу клиента. Суть в том, что операционная система хранит таблицу соответствия mac- и ip-адресов (arp-таблицу). В ней хранятся адреса хостов, с которыми был какой-то обмен информацией по сети. Команда arp просто выведет таблицу, arp -n чтобы не пытаться резолвить адреса в имена хостов.

Если скомпрометирован хост, то можно считать, что скомпрометирован и гость.

1) Сеть гостя можно защитить с помощью VPN, но с кучей оговорок, т.е. в общем случае - нельзя.

2) Клавиатурный ввод нельзя защитить, если клавиатура подключена к хосту. Генератор мусора будет запущен где? На хосте? Но что мешает хосту игнорировать мусор, который он же сам и генерирует? Ничего не мешает. Есть вариант с экранной клавиатурой на госте. Но что мешает хосту перехватывать события мыши? Есть вариант с экранной клавиатурой, на которой буквы перемешаны или даже хаотически прыгают. Это жутко затруднит ввод человеку, но что мешает хосту перехватывать картинку с гостя? Ничего. Короче, клавиатура, мышь и экран гостя беззащитны перед хостом.

3) Иметь дополнительный комп, с которого можно подключиться к гостю по RDP (+VPN), чтобы не использовать клавиатуру, мышь и экран хоста. Тут можно было вернуться к пункту 1)... Но если есть дополнительный чистый (не скомпрометированный) комп, то вся затея теряет смысл, просто используйте этот комп для работы с чувствительной информацией.

Короче: если хотите работать с непроверенными исполняемыми файлами, то эта работа должна быть на госте, а не на хосте. И даже в этом случае остаются такие вещи, как Meltdown и Spectre и ещё куча найденных после них. Эксплуатировать эти уязвимости очень сложно, но теоретически они позволяют пробиться из гостя, перехватить хостовую информацию. А еще уязвимость Rowhammer (и родственные ей), которая позволяет на физическом уровне менять данные в оперативной памяти... А ещё... Ну вы поняли.

8,00 ГБ (6,15 ГБ доступно)

часть оперативки ушла на интегрированную графику.
75% - это 75% от 6,15 ГБ

https://ru.wikipedia.org/wiki/Рациональное_выражение
Второе и третье выражения - рациональные, первое и четвёртое - нет. В книге опечатка.

Денис Зубрицкий, согласно официальной документации, которая доступна на официальном сайте, режим называется repeater. TL-WR940N(EU)_V5_User Guide, страница 97, параграф 6.2 и далее.

Попробуйте из коммандной строки smbclient, может он скажет, что ему не нравится.

Задача поиска экстремума функции
и поиска экстремума обратной функции.
Может быть к этому ещё капелька эвристики (что бы это ни значило, гы-гы).

потому что многие функции быстро уходят к бесконечности, и выходит полнейшая дичь.

IMHO, это не является препятствием.

Смотрите в "управлении дисками", наверняка там все диски видно. Возможно, буквы разделам не назначены, решается за несколько кликов мышкой.

С разной скоростью можно.
Barracuda в RAID - ну это совсем "дешман" (хотя и сам так делал). Бюджетно-компромиссный вариант - это хотя бы Seagate Iron Wolf или WD Red. Нормальный вариант - это диски enterprise-класса, но они будут раза в 2-3 дороже Барракуды. Также есть диски специально под видеонаблюдение - Surveillance и WD Purple (скорее всего отличаются от других дисков только адаптированной под конкретную задачу прошивкой; не уверен, что стоят своих денег).
Ну и то, что у вас вообще RAID5 - это вам не повезло. То, что RAID5 под видеонаблюдение - не повезло вдвойне. На перспективу я бы задумался о переходе на другой RAID. Подробно расписывать не буду, тыщу раз эта тема обсуждалась в интернет, и раз десять на Хабре и Тостере. Просто учтите, что вот сейчас вы новый диск поставите, и синхронизация массива у вас может идти несколько дней, учитывая, что рабочая нагрузка от видеонаблюдения идёт 24 часа в сутки. За эти несколько дней случится хоть одна ошибка на любом из остальных трёх дисков - и кирдык всему RAID'у.

У каждого конкретного сайта могут быть какие-то свои особенности, про которые никто ни в одном руководстве не напишет, и здесь заранее никто не угадает. Поэтому гарантированной 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. Это всё годится в случае, если БД не содержит чего-то, что всегда должно быть в актуальном состоянии (я про всякие интернет-магазины, соц.сети и т.п.), там перенос БД был бы самым замороченным пунктом.

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

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