res2001

Обычно, когда вы арендуете целиком подсеть, то у вас есть эта подсеть + еще какой-то белый адрес не из этой подсети, который выдается оператором для внешнего интерфейса и через который будет происходить маршрутизация вашей подсети оператором. Соответственно на шлюз на внешний интерфейс вешается этот отдельный адрес, а в локальной сети назначаете адреса из подсети (статически или через DHCP). Т.е. все то же самое, как и при использовании серых адресов, только в случае с серыми адресами подсети их вам никто не выдает (выбираете любой диапазон по собственному усмотрению) и вы обязаны использовать NAT для выхода в интернет.

Если же у вас только подсеть, то используйте ответ Andrey Barbolin

У астры неплохая вики, а так же есть форум, пользуйтесь. Там уже большая часть вопросов "от новичков" разжевана.
На счет репозиториев, на сколько помню, там по умолчанию прописан только репозиторий лежащий на диске (на CD или на образе), никаких репозиториев в интернете не зарегистрировано. Если диск не вставлен или образ не смонтирован, то репозиторий будет не найден.
Но это можно легко поправить: https://wiki.astralinux.ru/pages/viewpage.action?p...

Таймаут при вызове connect. Это, в принципе, нормально и вполне вероятно в любых сетевых приложениях. Это может говорить о недоступности удаленной стороны или плохом качестве связи.
Обычной реакцией на подобную ошибку может быть повтор операции или завершение приложения с ошибкой.

Используйте ВПН и USB over IP для проброса флэшки на VDS.

Это последняя версия питона в репах дебиана?
Если да, то найдите стороннюю репу со свежим питоном и добавьте ее в систему.
Если нет - обновите сам дебиан
sudo apt update & sudo apt upgrade

Дык этож не винда, наследования прав нет. Процесс создающий файл сам задает права доступа.
Гуглите umask.
Установите нужную маску для пользователя из-под которого работает www-cloud.
И еще, по моему, чтоб схема работала должно быть username UID == www-cloud UID

С веб мордой вряд ли что-то найдете. Разве что на VPS воткнете что-то типа pfsence или аналогов.
Я голосую за openvpn :-)

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

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

Возможно это связано с разными значениями mtu на клиенте и сервере.
Добавьте опцию mtu-test в конфиг на сервере и клиенте, тогда при подключении openvpn будет тестировать mtu и выведет в лог информацию о реальном мту, его можно будет прописать в опции tun-mtu
https://community.openvpn.net/openvpn/wiki/Openvpn...
https://forums.openvpn.net/viewtopic.php?t=25039

MaxxDamage,
Конфиг сервера:
push "route 192.168.1.0 255.255.255.0 10.8.0.2"
Обычно в route не задают третий параметр - он подставляется автоматически - адрес ВПН сервера.
push "route ..." прописывает на клиенте маршрут до сети за сервером. У вас же эта команда прописывает на клиенте маршрут за клиентом. Этот маршрут и так присутствует на клиенте.
Нужно ее привести в такой вариант:
push "route 192.168.0.0 255.255.255.0"
После подключения клиента в его таблице маршрутизации должен появиться соответствующий маршрут.

Директива
route 192.168.1.0 255.255.255.0 10.8.0.1
в таком виде не правильна.
route добавляет маршрут на своей стороне (т.е. на стороне сервера в данном случае). Нужно в третьем параметре указать адрес клиента (10.8.0.1 - наверняка адрес сервера).
Но лучше перенести эту директиву в клиентский конфиг на сервере (это тот который лежит в пути указанном в директиве client-config-dir) в следующем виде:
iroute 192.168.1.0 255.255.255.0
Тогда при подключении клиента маршрут к его сети добавится на сервере, адрес клиента автоматически добавится к директиве, его указывать явно не нужно.

Конфиг клиента:
Директива
route 192.168.0.0 255.255.255.0
тут не нужна. Ее функции выполняет директива push "route ..." в конфиге сервера.
Вообще обычно клиентский конфиг делают максимально простым. Вся маршуртизация прекрасно конфигурируется на стороне сервера.

Вообще можно конфигурацию ВПН полностью отладить на виртуалках в своей виртуальной сети и перенести ее на реальное железо, заменив только слушающий адрес сервера в директиве local.

Видимо параллельно нужно вести и обратную зону. Обратная - это там где по IP вы получаете имя.

Выдать конкретному клиенту фиксированный IP средствами OpenVPN можно.
Все остальное делается в iptables.

Сталкивался с подобной ситуацией, но в другой конфигурации оборудования и ПО (ESXi + хранилка от HP).
Но схема действий одна и та же:
Если у вас все тома в виртуалках тонкие, то одного удаления файлов в виртуалке не достаточно, чтоб освободившееся место было отдано гипервизору - нужно забить это место нулями (по крайней мере в моем случае было так), причем это место должно быть в конце диска.

Если тома толстые, то:
1.Вы должны уменьшить размер раздела в виртуальных машинах, причем правильно - так что бы свободное место было в конце тома. Это можно сделать и в случае thin томов.
2.Уменьшить том выделенный этой виртуальной машине в гипервизоре. Только после этого свободное место будет доступно для других ВМ.

PS: этим и опасны thin тома - нужно всегда контролировать свободное дисковое пространство.

Скорее всего нет прав, возможно не на сам скрипт, а на вышележащие каталоги.

Это может быть кабель или коммутатор.
Воткните в этот кабель в другой комп, заведомо рабочий и погоняйте.
Если другой комп нормально себя ведет - значит дело в адаптере - меняйте.
Сбойные сетевые адаптеры порой ведут себя очень странно.

Тут скорее виноват OpenVPN.
Посмотрите это.

Для внутренних нужд завести внутренний ДНС сервер, для внешних пользователей - внешний. 2 разных ДНСа.

Дожили. Гугл консультируется на тостере :)