Hardoman

Puppy Linux - самый лёгкий, основан на Debian
Linux lite - судя по их базе данных, заработает на Atom
Damn Small Linux 2024 - занимает до 700 Мбайт
Lubuntu - убунта с лёгкой FXCE оболочкой, но все равно тяжелее конкурентов. Зато больше современных возможностей.

Если у вас git и код в WSL, то IDE тоже надо запускать из WSL, а не из Windows
В примере с VSCode

sudo apt install code
cd ~/my-git-project
code .

VScode в WSL имеет свои настройки, плагины и т.п., которые лежат отдельно в папке вашего юзера WSL ~/.vscode-server/, отличающиеся от инсталляция в винде.

Для диагностики во время пропадения интернета выполните трассировку.
например (для Windows)
tracert ya.ru
Где обвалится - там и проблема (исключение - хопы трассировки за IX узлами, там иногда 1 или 2 узла могут не отвечать на ICMP, но за ними трейс должен продолжиться!).
Если при этом не резолвится ya.ru, то значит DNS не доступен, что само по себе может не являться корнем проблемы, если вы на клиентах используете сторонний DNS, который без интернета не доступен.
Попробуйте трейс до 77.88.8.8 - это DNS Яндекса, он при рабочем интернете должен быть доступен всегда.

Также пингуете каждый узел на пути до интернета по цепочке. Если пинги уходят за периметр вашей сети, то проблема не у вас. Например, пингуется ваш шлюз в интернет, но за ним не пингуется гейтвей провайдера.
Для пинга хорошо бы узнать IP гейтвея провайдера и их DNS, каждый из них проверить (обычно они видны на вашем WAN интерфейсе).

Вероятно, не хватает ресурсов для корректной работы
1. Ограничьте память и cpu в файле .wslconfig
2. Используйте Hyper-V (с любой осью), а не wsl

Я не думаю, что дело в nginx, но это легко проверить передавая запросы в docker напрямую, минуя nginx

Здесь неплохо описано
https://hww.ru/2008/11/remont-i-vosstanovlenie-kla...

Нет смысла защищать секреты внутри контейнеров, как уже было сказано, если есть доступ к контейнеру, их в любом случае раскроют.
Озаботьтесь тем, чтобы при сборке и деплое контейнера секреты не передавались в открытом виде (в зависимости от инструмента деплоя - разные методы защиты, например в ansible используйте ansible-vault, если docker-compose, используйте файлы, которые маунтят секрет, чтобы не писать в compose файле секрет в открытом виде) :

version: '3.8'
    secrets:
      db_password:
        file: ./secrets/db_password.txt # Путь к локальному файлу с секретами 
    services:
      database:
        image: postgres
        environment:
          POSTGRES_PASSWORD_FILE: /run/secrets/db_password
        secrets:
          - db_password

Секрет у вас будет маунтиться в /run/secrets/, но надо все равно использовать внешний файл с паролем.

В swarm чуть более удобно - пароль берётся из секрета, который создаётся заранее

docker swarm init
docker secret create <secret_name> <file_path>

или

echo "mysecretvalue" | docker secret create <secret_name> -

version: '3.8'
    secrets:
      db_password:
        external: true # Указывает, что секрет уже создан в swarm
    services:
      database:
        image: postgres
        environment:
          POSTGRES_PASSWORD_FILE: /run/secrets/db_password
        secrets:
          - db_password

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

Вероятно, дело в BranchCache, и его надо локально отключить

Никогда, никогда не пишите логи в базу напрямую. В первую очередь из-за скорости, во-вторых, это синхронное действие процесса и оно должно выполняться всегда, а при недоступности базы повесит процесс в wait.
Если надо парсить большой объем логов (не ваш случай), то их отдельно можно стримить куда угодно, хоть в кафку, хоть в elasticsearch специально предназначенными для этого сервиса и типа vector.
Ротировать локальные логи logrotate'ом

Если я правильно понял, то скорость по wifi у вас выше, чем по кабелю на ПК?
В таком случае, проверяйте:
- что ОС показывает подключение к порту 1000 Мбит
- что на l2 порты 1000М
- категория кабеля 5е
- кабель правильно обжат и все 8 жил правильно звонятся в нужном порядке. 100М использует только 4 жилы.

ПО такого полно.
Инфраструктурным стандартом является Hashicorp Vault

В РФ распространен Passwork

Важно! Их не нужно использовать для передачи секретов за пределы контура компании.
Для таких целей можно использовать сервисы разового доступа к секретам, например Bitwarden Send или Password Pusher

Если вы можете подключиться к порту 5678, то проблема не в докере. Вероятно, ваш сервис слушает только на 127.0.0.1 внутри контейнера, а не на 0.0.0.0
Также может быть проблема в файрволе
Пробуйте следующие тесты:
- curl -v 127.0.0.1:5678
- curl -v host_ip:5678

