# Сценарии использования Практические схемы применения Qeli: что настраиваем, какие данные нужны, готовые конфиги, порядок запуска, проверка и восстановление после перезагрузки. [Карта документации](../index.md) · [English](../../eng/scenarios/README.md) | Сценарий | Задача | Версия и проверка | | --- | --- | --- | | [VPS как full-tunnel VPN](FULL-TUNNEL.md) | Выход устройства в интернет через VPS, NAT и tunnel DNS | Настройки 0.8.4; IPv6 и блокировка без VPN проверяются отдельно | | [IPv4 и IPv6 через один VPN](DUAL-STACK.md) | Полный dual-stack через VPS, NAT44/NAT66 или маршрутизируемый IPv6-префикс | Адресный план, DNS, required/auto, проверки обеих семей и отказов | | [Доступ только к домашней сети](HOME-LAN.md) | NAS, камеры и LAN без смены интернет-шлюза клиента | Маршрутизация без NAT с обязательным обратным маршрутом | | [Несколько профилей на сервере](MULTI-PROFILE.md) | Отдельные TCP/UDP listeners, порты, TUN и пулы | Полный шаблон серверных профилей и отдельные ключи | | [Основной и резервный канал](PRIMARY-BACKUP.md) | Reality TLS и UDP QUIC на одном сервере | Резерв выбирается вручную; roaming не переключает профили | | [Раздельная маршрутизация ресурсов](SPLIT-ROUTING.md) | Выбор IP/CIDR через VPN или напрямую | Матрица include/exclude, server push и desktop route_file | | [Мобильная и нестабильная сеть](MOBILE-ROAMING.md) | Смена Wi-Fi/LTE, сон, reconnect и MTU | Roaming auto; ограничения платформ остаются существенными | | [Две локальные сети](SITE-TO-SITE.md) | Соединить площадки через центральный сервер | Linux-шлюзы, client_subnet, forwarding и ACL без NAT | | [Интернет через домашний выходной узел](EXIT-NODE.md) | Выход других клиентов через WAN Linux-клиента за NAT | exit_node только на Linux; права на выход выдаются по семействам IP | | [Только выбранные приложения](PER-APP.md) | Разделить VPN-трафик по приложениям | Windows/Android; macOS требует подписанных extensions, iOS — MDM | | [Внешний TUN или TAP](EXTERNAL-TUN.md) | Передать сетевую политику внешнему владельцу интерфейса | Linux dev_attach; создание, маршруты и удаление остаются владельцу | | [Личные, домашние и гостевые профили](ACCESS-PROFILES.md) | Раздельные пользователи, разрешения и лимиты | profiles и allowed_networks; отдельные учётные данные на устройство | | [Клиент → A → B → Интернет](CHAINED-SERVERS.md) | Подключить клиентов к A и направить их трафик через B, сохранив собственные маршруты серверов; встроенный клиент, INI-hooks и автозапуск | Исправление reconnect в планируемой 0.8.4 проверено на кандидате; root — испытан, User=qeli — отдельная квалификация не проводилась | Для установки самого Qeli начните с [GETTING-STARTED](../manuals/GETTING-STARTED.md). Полные параметры находятся в [CONFIG](../manuals/CONFIG.md); здесь описываются готовые комбинации настроек, а не дублируется справочник. ## Перед настройкой Сценарии соответствуют задачам [раздела сайта](https://qeli.ru/docs/scenarios/), но содержат отдельные процедуры настройки для кандидата **0.8.4 Beta**. Публикацию и доступные пакеты проверяйте в GitHub Releases; ссылки на 0.8.4 начнут работать после публикации. Мануал цепочки отдельно отмечает изменение `post_up`, требующее 0.8.4. Наличие инструкции не означает, что каждая ОС и топология прошла новый runtime-прогон. Сначала установите сервер и клиент по [GETTING-STARTED](../manuals/GETTING-STARTED.md) и добейтесь обычного подключения. Сохраните работающие transport/auth-параметры: `server`, `proto`, `mode`, `key`, `sni` и `reality_sid` должны соответствовать профилю. Берите ключ и `qeli://` из доверенного канала, не отключайте `bind_static` ради примера. В сетевых фрагментах `[profile:main]` — условное имя **существующего** профиля. Замените его на своё, а строки объедините с текущей секцией; не добавляйте второй listener на уже занятый адрес/порт. Фрагменты не заменяют полный серверный конфиг. Не дублируйте `[qeli]` или `[user:*]`: редактируйте соответствующие секции. Адреса `10.9.0.0/24`, `192.168.50.0/24`, `192.168.60.0/24` и имена интерфейсов — пример; выберите непересекающиеся с вашими сетями. `203.0.113.0/24` и `198.51.100.0/24` зарезервированы для документации, не являются списком стран. Команды управления пользователями и identity выполняйте от владельца службы и конфигов: для штатного пакета обычно `sudo -u qeli qeli ...`. Не меняйте службу на root ради этих сценариев. Для Linux-маршрутов, firewall и TUN нужны отдельные сетевые права; сохраните действующие capabilities и ограничения unit. Перед изменением сохраните конфиги, `users.conf`, права/владельцев, маршруты и drop-in службы в закрытом резервном каталоге. Сохраняйте SSH или консоль вне VPN. Новые пароли создавайте через `add-client` или панель; не передавайте настоящий пароль через `--password`, историю shell или публичный отчёт. ### Tunnel DNS на Linux Для `dns=tunnel` Linux-клиенту нужен работающий `systemd-resolved`, используемый системным резолвером. Qeli проверяет фактические `nameserver` в `/etc/resolv.conf` (`127.0.0.53`/`127.0.0.54`), а не только имя symlink; одного установленного `resolvectl` недостаточно. Перед подключением проверьте: ```sh systemctl is-active systemd-resolved readlink -f /etc/resolv.conf resolvectl status ``` Проверьте также содержимое `/etc/resolv.conf`: сторонний upstream рядом со stub не соответствует этому контракту. Доступ к resolved и нужному network namespace должен быть у процесса клиента. При несовместимой конфигурации Qeli откажет в применении DNS, а не начнёт незаметно переписывать чужой resolver. Если DNS обслуживает NetworkManager/dnsmasq/прошивка, согласуйте его настройку с владельцем сети по [CONFIG](../manuals/CONFIG.md). `dns=off`/`system` оставляет системный resolver вне управления Qeli и не является автоматическим безопасным исправлением ошибки: отдельно обеспечьте маршрут DNS и отсутствие нежелательного прямого разрешения. Не заменяйте `/etc/resolv.conf` вслепую на удалённом хосте. ## Общая проверка и откат До перезапуска проверьте оба **полных** конфига: ```sh sudo -u qeli qeli check-config --config /etc/qeli/server.conf sudo qeli check-config --client --config /etc/qeli/client.conf ``` Вторую команду запускайте с UID и путём фактического Linux-клиента; в GUI сохраните полный профиль через штатный редактор. Перезапуск `qeli.service` разрывает соединения всех его профилей; согласуйте окно и проверьте имя своей службы. После запуска проверьте журнал, маршрут к целевому IP, DNS, разрешённые и запрещённые направления, обе семьи IP и поведение при потере связи. Один статус «Подключено» или успешный ping не подтверждает весь сценарий. Внешний IP проверяется, например, через `curl -4 https://api.ipify.org` и, при наличии IPv6, `curl -6 https://api64.ipify.org`. Это сторонние сервисы; вместо них можно использовать свой проверочный endpoint. Для отката сначала штатно остановите затронутые подключения, верните сохранённые конфиги с прежними правами и отмените **только свои** добавленные маршруты/правила. Запустите прежнюю схему и повторите проверку. Не очищайте весь firewall и не удаляйте журналы DNS/sysctl/route recovery для обхода ошибки: используйте [восстановление](../manuals/OPERATIONS.md). ## Результаты проверки цепочки - [Кандидат 0.8.4: повтор post_up, автозапуск и reboot A/B](../reports/CHAINED-SERVERS-084-2026-10-30.md). - [Историческая проверка INI-hooks и очистки на 0.8.3](../reports/CHAINED-SERVERS-HOOKS-2026-10-30.md). - [Исходная проверка цепочки C → A → B](../reports/CHAINED-SERVERS-2026-10-30.md). Новые сценарии размещаются отдельными файлами в этом каталоге с такими же путями в RU/EN. Указывайте требования к версии и правам, способ проверки и границы испытаний; добавляйте ссылку в этот каталог. Отчёты и ссылки на расположение raw остаются в reports/; сами лабораторные raw сюда не переносятся. [Старый адрес инструкции](../manuals/CHAINED-SERVERS.md) сохранён для прежних ссылок; актуальный документ находится в этом разделе.