Перейти к содержанию

Добавление Whitelist-сервера

Whitelist (WL) — серверы для обхода блокировок. Пользователь подключается к российскому proxy IP, тот через nftables DNAT форвардит трафик на реальный upstream VPN-сервер за рубежом.

Полный источник: docs/guides/WL-CREATE-NEW-ENTRIES-GUIDE.md (monorepo).

Архитектура записей

Страна (country)
  └─ Город (city) — "moscow_wl<код>"
       └─ Сервер (server, panel_type='WHITELIST')
            ├─ ip        = upstream VPN (реальный сервер)
            ├─ port      = порт прослушивания на proxy (2096, 443, 8443...)
            └─ change_ip = IP российского proxy (куда подключается клиент)

Каждый WL-сервер — одна строка в server с panel_type='WHITELIST'. Если нужны несколько портов — отдельная строка на каждый порт.

Шаг 1. Создать страну

INSERT INTO country (id, code, name_key, picture) VALUES (
  UUID(),
  'WDN',                  -- уникальный 3-х символьный код
  'whitelist_denmark',    -- уникальный name_key
  NULL
);

Код должен быть уникальным. Список занятых кодов: SELECT code FROM country WHERE code LIKE 'W%';

Шаг 2. Создать город

INSERT INTO city (id, name_key, country_id) VALUES (
  UUID(),
  'moscow_wldn',                                          -- конвенция: moscow_wl<код_lower>
  (SELECT id FROM country WHERE code='WDN')
);

Шаг 3. Создать записи сервера

Одна запись = один порт на одном proxy IP.

INSERT INTO server (id, name, ip, port, city_id, is_active, change_ip,
                   change_ip_enabled, panel_type, health_status, latitude, longitude) VALUES (
  UUID(),
  'vk-03-wldn-2096',                                      -- уникальное имя: <proxy>-<код>-<port>
  '10.99.87.X',                                           -- upstream VPN IP
  2096,                                                   -- порт на proxy (не upstream!)
  (SELECT id FROM city WHERE name_key='moscow_wldn'),
  1,
  '90.156.218.106',                                       -- proxy IP (куда идёт клиент)
  1,
  'WHITELIST',                                            -- обязательно!
  'HEALTHY',
  0.0, 0.0
);

Критичные поля

  • panel_type обязан быть 'WHITELIST'. Дефолт — 'XUI', что сломает логику.
  • ip = upstream VPN. change_ip = proxy RU. Не перепутать!
  • (change_ip, port) должна быть уникальной комбинацией — иначе конфликт на proxy.

Stealth-серверы (WLS, inbound 3)

Stealth маскируется под конкурентские VPN. Требует двух записей в MySQL на каждый upstream:

panel_type inbound_id Зачем
XUI 3 fill_configs добавляет клиентов на XUI-панель
WHITELIST 3 проксированный маршрут через RU proxy

Без XUI-записи fill_configs не знает про inbound → клиенты не добавляются → подключение отвергается.

Stealth порт: 10443 (NL/DE — 9443 после 13 Mar 2026, AT/CH/IT/PL — 10443).

Добавление в Whitelist-таб приложения

WL-страны, которые показываются в таблице "Whitelist" в приложении, задаются хардкодом в CountryServiceImpl.java. Добавить код туда — иначе страна будет доступна только через "Все" и не появится во вкладке Whitelist.

Добавить DNAT на proxy

После добавления записей добавить правило на соответствующем VK Cloud сервере:

# /etc/nftables.conf
iifname "ens3" tcp dport <port> counter dnat to <upstream_ip>:853  # WL (inbound 2)
iifname "ens3" tcp dport 10443 counter dnat to <upstream_ip>:10443  # WLS (inbound 3)

Применить без перезагрузки:

nft flush ruleset && nft -f /etc/nftables.conf

Flush обязателен

Без flush старые правила остаются в рантайме и матчат первыми.

Заполнить transport_params до активации

Для panel_type='WHITELIST' backend строит VLESS URL из server.transport_params (Reality params). Поле заполняется автоматически VCS transport_params_sync (~30 мин) после того как VCS подхватит XUI inbound.

Можно ускорить через ручные API-вызовы (все команды на backend 10.99.87.249):

# 1. VCS подхватывает сервер из MySQL
curl -X POST http://localhost:8000/api/v1/sync/mysql-servers -H "X-API-Key: KEY"

# 2. VCS читает inbounds с XUI панели по SSH
curl -X POST "http://localhost:8000/api/v1/sync/fast?force=true" -H "X-API-Key: KEY"

# 3. Ждать ~5 мин: transport_params_sync отработает автоматически после full_sync
#    Проверить что transport_params заполнен:
docker exec vpn-db mysql -uvpn -p'PASSWORD' vpn \
  -e "SELECT name, ip, port, LENGTH(transport_params) as tp_len FROM server WHERE ip='<UPSTREAM_IP>'"
# tp_len должен быть NOT NULL

# 4. Если tp_len всё ещё NULL — дождаться следующего цикла (30 мин) или перезапустить:
curl -X POST "http://localhost:8000/api/v1/sync/fast?force=true" -H "X-API-Key: KEY"

API key: Vaultwarden → Infrastructure → VPN Config Service. Подробнее: VPN Config Service → Операции.

Формат transport_params (берутся с TCP inbound, port 853): 

{
  "sni": "vk.com",
  "fingerprint": "random",
  "public_key": "...",
  "short_id": "a1b2c3d4"
}

Активация

UPDATE server SET is_active=1 WHERE name='vk-03-wldn-2096';

Backend автоматически создаёт конфиги для всех пользователей (~5 мин с заполненным transport_params).

Чеклист

  • country, city, server записи созданы
  • Уникальность: code, name_key, server.name, (change_ip, port)
  • panel_type='WHITELIST' проставлен
  • Код добавлен в CountryServiceImpl.java (Whitelist-таб)
  • DNAT правила на proxy добавлены и применены (nft flush ruleset && nft -f ...)
  • transport_params заполнен (автоматически VCS или вручную)
  • Протестировать DIRECT и WL-ссылки
  • is_active=1

Proxy IPs (актуальные)

Proxy IP Сервер
212.233.123.88 vk-01
90.156.214.48 vk-02
90.156.213.143 vk-03
83.166.239.199 vk-04
83.166.238.168 vk-05
83.166.235.99 vk-06
90.156.218.106 vk-07
90.156.219.233 vk-08
90.156.218.103 vk-09
37.139.35.61 vk-10

Доступные порты на proxy: 443, 2096, 2083, 8443, 51443, 52443, 57443, 59443.

Проверить занятые порты: SELECT port FROM server WHERE change_ip='90.156.218.106' ORDER BY port;

Связанные страницы