\AppData\Local\Packages\...\LocalState\
```
(если осталась)
---
#### Также удалить архив:
```text
D:\wsl\ubuntu.tar
```
(если перенос завершён успешно)
---
### 🧠 ЧАСТЬ 6 — ЧТО В ИТОГЕ ПОЛУЧАЕТЕ
#### Было:
- Ubuntu на C ❌
- диск быстро забивается
#### Стало:
- Ubuntu на D ✅
- C освобождён
- можно ставить:
- nginx
- MariaDB
- PostgreSQL
- GitLab
- .NET
---
### 🚀 ЧАСТЬ 7 — РЕКОМЕНДАЦИИ (ВАЖНО)
После переноса:
#### включите systemd (для сервера):
```bash
sudo nano /etc/wsl.conf
```
Добавьте:
```ini
[boot]
systemd=true
```
---
Потом:
```bash
wsl --shutdown
```
---
#### Дополнительные сведения.
WSL запускается в окне Power Shell, после запуска вы попадаете в терминал, выйти из терминала можно через команду **exit** при этом WSL останется работающим, если же окно Power Shell закрыть, то WSL будет остановлен.
Если в системе есть еще установленные дистрибутивы WSL, то дистрибутив Ubuntu может оказаться не основным по умолчанию и команда
**wsl -l -v**
может выдать примерно следующее:
```
NAME STATE VERSION
*docker-desktop Stopped 2
Ubuntu Stopped 2
docker-desktop-data Stopped 2
```
Чтобы сделать Ubuntu основным дистрибутивом по умолчанию выполните следующую команду:
**wsl --set-default Ubuntu**
В разных окнах Power Sell можно несколько раз выполнить команду wsl но среда WSL будет запущена только один раз, все остальные команды откроют терминалы к этой среде.
#### ❌ Остановка WSL
👉 тогда:
- ВСЕ процессы останавливаются
- WSL полностью выгружается
### 🎯 ИТОГ
✔ WSL ставится через `wsl --install`
✔ Ubuntu создаётся на C по умолчанию
✔ перенос делается через:
- `export`
- `unregister`
- `import`
✔ после этого ext4.vhdx на C больше не нужен
# Создание пользователя - администратора
Текущая работа от `root` в WSL неудобна и рискованна. Лучше создать обычного пользователя `devadmin`, дать ему sudo-права и перевести dev-среду на него. Создать пользователя `admin` не получится, так как уже есть группа с таким названием.
---
### 🏆 Что важно понять заранее
Не все сервисы нужно “переводить” на пользователя `devadmin`.
### Системные сервисы уже работают правильно:
- nginx → пользователь `www-data`
- Apache HTTP Server → `www-data`
- MariaDB → `mysql`
- PostgreSQL → `postgres`
Это **нормально и менять не надо**.
#### Что реально перевести на `admin`
✔ вход в WSL
✔ твои проекты
✔ MinIO
✔ dotnet run / build / git / npm
✔ домашние папки
---
### 🥇 План действий
```text
1. Создать devadmin
2. Дать sudo
3. Сделать default user
4. Перенести dev-файлы
5. MinIO запускать от admin
6. root оставить только для администрирования
```
---
### 🥇 ШАГ 1 — создать пользователя
Сейчас все работает под root, это удобно.
```bash
adduser devadmin
```
Задайте пароль.
---
### 🏆 ШАГ 2 — дать sudo права
Проверить:
Должно быть:
### 🏆 ШАГ 3 — проверить домашнюю папку
Должно появиться:
### 🏆 ШАГ 4 — сделать default user для WSL
В Windows PowerShell:
### 🏆 ШАГ 5 — проверить
Закройте WSL и снова откройте:
Потом:
Должно быть:
### 🏆 ШАГ 6 — дать доступ к проектам
Если проекты лежат в:
или на `D:` — отдельно настроим.
Создайте dev-папки:
---
### 🏆 ШАГ 7 — MinIO перевести на devadmin
Когда пользователь будет создан:
### 🧠 Что с nginx/apache/db
Оставляем как есть:
Это правильно.
# Что такое WSL
**WSL (Windows Subsystem for Linux)** — это подсистема Linux внутри Windows, которая позволяет запускать полноценное Linux-окружение без отдельной виртуальной машины.
### Что даёт WSL
#### Linux-команды
Можно выполнять:
```bash
ls
grep
find
ssh
curl
```
как на обычном сервере Ubuntu.
#### Разработка как на сервере
Если ваш хостинг работает на Ubuntu, то WSL очень удобен:
```text
Продакшен: Ubuntu
Разработка: Ubuntu (WSL)
```
Меньше различий между средами.
#### Docker
Большинство разработчиков под Windows используют Docker через WSL.
#### .NET
Можно поставить Linux-версию SDK:
```bash
dotnet --version
```
и собирать проект так же, как на сервере.
#### React / Node.js
Обычно работают быстрее и стабильнее в WSL, чем в некоторых конфигурациях Windows.
### Как это устроено
В современных версиях используется лёгкая виртуализация.
У WSL есть собственная сеть:
```text
Windows
172.31.32.1
WSL
172.31.xx.xx
```
Именно поэтому вы можете видеть:
```bash
cat /etc/resolv.conf
nameserver 172.31.32.1
```
Это адрес Windows, который виден из WSL.
###
### Чем WSL отличается от виртуальной машины
#### Виртуальная машина
Например, через Oracle VM VirtualBox или VMware Workstation:
```text
Windows
└─ Полноценная VM
└─ Ubuntu
```
Плюсы:
- полная изоляция
Минусы:
- больше памяти
- больше диска
- медленнее старт
#### WSL
```text
Windows
└─ Ubuntu
```
Плюсы:
- быстрый запуск
- меньше ресурсов
- интеграция с Windows
### Почему VS Code любит WSL
Когда открываете проект через:
```text
Remote - WSL
```
VS Code устанавливает внутри Linux свой сервер:
```text
~/.vscode-server
```
Поэтому вы видели каталоги вроде:
```text
~/.vscode-server/data/logs
```
Именно там лежат логи Copilot и Continue.
# Настройка Git в WSL-Ubuntu && Windows
Зайдите в папку проекта.
#### Проверка версии Git
Чтобы узнать, какая версия Git установлена в Ubuntu:
```
git --version
```
*(Если нужно обновить Git до актуальной версии в Ubuntu: `sudo apt update && sudo apt install git -y`).*
Проверить, установлена ли утилита **GitHub CLI (`gh`)** в вашей системе (в WSL Ubuntu, PowerShell на Windows или Linux), можно с помощью любой из следующих команд:
#### Проверка версии (Самый простой способ)
Выполните в терминале:
```
gh --version
```
- **Если `gh` установлен:** Вы увидите версию утилиты и архитектуру, например:
`gh version 2.52.0 (2024-06-20)`
- **Если `gh` НЕ установлен:**
- В **WSL / Ubuntu** вы получите сообщение: `Command 'gh' not found...`
- В **Windows PowerShell** вы получите ошибку: `gh : Имя "gh" не распознано как имя командлета...`
#### Проверка пути к исполняемому файлу
- **В WSL / Ubuntu / Linux:**
```
which gh
```
*(Если установлен, вернет путь вида `/usr/bin/gh` или `/usr/local/bin/gh`).*
- **В Windows PowerShell:**
```
Get-Command gh
```
#### Как быстро установить `gh`, если его нет:
**В WSL / Ubuntu:**
```
sudo apt update && sudo apt install gh -y
```
**В Windows (через winget в PowerShell):**
```
winget install --id GitHub.cli
```
Перед началом работы с репозиторием в GitHub вам нужно к нему подключиться с помощью команды
```
gh auth login
```
Далее последует небольшой диалог, в приведенном примере я использую ключ GitHub для авторизации:
```
gh auth login
? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations on this host? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Paste an authentication token
Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
The minimum required scopes are 'repo', 'read:org', 'workflow'.
? Paste your authentication token: **************************************************
- gh config set -h github.com git_protocol https
✓ Configured git protocol
! Authentication credentials saved in plain text
✓ Logged in as YourGitLogin
```
Чтобы склонировать репозиторий с GitHub со всеми ветками и полной историей, **достаточно выполнить стандартную команду `git clone`**:
```
git clone git@github.com:username/repository.git
```
*(Или через HTTPS / GitHub CLI, например: `gh repo clone username/repository`).*
Вопреки распространенному заблуждению, **стандартный `git clone` по умолчанию скачивает абсолютно ВСЕ ветки, теги и всю историю проекта**.
Однако локально Git сразу создает текстовую указательную ветку только для главной (обычно `main` или `master`). Остальные ветки остаются в так называемом режиме отслеживания (*remote-tracking branches*).
#### Как увидеть все забранные ветки и работать с ними
##### 1. Посмотреть список всех веток
Перейдите в папку проекта (`cd repository`) и выполните:
```
git branch -a
```
Вы увидите список:
```
* main
remotes/origin/HEAD -> origin/main
remotes/origin/main
remotes/origin/dev
remotes/origin/feature-login
```
Все ветки с префиксом `remotes/origin/` **уже находятся на вашем компьютере**, их не нужно скачивать заново из интернета.
##### 2. Как переключиться на нужную ветку
Чтобы начать работать с любой из локально загруженных веток (например, `dev`), просто переключитесь на нее:
```
git checkout dev
```
*(В современных версиях Git также можно использовать `git switch dev`).*
Git автоматически создаст локальную ветку `dev`, свяжет ее с `origin/dev` и переключит ваш рабочий каталог.
#### Если вам нужно гарантированно развернуть ЛОКАЛЬНЫЕ копии ВСЕХ веток сразу
Если ваша цель — не просто скачать проект, а сделать так, чтобы команда `git branch` (без флага `-a`) сразу показывала полный список всех веток как локальных, используйте короткий однострочник прямо в терминале:
**В WSL / Ubuntu (Bash):**
```
git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done
git fetch --all
```
**В Windows PowerShell:**
```
git branch -r | Where-Object { $_ -notmatch '->' } | ForEach-Object {
$branch = $_.Trim().Replace('origin/', '')
git branch --track $branch $_.Trim()
}
git fetch --all
```
После выполнения этого скрипта каждая удаленная ветка превратится в полноценную локальную ветку.
#### Рекомендуемый файл .gitignore для проекта в связке с .NET и REACT:
```bash
# ==========================================
# .NET / C# (Правила сработают для любой подпапки)
# ==========================================
## --- Build & Output directories ---
bin/
obj/
out/
[Bb]in/
[Ob]j/
## --- Visual Studio & Rider temporary files ---
.vs/
.idea/
*.user
*.userosscache
*.sln.docstates
*.suo
*.userprefs
## --- NuGet Packages & Cache ---
*.nupkg
*.snupkg
**/packages/
project.lock.json
project.assets.json
## --- Local settings & Secrets ---
# Локальные пользовательские конфигурации (раскомментируйте, если не хотите коммитить appsettings.Development.json)
# appsettings.Development.json
# appsettings.*.local.json
secrets.json
## --- Test Results & Coverage ---
[Tt]est[Rr]esult*/
*.coverage
*.coveragexml
# ==========================================
# Node.js / Frontend (Vue, React и т.д.)
# ==========================================
node_modules/
dist/
.npm
*.log
# ==========================================
# Общие временные файлы ОС
# ==========================================
.DS_Store
Thumbs.db
```
# Установка MinIO
Инструкция по установке под пользователем **`devadmin`** в WSL Ubuntu Windows с автозапуском через systemd.
### 🏆 Что получим
```text
User: devadmin
Data: /home/devadmin/minio-data
Console: http://localhost:9001
API: http://localhost:9000
Autostart: yes
```
---
### 🥇 ШАГ 0 — зайти под devadmin
Проверьте:
```bash
whoami
```
Должно быть:
```text
devadmin
```
Если нет:
```bash
su - devadmin
```
---
### 🥇 ШАГ 1 — скачать MinIO
```bash
wget https://dl.min.io/server/minio/release/linux-amd64/minio
```
```bash
chmod +x minio
```
```bash
sudo mv minio /usr/local/bin/
```
Проверка:
```bash
minio --version
```
---
### 🥇 ШАГ 2 — создать каталоги
```bash
mkdir -p /home/devadmin/minio-data
mkdir -p /home/devadmin/minio-config
```
---
### 🥇 ШАГ 3 — создать env файл
```bash
nano /home/devadmin/minio-config/minio.env
```
Вставьте:
```ini
MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=StrongPass123!
MINIO_VOLUMES=/home/devadmin/minio-data
MINIO_OPTS=--console-address :9001
```
Сохраните.
Нужно иметь в виду, что
MINIO\_ROOT\_USER=admin
это пользователь-администратор внутри MinIO и к текущему пользователю devadmin отношения не имеет.
---
### 🥇 ШАГ 4 — создать systemd сервис
```bash
sudo nano /etc/systemd/system/minio.service
```
Вставьте:
```ini
[Unit]
Description=MinIO Object Storage
After=network.target
[Service]
User=devadmin
Group=devadmin
WorkingDirectory=/home/devadmin
Environment="MINIO_ROOT_USER=admin"
Environment="MINIO_ROOT_PASSWORD=StrongPass123!"
ExecStart=/usr/local/bin/minio server /home/devadmin/minio-data --console-address :9001
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
```
---
### 🥇 ШАГ 5 — включить автозапуск
```bash
sudo systemctl daemon-reload
sudo systemctl enable minio
sudo systemctl start minio
```
---
### 🥇 ШАГ 6 — проверить статус
```bash
sudo systemctl status minio
```
Должно быть:
```text
active (running)
```
---
### 🥇 ШАГ 7 — открыть в Windows
Браузер:
```text
http://localhost:9001
```
Логин:
```text
admin
```
Пароль:
```text
StrongPass123!
```
---
### 🥇 ШАГ 8 — создать bucket
В UI:
```text
uploads
```
---
### 🧠 Если localhost не открывается
Проверь:
```bash
sudo ss -tulpn | grep 900
```
---
### 🏆 После этого можно использовать в .NET
```json
Endpoint: http://localhost:9000
AccessKey: admin
SecretKey: StrongPass123!
Bucket: uploads
```
---
### 🥇 Важно
Если systemd ещё не включён:
```bash
sudo nano /etc/wsl.conf
```
Добавить:
```ini
[boot]
systemd=true
```
Затем из Windows:
```powershell
wsl --shutdown
```
# Настройка VPN через туннель к VPS
#### Окружение для настройки.
- Имеется VPS с выделенным IP где-то в Европе. Там стоит Linux, в моем случае это Ubuntu. Нужно иметь на сервер права администратора. Сервер должен принимать соединения по ssh.
- Машина с Windows 10 или 11.
- VPS должен быть виден через ваше интернет-соединение. В моем случае у меня было два интернет-подключения: через мобильное соединение VPS виден не был, через проводное соединение видимость была.
- Не должно быть работающих VPN-соединений.
#### Установка туннеля.
Нужно открыть windows PowerShell от лица администратора.
В windows PowerShell нужно подключиться к вашему VPS:
```bash
ssh -D 0.0.0.0:1080 -N root@[IP_your_vps]
```
Windows может попросить подтвердить использование туннеля.
Если у вас нет ключа доступа к VPS, то потребуется ввести пароль для root.
Сессия откроется, это окно PowerShell нужно оставить открытым, оно "зависнет", то есть через туннель пойдет обмен.
Откройте другое окно PowerShell с обычными правами. Проверка соединения:
```bash
curl.exe --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
```
Команда должна показать IP вашего VPS.
В настройках Windows есть раздел "proxy" его можно использовать для включения обмена, но с оговорками. Нужно иметь в виду, что туннель открывается только для протокола socks, для протоколов http и https он не работает. В поле "Proxy IP address" нужно прописать
```bash
socks=127.0.0.1:1080
```
в поле для значения порта ничего быть не должно.
После того, как вы запишите эти настройки, они корректно пропишутся в реестр windows, но при редактировании оттуда будут взяты неверные значения. при повторной записи работа прокси сломается, ниже пример того, как интерпретирует эти настройки интерфейс windows:
[](https://docs.consulting-plus.com/uploads/images/gallery/2026-06/proxy-2.jpg)
для корректной настройки лучше пользоваться PowerShell, чтобы посмотреть настройки используйте команду
```bash
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
```
для установки протокола socks:
```bash
Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer 'socks=127.0.0.1:1080'
```
Нужно иметь в виду, что с таким proxy в вашем случае будут работать только те приложения, которые используют протокол socks.
Не все приложения Windows используют системный SOCKS-прокси.
Например:
- браузеры обычно умеют
- некоторые программы используют WinINET/WinHTTP
- некоторые (включая часть Electron/Node-приложений) игнорируют системный SOCKS и требуют отдельной настройки
Для включения proxy используйте команду
```bash
Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable 1
```
В обычном `cmd.exe` (или FAR например) аналог делается через `reg add`.
Включить прокси:
```
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 1 /f
```
Отключить прокси:
```
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 0 /f
```
Установить SOCKS-прокси:
```
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer /t REG_SZ /d "socks=127.0.0.1:1080" /f
```
Проверить текущие значения:
```
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
```
После изменения реестра некоторые программы сразу подхватывают настройки, а некоторые — только после перезапуска. Чтобы уведомить Windows о смене настроек прокси без выхода из системы, можно выполнить:
```
RUNDLL32.EXE inetcpl.cpl,LaunchConnectionDialog
```
или просто перезапустить приложение (браузер, VS Code и т.п.).
### Пояснения по открытию туннеля от ChatGPT.
Вопрос:
что конкретно делает эта команда ssh -D 0.0.0.0:1080 -N root@\[IP\_your\_vps\]
На вашем компьютере запускается **локальный SOCKS5-прокси** на порту `1080`.
Все программы, которые используют этот SOCKS-прокси, будут выходить в интернет через VPS.
Схема:
```
Приложение
↓
SOCKS5 127.0.0.1:1080
↓
SSH-соединение
↓
VPS
↓
Интернет
```
#### Разбор параметров
##### `ssh`
Запускает SSH-клиент.
##### `root@IP_VPS`
Подключается к VPS:
```
Пользователь: root
Сервер: IP_VPS
```
Например:
```
ssh root@38.242.220.114
```
##### `-D`
Означает **Dynamic Port Forwarding**.
То есть SSH создаёт SOCKS-прокси.
Например:
```
-D 1080
```
создаёт:
```
SOCKS5 localhost:1080
```
Любая программа, умеющая SOCKS5, может его использовать.
##### `0.0.0.0:1080`
Очень важный момент.
Если написать:
```
-D 1080
```
или
```
-D 127.0.0.1:1080
```
то SOCKS будет доступен только на локальном интерфейсе Windows.
WSL обычно не сможет к нему подключиться напрямую.
Если написать:
```
-D 0.0.0.0:1080
```
то SSH слушает на всех интерфейсах:
```
127.0.0.1
LAN IP
WSL gateway
и т.д.
```
##### `-N`
Означает:
```
Не запускать shell на VPS
```
То есть:
❌ не открывать консоль Linux
✅ только держать туннель
Окно просто висит:
```
ssh -D ...
```
и прокси работает.
#### Что НЕ делает эта команда
Она НЕ создаёт полноценный VPN.
Не происходит автоматического перенаправления всего трафика.
Например в WSL:
```
curl https://api.ipify.org
```
по умолчанию всё ещё идёт напрямую.
А вот:
```
curl --proxy socks5h://172.31.32.1:1080 https://api.ipify.org
```
идёт через VPS.
#### Чем отличается от VPN
VPN:
```
Весь трафик
↓
VPN
↓
VPS
```
SSH SOCKS:
```
Только программы,
которые настроены на SOCKS
↓
VPS
```
#### Почему это удобно
Для связки:
```
Windows
└─ WSL
└─ VS Code
└─ Continue
```
достаточно настроить Continue, VS Code или переменные окружения на использование SOCKS.
Тогда:
- Continue
- OpenAI API
- Gemini API
- GitHub Copilot
будут работать через VPS,
а остальной интернет останется обычным.
Для дополнительной безопасности я бы рекомендовал использовать не `root`, а отдельного пользователя на VPS:
```
ssh -D 0.0.0.0:1080 -N devadmin@IP_VPS
```
Это не влияет на работу туннеля, но считается хорошей практикой администрирования.
# Работа с MS Vs Code
Настройка, работа в Windows и Linux, подключение AI-агентов и плагинов.
# Настройка VS Code для работы в WSL
WSL - это среда Linux под Windows [подробнее о WSL](https://docs.consulting-plus.com/books/linux-windows/page/cto-takoe-wsl "Что такое WSL").
Для стека **Ubuntu-хостинг + .NET 10 + React + SSH-туннели** VS Code через WSL обычно удобнее, чем запуск проекта напрямую в Windows.
#### 1. Среда разработки совпадает с сервером
Если у вас продакшен на Ubuntu.
Когда VS Code открыт как:
```text
WSL: Ubuntu
```
команды выполняются в Linux:
```bash
dotnet build
npm install
npm run dev
```
То есть почти в той же среде, что и сервер.
Меньше сюрпризов вида:
> "На Windows работает, а на Ubuntu нет".
#### 2. Лучше работает Node.js и React
Многие инструменты фронтенда изначально ориентированы на Linux/macOS.
Например:
- Vite
- Webpack
- ESLint
- npm
- pnpm
обычно чувствуют себя в WSL стабильнее, чем при работе с проектом на диске Windows.
Особенно это заметно на больших проектах.
### 3. Нормальные Linux-инструменты
Сразу доступны:
```bash
grep
find
sed
awk
ssh
rsync
curl
```
Не нужно искать Windows-аналоги.
#### 4. Удобнее работать с сервером
Если вы постоянно используете SSH к VPS.
В WSL можно:
```bash
ssh server
scp file
rsync project
```
без дополнительных утилит.
#### 5. AI-инструменты работают рядом с кодом
Когда VS Code открыт в WSL:
```text
VS Code
↓
VS Code Server (в WSL)
↓
Continue / Copilot
↓
Файлы проекта
```
AI видит проект напрямую в Linux-среде.
#### 6. .NET ближе к реальному продакшену
Если сервер Ubuntu, то:
```bash
dotnet publish
```
в WSL собирает проект в Linux-окружении.
Легче ловить проблемы:
- путей (`/` против `\`)
- регистра файлов
- прав доступа
- конфигурации Linux
#### Когда лучше открывать через Windows
Есть случаи, когда удобнее работать напрямую из Windows:
- WinForms
- WPF
- MAUI под Windows
- COM-компоненты
- специфичные Windows SDK
Но если у вас:
```text
React
ASP.NET Core
Ubuntu
```
то WSL выглядит более естественным вариантом.
#### Важный момент
Если вы используете WSL, держите проект внутри Linux-файловой системы:
```text
/home/devadmin/projects/myapp
```
а не в:
```text
/mnt/c/Users/...
```
На небольших проектах разница может быть незаметна, но на React-проектах с большим количеством файлов производительность и скорость работы инструментов обычно лучше внутри файловой системы WSL.
Откройте:
```
nano ~/.bashrc
```
добавьте в конец:
```
export ALL_PROXY=socks5://172.31.32.1:1080
export HTTP_PROXY=socks5://172.31.32.1:1080
export HTTPS_PROXY=socks5://172.31.32.1:1080
```
Сохраните:
```
Ctrl+O
Enter
Ctrl+X
```
Применить:
```
source ~/.bashrc
```
##### Для VS Code Remote WSL
В `settings.json`:
```
{
"http.proxy": "socks5://172.31.32.1:1080",
"http.proxySupport": "override",
"http.proxyStrictSSL": false
}
```
После этого:
- Continue
- Copilot
- npm
- dotnet restore
- git clone
- curl
из WSL будут идти через VPS.
---
Ваша итоговая схема теперь:
```
Windows
|
| SSH -D 0.0.0.0:1080
|
v
VPS (38.242.221.111)
|
v
Internet
WSL
|
v
172.31.32.1:1080
```
# Настройка SSH для VPS (Windows && Linux-WPS)
## Настройка под Windows.
Для настройки соединения у вас обязательно должен быть файл с приватным ключом и желательно с публичным тоже. В моем примере я использую ключи в формате ED25519, которые приходят сейчас на смену ключам RSA. На VPS вы сгенирировали файлы с ключами, в моем случае они назывались id\_ed25519 и id\_ed25519.pub, лучше их переименовать в виде id\_ed25519\_myproxy и id\_ed25519\_myproxy,pub. Если у вас имеется несколько серверов с различными ключами, то названия файлов будут различаться и подключение будет управляться через файл config.
Положите файлы в папку **C:\\Users\\\[your\_user\_name\]\\.ssh\\**, в той же папке создайте файл **config** без расширения примерно с таким содержанием:
```bash
Host myproxy
HostName 11.22.33.44 # IP-адрес или домен вашего VPS
User root # Логин для подключения
IdentityFile ~/.ssh/id_ed25519_myproxy # Путь к файлу ключа
DynamicForward 0.0.0.0:1080
SessionType none
Port 22 # Порт (если меняли стандартный)
```
Строка **DynamicForward 0.0.0.0:1080** это прямой аналог флага `-D 0.0.0.0:1080` в файле конфигурации. Он включает локальный SOCKS5-прокси на порту `1080` для всех сетевых интерфейсов (`0.0.0.0`), строка SessionType none это директива `RequestTTY no` которая аналогична флагу -N и позволяет не выполнять команды на удаленном сервере, а только держать туннель.
Запуск туннеля на ваш сервер будет теперь выполняться одной командой:
```
ssh myproxy
```
Проверить, открыт ли порт **1080** и слушаются ли на нем подключения, можно прямо из консоли Windows (Command Prompt / PowerShell) или из среды WSL.
Ниже приведено несколько простых способов проверки работает ли соединение.
Откройте **PowerShell** от имени администратора или обычного пользователя и выполните:
-
**Если порт открыт и прослушивается:** Команда выведет таблицу с состоянием подключения (`State: Listen`), а в колонке `OwningProcess` будет указан PID (идентификатор процесса, например, вашего `ssh.exe`).
-
**Если порт закрыт:** Команда ничего не выведет (вернется пустая строка).
Откройте командную строку или PowerShell и выполните:
-
**Ожидаемый результат (порт открыт):**
```
TCP 0.0.0.0:1080 0.0.0.0:0 LISTENING 1234
```
*(Значение `LISTENING` означает, что SOCKS-туннель успешно поднят и ждет подключений, а `1234` в конце — это PID процесса SSH).*
-
**Если порт закрыт:** Вывод будет абсолютно пустым.
Если туннель или проверяемое приложение запущены внутри WSL, используйте стандартные утилиты Linux:
Если вы хотите убедиться, что порт не просто открыт, а к нему действительно можно успешно подключиться локально (например, со стороны браузера или приложения):
В ответ вы получите отчет. Обратите внимание на нижнюю строку:
-
`TcpTestSucceeded : True` — порт открыт и принимает соединения.
-
`TcpTestSucceeded : False` — порт закрыт (SSH-туннель не запущен или упал).
**Узнать, какая программа заняла порт:**
Если порт 1080 занят, но вы не уверены, чем именно, узнайте PID из команды `netstat` (последнее число в строке) и выполните в PowerShell:
```
> Get-Process -Id
>
> ```