Маршрутизация и server push

Шесть механизмов — шесть разных задач

Сначала определите направление: нужно отправить маршрут клиенту, разрешить назначение, зарегистрировать сеть за клиентом или завернуть весь трафик устройства.

Split-tunnel и full-tunnel

Режим по умолчанию зависит от клиента: Linux CLI стартует в split-tunnel, GUI-клиенты — в full-tunnel. В split-режиме через Qeli идут TUN-пул и выданные сервером маршруты; для интернет-egress в full-tunnel нужен NAT на сервере.

# split-tunnel: только TUN-пул, server-push и include
gateway = false
include = 10.50.0.0/16
exclude = 203.0.113.0/24

# full-tunnel: весь остальной трафик тоже через Qeli
gateway = true
kill_switch = true

# нужно для выхода full-tunnel в интернет
routing.nat.enabled = true
# WAN определяется автоматически; при необходимости задайте явно
routing.nat.interface = ens3

Профильные и персональные маршруты

Ключ повторяемый. CIDR обязателен и пишется первым; gateway и metric необязательны. Типовой next-hop — tun.address сервера.

# получат все пользователи профиля
route = 192.168.50.0/24 gateway=10.9.0.1 metric=100
route = 10.50.0.0/16

[user:contractor]
# получит только этот пользователь
route = 192.168.50.128/25 gateway=10.9.0.1

Загрузка IP-адресов и подсетей через route_file

route_file подключает один или несколько внешних файлов к локальному split-tunnel. Ключ можно повторять; записи из всех файлов объединяются с include, канонизируются и дедуплицируются.

# Windows
gateway = false
route_file = C:\qeli\corp-routes.txt
route_file = C:\qeli\openvpn-routes.txt

# macOS: используйте абсолютный путь
# route_file = /Users/alice/.config/qeli/routes.txt

# одна сеть на строку
10.20.0.0/16
192.0.2.0/24      # филиал

; один IPv4-адрес записывается как /32
203.0.113.17/32
route 172.16.9.7 255.255.0.0 vpn_gateway 10
route-ipv6 2001:db8:42::/48

ACL назначения и сеть за клиентом

allowed_networks ограничивает исходящие назначения пользователя. client_subnet сообщает серверу, что указанный CIDR достижим через этого клиента. Эти ключи не заменяют друг друга.

[user:branch-a]
static_ip = 10.9.0.10
# сеть находится ЗА branch-a: входящий iroute на сервере
client_subnet = 192.168.50.0/24
# сам branch-a может ходить только сюда
allowed_networks = 10.9.0.0/24, 192.168.60.0/24

Пустой allowed_networks означает отсутствие ACL-ограничения, а не запрет всего. Сеть client_subnet должна быть непересекающейся с pool.cidr и сетями других площадок.

Минимальный site-to-site без NAT

Каждый шлюз получает фиксированный адрес, регистрирует свою LAN через client_subnet и получает персональный маршрут к LAN второй площадки.

[user:branch-a]
static_ip = 10.9.0.10
client_subnet = 192.168.50.0/24
route = 192.168.60.0/24 gateway=10.9.0.1

[user:branch-b]
static_ip = 10.9.0.11
client_subnet = 192.168.60.0/24
route = 192.168.50.0/24 gateway=10.9.0.1

# сервер, [profile:main]
routing.nat.enabled = false
routing.forward_private = true
routing.client_to_client = true

# каждый Linux-шлюз, [qeli]
forward = true

Дополнительные механизмы маршрутизации

Эти параметры не заменяют route и route_file: они управляют NAT, выбором приложений, IPv6 или жизненным циклом интерфейса на конкретном клиенте.

Прокси DNS и адрес, который получает клиент

dns.enabled поднимает прокси на сервере. dns.push_servers отдельно определяет, какой адрес будет передан клиентам.

Как клиенты применяют push-маршруты

Все актуальные клиенты применяют CIDR. Необязательные next-hop и metric зависят от платформы, поэтому не используйте их как единственный механизм приоритизации.

Как понять, где потерялся маршрут

Проверяйте последовательно: конфиг сервера, фактический push, таблицу маршрутов клиента, forwarding и NAT/firewall.

На клиенте ищите строку Pushed route applied. Если push виден в логе, но маршрута нет в ОС, проблема уже в платформенном применении, конфликте таблиц или правах.

Полное описание маршрутизации