Два независимых VPN-туннеля: WireGuard + ProtonVPN через Shadowsocks
Добавим контейнер ProtonVPN рядом с существующим контейнером WireGuard на том же VPS, доступный с ПК через прокси Shadowsocks, Я всегда стараюсь делать легко обратимые изменения. .
Цель
- Не изменять существующий контейнер WireGuard.
- Добавить второй, независимый туннель: ПК → Shadowsocks → контейнер ProtonVPN → интернет.
- Каждый контейнер управляет своей сетью. Без общих маршрутов и изменений iptables на хосте.
- Выбирать нужный туннель на уровне клиента или приложения, либо использовать оба одновременно.
Сервер
Существующий сервис wireguard остаётся как есть (network_mode: host, своя подсеть и пиры). Добавим контейнер gluetun с клиентом ProtonVPN и включённым Shadowsocks.
Добавьте сервис protonvpn в docker-compose.yml, рядом с существующим сервисом wireguard:
protonvpn:
image: qmcgaw/gluetun:latest
container_name: protonvpn
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
environment:
- VPN_SERVICE_PROVIDER=protonvpn
- OPENVPN_USER=${PROTONVPN_USERNAME}
- OPENVPN_PASSWORD=${PROTONVPN_PASSWORD}
- SERVER_COUNTRIES=Netherlands
- SHADOWSOCKS=on
- SHADOWSOCKS_PASSWORD=${SHADOWSOCKS_PASSWORD}
- SHADOWSOCKS_METHOD=chacha20-ietf-poly1305
ports:
- "8388:8388/tcp"
- "8388:8388/udp"
volumes:
- ./protonvpn:/gluetun
restart: unless-stopped
gluetun сам устанавливает OpenVPN-соединение с ProtonVPN и запускает сервер Shadowsocks внутри собственного сетевого namespace контейнера, отдельно от таблицы маршрутизации хоста.
Создайте файл .env рядом с docker-compose.yml с PROTONVPN_USERNAME, PROTONVPN_PASSWORD и SHADOWSOCKS_PASSWORD. Используйте учётные данные OpenVPN от Proton, а не логин от аккаунта (можно взять тут https://account.protonvpn.com/account#openvpn ).
SHADOWSOCKS_PASSWORD=<some-password>
PROTONVPN_USERNAME=<openvpn-username-not-protonvpn-account-name>
PROTONVPN_PASSWORD=<openvpn-password-not-your-account-password>
Запустите:
docker-compose up -d
docker logs protonvpn
Убедитесь, что исходящий IP принадлежит ProtonVPN, а не самой VPS:
docker exec protonvpn wget -qO- ifconfig.me
Клиент
Clash (или одна из GUI-обёрток, например Clash Verge) читает YAML-конфиг и поднимает одновременно HTTP- и SOCKS5-прокси.
Сохраните в config.yaml:
port: 7890
socks-port: 7891
allow-lan: false
mode: Rule
proxies:
- name: "ProtonVPN-SS"
type: ss
server: your-vps-host.example.com
port: 8388
cipher: chacha20-ietf-poly1305
password: "your_shadowsocks_password"
udp: true
proxy-groups:
- name: "PROXY"
type: select
proxies:
- ProtonVPN-SS
- DIRECT
rules:
- MATCH,PROXY
Запустите clash из каталога с этим config.yaml:
clash
# INFO Start initial compatible provider PROXY
# INFO HTTP proxy listening at: 127.0.0.1:7890
# INFO SOCKS proxy listening at: 127.0.0.1:7891
Clash читает конфиг и висит как обычный процесс (не в фоне).
Настройка в GNOME
При запущенном Clash:
- Откройте
Settings→Network→Network Proxy. - Выберите
Manual. - В
SOCKS Hostукажите127.0.0.1и порт7891. - Нажмите
Apply.
Или то же самое из командной строки:
gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.socks host '127.0.0.1'
gsettings set org.gnome.system.proxy.socks port 7891
Большинство GTK-приложений и всё, что учитывает системный прокси (включая многие CLI-утилиты через all_proxy), пойдёт через ProtonVPN. Проверить можно так:
curl --socks5 127.0.0.1:7891 ifconfig.me
Исключение для Firefox
Firefox не учитывает org.gnome.system.proxy, даже при выборе Use system proxy settings. Насколько я знаю, это не особенность именно этой конфигурации - баг репортят на Firefox под Linux уже больше десяти лет. Вроде его так и не починили, только костыли,
Я просто вручную переключаюсь на SOCKS5 прямо в сетевых настройках Firefox. Между “Manual” и “No proxy” два клика, не так и долго, учитывая как редко я это делаю. Пробовал FoxyProxy. Стоит ставить, только если нужны правила по сайтам или переключатель на панели инструментов. Ещё пробовал переменную окружения MOZ_GTK_USE_PORTAL=1, которую иногда советуют, - в моих тестах она то работала, то не применялась, так что полагаться на неё не стал.
.