Если WAN порт не может согласовать с портом вышестоящего свитча 1000М, то на это могут быть только физические причины:
- качество кабеля и его категория
- его длина (необходимо, чтобы мастер проверил тестером длину кабеля по каждой из жил, длина должна совпадать и желательно не превышать 90 м). Если длина по разным жилам разная - это говорит об обрыве или частичном повреждении на том расстоянии, которое выдает тестер.
- влияние силовых кабелей: нельзя, чтобы витая пара шла параллельно силовому кабелю. При воздействии эл-магнитного поля силового кабеля в витой паре индуцируется поле, в результате чего порты снижают частоту с 1ГГц до 100 МГц для стабильности. Это происходит автоматически, если количество ошибок доставки пакетов возрастает.
- битый порт на свитче провайдера. Иногда переключение на другой порт помогает.

Скорее всего, доступ по паролю для root запрещен (а это дефолтная конфигурация sshd).
Если вы не добавляли ключ, то подключитесь к серверу через консоль хостера по протоколу VNC и поменяйте конфиг временно
/etc/ssh/sshd_config

PermitRootLogin yes
PasswordAuthentication yes

Также удалите все дополнительные файлы в папке /etc/ssh/sshd_config.d/ (их часто добавляют хостеры при бутстрапе ноды)
Рестартаните сервис, добавьте ключ, проверьте, что вы с ним можете войти и замените обратно на

PermitRootLogin no

Это технически невозможно, скорость ограничивается точками обмена трафика MSK-IX, куда почти все дата-центры подключены.

Вообще то, что вы хотите, противоречит логике фпцловх серверов и Samba. На фпцловх серверах делается или одна общая папка на всех или папка для каждого пользователя.
Папки на клиентских хостах не надо расшаривать. Это не безопасно и не соответствует идеологии централизованного управления.

Чтобы организовать общую сетевую папку Samba, доступную всем пользователям домена FreeIPA, выполните следующие шаги:

### 1. Установка и настройка Samba
```bash
sudo dnf install -y samba samba-client samba-common
```

### 2. Интеграция Samba с FreeIPA
```bash
sudo ipa-adtrust-install --add-sids
```

### 3. Создание общей папки
```bash
sudo mkdir -p /srv/shared
sudo chmod 2770 /srv/shared
sudo chown root:"DOMAIN\users" /srv/shared
```
Замените `DOMAIN` на имя вашего домена.

### 4. Настройка Samba (`/etc/samba/smb.conf`)
```ini
[global]
workgroup = DOMAIN
security = ads
realm = DOMAIN.EXAMPLE.COM
idmap config * : backend = tdb
idmap config * : range = 10000-999999
idmap config DOMAIN : backend = sss
idmap config DOMAIN : range = 10000-999999
winbind use default domain = yes
template shell = /bin/bash
template homedir = /home/%U

[shared]
path = /srv/shared
read only = no
writable = yes
browseable = yes
valid users = @"DOMAIN\users"
force group = "DOMAIN\users"
create mask = 0660
directory mask = 2770
```

### 5. Перезапуск служб
```bash
sudo systemctl restart smb nmb
sudo systemctl enable smb nmb
```

### 6. Настройка доступа через SELinux (если используется)
```bash
sudo semanage fcontext -a -t samba_share_t "/srv/shared(/.*)?"
sudo restorecon -Rv /srv/shared
```

### 7. Проверка доступа
С любого клиента в домене попробуйте подключиться:
```bash
smbclient //server-name/shared -U user-name
```

### Дополнительные настройки (по желанию):
- Для автоматического монтирования добавьте запись в `/etc/fstab`:
```
//server-name/shared /mnt/shared cifs credentials=/etc/samba/credentials,uid=%u,gid=%g,dir_mode=0770,file_mode=0660 0 0
```

Где `/etc/samba/credentials` содержит:
```
username=user
password=pass
domain=DOMAIN
```

Важно: Все пользователи должны быть членами группы "users" в FreeIPA. Проверить можно командой:
```bash
ipa group-show users
```

Если вам нужно, чтобы **каждый Linux-клиент в домене FreeIPA** имел свою расшаренную папку, доступную другим пользователям домена, но **без установки Samba на каждом клиенте**, альтернативой может быть использование **SSHFS + Autofs + Kerberos** или **NFSv4 + Kerberos**.

Но если вам нужен именно **SMB-доступ** (например, для Windows-клиентов), то без установки Samba на каждом хосте не обойтись.

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

Во-вторых, блоки IP наши провайдеры берут у ДЦ, где арендуют стойки. И эти блоки адресов переходят их рук в руки и их принадлежность меняется, но это отражается не во всех базах.

Про смену хостера не из РФ - это вообще не обязательно. Десятки наших хостеров, у кого сервера арендованы заграницей определяются корректно. Как я сказал, важно, как были арендованы или вукуплены адреса.