Игорь

Можно еще убрать из configure:
--with-http_perl_module
Если Вы не собираетесь часть конфига на perl писать.
Вот описание модуля:
nginx.org/ru/docs/http/ngx_http_perl_module.html

Самое простое ssh -D и прописать полученный сокет как прокси в браузере. Не требует никакой дополнительной возни.
А так можно помимо вышепредложенных сделать наприер VPN до сервера и пушить в него маршруты только до IP серверов, на которые Вы хотите ходить через Ваш сервер. Тогда через VPN будет ходить трафик только до указанных IP, остальной будет ходить обычным дефолтным маршрутом. На openvpn такая схема достаточно просто реализуется. Из дополнительных плюсов- шифрование.

Покажите выводы команд:

ip r
ip a
iptables-save

Postrouting в основном используется для маскарадинга. То-есть когда у Вас есть шлюз и за ним "серая" сеть. В данному случае, чтобы машины из "серой" сети могли ходить в интернет необходим masquerade на шлюзе, котоый будет подменять "серый" source ip в пакете на белый адрес шлюза или жестко прописанный -j SNAT --to-source.

В случае Вашего правила всё, что будет уходить с eth0 шлюза будет иметь source ip в пакете 95.17.248.226. То-есть происходит подмена 10.8.0.2 на 95.17.248.226, если запрос уходит с 95.17.248.226. И пакет уходит с "белым" ip шлюза.

Если из внутренней сети подключаетесь, а из внешней проблема. Значит проблема в пробросе или в разрешениях на шлюзе через который подключаетесь.
Рекомендую задать диапазон пассивных портов и пробросить его на шлюзе до сервера.

Конфигурационный файл можно положить в /etc/supervisor/conf.d.
А подробнее хорошо расписано в этой инструкции:
https://www.digitalocean.com/community/tutorials/h...

Чтобы понять какая программа, сделайте:
netstat -ntpua | grep 80
и смотрите какой pid будет устанавливать соединения на 80-й порт.

Чтобы посмотреть сам трафик, попробуйте его отфильтровать например tcpdump-ом:
tcpdump -nieth0 tcp port 80
так в базовом виде увидите весь трафик по 80-му порту. Дальше можно добовлять ключики для фильтрации лишнего.

Если Вы хотите запустить графическое приложение на сервере, но с пробросом иксов к себе (то-есть запустить его на своих иксах), то через ssh -X /path/to/your/app

Увеличить можно и без размонтирования online, если мы говорим об увеличении именно ФС:
resize2fs /path/to/device

Все зависит от задачи и от бюджета.
Если Ваша среда на windows, то видимо и строить виртуалзиацию лучше на Hyper-V. Если предполагаете использовать linux, то опять же все сводится к задаче. Важны такие параметры как отказоустойчевость, живая миграция и прочее, по этим критериям уже можно думать что брать (платное или бесплатное решение).
Из нативного в linux очень хорошо работает KVM. Документирован хорошо, достаточно удобен в управлении.
Из контейнерного могу посоветовать openvz. Тоже много хорошей документации. Стабильная работа и очень удобные утилиты управления.
Обе данные виртуализации бесплатны.

readonly = yes
writable = yes

Вас тут ничего не смущает?
Проверьте свой конфиг командойtestparm

Попробуйте сделать такой конфиг:

[global]
	workgroup = MYGROUP
	server string = Samba Server Version %v
	
	log file = /var/log/samba/log.%m
	max log size = 50
	
	security = user
	passdb backend = tdbsam
	map to guest = Bad User
	
	load printers = yes
	cups options = raw
	
[share]
	comment = Public Stuff
	path = /media/ftp-data/MediaContent
	public = yes
	writable = yes
	printable = no
	guest ok = yes

Вы хотябы написали что за linux.
Возможно у Вас там уже все на systemd.

Все логично.
Тут дело не в ssh, а в tcp поверх которого уже работает ssh. При смене IP-адреса (сети) рвется tcp-соединение. А новое соединение требует уже нового хендшейка и т.д.
То-есть, Вам нужно, чтобы в случае разрыва программа заново подключалась к Вашему серверу, а это значит проходила авторизацию и еще запускала нужный на сервере screen.
Готового решения подобного под windows, к сожалению, не видел.

А у Вас точно на материнке есть динамик?
Сталкивался с ситуацией, когда он идет отдельным "устройством" вместе с корпусом и его просто надо подключить к мат. плате.

Можно попробовать лить не через ssh а через протокол rsync. В этом случае не нужно будет шифрование и все заработает быстрее. Правда на сторонее приема нужно будет запустить rsync как демона.