Выход через отдельный exit node
Как направить интернет-трафик одних клиентов через физический WAN другого Linux-клиента, не превращая сервер Qeli в точку выхода.
Потребитель → сервер → exit-клиент → интернет
Сервер пересылает пакеты между клиентами профиля. Exit-клиент принимает их из Qeli TUN, подменяет исходный адрес с помощью NAT и выпускает через свой физический WAN. Ответы возвращаются тем же путём.
| Роль | Ключевая настройка | Задача |
|---|---|---|
| Сервер Qeli | routing.client_to_client=true | Разрешает пересылку между клиентами |
| Exit-клиент | gateway=false + exit_node=true | Выпускает туннельный трафик в свой WAN |
| Клиент-потребитель | gateway=true | Отправляет публичный IPv4-трафик в Qeli |
gateway_nat заводит LAN за клиентом в туннель, а exit_node выводит трафик из туннеля в физический WAN клиента.Настройки сервера и двух клиентов
Exit-узел должен быть отдельным Linux-клиентом. Он остаётся в split-tunnel, иначе собственный default route может зациклиться через Qeli.
routing.client_to_client = true
# пользователь, под которым подключается exit-клиент
[user:exit]
profiles = main
client_subnet = 0.0.0.0/0
# обычный пользователь-потребитель; route=0/0 здесь не нужен
[user:consumer]
profiles = main
gateway = false
exit_node = true
gateway = true
kill_switch = true
0.0.0.0/0 как переключатель. Общий клиентский core фильтрует слишком широкие push-префиксы. Full-tunnel выбирается локальным gateway=true; client_subnet=0.0.0.0/0 у exit-пользователя решает другую задачу — регистрирует путь на сервере.exit_node=true вместе с gateway=true Qeli пишет предупреждение, но продолжает запуск. WAN-путь при этом пропадает, поэтому forwarding не работает — исправьте конфиг до старта.Что Qeli настраивает на exit-клиенте
При подключении Qeli автоматически включает forwarding, ослабляет reverse-path filtering на TUN/WAN и создаёт помеченные правила. WAN выбирается по default route с наименьшей метрикой; запасной способ — маршрут до 1.1.1.1.
| Слой | Действие |
|---|---|
| sysctl | net.ipv4.ip_forward=1, rp_filter=0 на TUN и WAN |
| mangle | Помечает пакеты TUN → WAN |
| nat | Подмена исходного адреса (MASQUERADE) только для помеченных пакетов при выходе в WAN |
| filter | Разрешает FORWARD в обе стороны и устанавливает TCPMSS clamp |
Правила идемпотентны, сохраняются при переподключении и удаляются при штатной остановке клиента. Все они имеют комментарий qeli-exit-node.
Проверка маршрута и NAT
journalctl -u qeli-client -b | grep 'Exit-node engaged'подтверждает активацию exit-режимаcurl -s https://api.ipify.org ; echoна потребителе должен показать публичный IP exit-узлаsudo iptables -t nat -L POSTROUTING -v -n | grep MASQUERADEсчётчики должны расти при трафике потребителяsudo iptables -t mangle -S | grep qeli-exit-nodeпоказывает правила маркировкиsudo iptables -S | grep qeli-exit-nodeпоказывает FORWARD и TCPMSSУдаляйте только правила с меткой Qeli
При crash процесс не успевает выполнить cleanup. Сначала выведите правила с комментарием qeli-exit-node, затем для каждой точной строки замените -A на -D и выполните её в той же таблице. Не очищайте цепочки целиком.
sudo iptables -t mangle -S | grep qeli-exit-node
sudo iptables -t nat -S | grep qeli-exit-node
sudo iptables -S | grep qeli-exit-node
net.ipv4.ip_forward=0 и прежнее значение rp_filter только если до Qeli они действительно были другими: узел может обслуживать и другие маршрутизаторы.Платформа, стоимость и ответственность
| Exit-платформа | Только Linux-клиент с iptables и правами на сеть; потребители могут быть любыми актуальными клиентами |
|---|---|
| Путь | Двойной сетевой переход повышает задержку и расходует канал сервера и exit-узла |
| Публичный IP | Внешние сервисы видят адрес exit-узла; его владелец отвечает за выходящий трафик |
| Сам сервер | Если нужен выход через публичный IP сервера, используйте обычный full-tunnel и серверный NAT — exit_node не требуется |