hint000

а при обращение к subdomain.site.com перенаправило на 44.44.44.44 (почтовый сервер)

Почтовому серверу пофиг домен при установке соединения, так что ориентруйтесь по номерам портов.

iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 25 -j DNAT --to-destination 44.44.44.44
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 465 -j DNAT --to-destination 44.44.44.44
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 587 -j DNAT --to-destination 44.44.44.44

iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 80 -j DNAT --to-destination 33.33.33.33
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 443 -j DNAT --to-destination 33.33.33.33

Если ваш почтовый сервер не использует порт 465/tcp или 587/tcp, то лишние правила можете убрать.

Хорошая статья, из которой процитирую несколько фраз:
https://habr.com/ru/company/itsoft/blog/525054/

...Дублирование того, что уже и так прописано в законе.
...Ничтожные пункты, которые противоречат законам.

...В договоре не имеет смысла дублировать закон. Законы меняются со временем, а пункты договора могут стать ничтожными.

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

Это не пароль пользователя

Ну-у-у... это пароль пользователя, таки да. Но это старый пароль пользователя. Хром не знает, что с тех пор пароль менялся. Попробуйте вспомнить, какой был пароль на момент установки системы.

По идее это так называемый пароль от связки ключей (keyring по-английски). После логина нужно разблокировать связку ключей, и это делается прозрачно, когда пароль пользователя совпадает с паролем связки. Но когда пароль пользователя сменили, то пароль связки ключей не менялся.
Решение где-то тут: https://www.google.com/search?q=change+keyring+password

P.S. То же самое актуально, например, для RDP-клиента Remmina, не только для Chromium.

iptables -A PREROUTING -d 1.1.1.1 -p tcp --dport НомерПорта -j DNAT --to-destination 10.8.0.2:НомерПортаМожноДругой

Использую git для хранения конфигураций серверов.

в Excel нажать Ctrl-H

a = ( i == j ? 1 : 0 )

другой вариант:
a = ( i >= j ? 1 : 0 )

третий вариант:
a = ( i <= j ? 1 : 0 )

четвёртый вариант:
a = ( i == n+1-j ? 1 : 0 )

пятый вариант:
a = ( i >= n+1-j ? 1 : 0 )

шестой вариант:
a = ( i <= n+1-j ? 1 : 0 )

скачал с гитхаба проект на питоне, который позволяет преобразовывать MP4 и смотреть видео в консоли через ASCII. Всё работает очень быстро, но консоль неприятно мигает.

В стародавние времена как работали с динамичной графикой: брали два буфера, один из них отображался на экране, на втором рисовали следующий кадр; когда рисование кадра закончено, буферы меняли местами (не содержимое буферов, а их роли).
Здесь задача чуть другая. Достаточно взять один буфер размером в консольный экран (X*Y символов). Очередной кадр нужно рисовать в буфере, а потом быстро копировать готовый кадр. И никакого стирания. Просто копирование кадра целиком.

тогда зачем вообще в клиент-серверном чате p2p передача?

Чтобы не напрягать сервер (и его канал в интернет). Одно дело гонять через сервер короткие текстовые сообщения, и совсем другое - большие файлы.

Насчёт комментариев Strabbo и AlexVWill.
Действительно, маршрутизацией не решается, но и действительно без VPN можно обойтись.
Нужно два правила iptables на стороне прокси. Одно DNAT с заменой адреса прокси на адрес сервера, другое SNAT с заменой адреса клиента на адрес прокси. Побочный эффект - сервер вместо адресов любых клиентов будет видеть только адрес прокси. Если такой побочный эффект не желателен, тогда в соответствии с ответом Drno.

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

Если речь о третьем уровне и дальше, то можно только верить в удачу (что вы начнёте искать и случайно прям быстро попадётся ваше слово). Централизовано информация о всех доменных именах нигде не хранится. Если я зарегистрировал домен 2-го уровня, то могу хоть каждую минуту создавать и удалять домены 3-го, 4-го,.. , 80-го,.. уровня в пределах своего 2-го уровня (и могу делать это на своём собственном DNS-сервере, никого не уведомляя). За то время, пока вы будете перебирать старые домены, будет создано столько новых, что в итоге вы никогда не разгребёте эту кучу.

borg333, домены не будут ассимилированы, сопротивление не бесполезно ;) (ЕВПОЧЯ)

Как можно исправить?

Нужно понять, в каком месте исправлять.
Для этого нужно провести тесты, замеры производительности. В первую очередь предлагаю протестировать задержку и пропускную способность сети в виртуалке, потом скорость диска в виртуалке.

Если сбойный участок используется под видеопамять (ну так повезло), то могут быть артефакты (в том числе малозаметные), но вполне может ничего не зависнуть. При дискретной видеокарте тот же сбойный участок памяти может оказаться задействованым под операционную систему - в этом случае зависания, BSOD и т.п. очень вероятны.