Files
AuraVPN/docs/server_nat_fix.md
xah30 15c7da12fe fix(server): v3.6 — implicit auto-NAT on Linux (root cause of full-VPN dying)
Symptoms: in default = "VPN" full-VPN mode external internet was dead even
though tunnel-internal ping (10.7.0.1) worked perfectly. The tunnel itself
was assembled and AEAD-encrypted (see TEST_CASES.md), but packets sent
through it died on the server side.

Root cause: server's `[server.nat]` was opt-in. On the production server
(187.77.67.17) deployed before v2, the section is absent in
/etc/aura/server.toml, so `aura server` never ran the iptables MASQUERADE
plan. Packets egressed to the upstream router with src = 10.7.0.10 (RFC1918),
which the provider's reverse-path filter dropped — full-VPN clients saw
"internet is dead". Tunnel-internal pool addresses worked because they
don't need NAT.

Fix:
* `server.rs`: when `[server.nat]` is absent in server.toml AND we are on
  Linux, attempt auto-NAT with an auto-detected egress_iface. If detection
  or the iptables call fails we DON'T bail — we log a loud error and let
  the server come up so safe-mode clients keep working.
* `config.rs`: `ServerNatSection::default()` now defaults `auto = true`.
  A bare `[server.nat]` header (no `auto =`) now means "yes, enable it"
  instead of the silent-noop it used to be.
* New tests for both bare-header and explicit `auto = false` opt-out paths.
* `docs/server_nat_fix.md`: step-by-step instructions for fixing the
  existing 187.77.67.17 server (binary upgrade vs. manual server.toml
  patch vs. fully-manual sysctl + iptables).
* `docs/deployment.md`: replaces "manual mandatory step" wording with
  the new auto-NAT story.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-01 14:11:24 +03:00

5.9 KiB
Raw Permalink Blame History

Чиним full-VPN на старом сервере (v3.6)

Если сервер aura server был развёрнут до v3.6 — клиенты в default = "DIRECT" работают (пинг 10.7.0.1 идёт), но в default = "VPN" весь внешний интернет «гаснет». Корневая причина: на сервере не настроен SNAT/MASQUERADE для пула 10.7.0.0/24. Пакеты с приватным src=10.7.0.10 уходят в интернет, а ответы дропаются провайдером (RFC1918 reverse-path filtering).

В v3.6 у aura server появился implicit auto-NAT: если в server.toml нет секции [server.nat], сервер сам пытается включить ip_forward = 1 и поставить правило MASQUERADE на интерфейс по умолчанию (с автодетектом). Поэтому самый простой фикс — обновить бинарь на сервере и перезапустить.

Если по каким-то причинам так нельзя (нет рутового доступа на момент апгрейда, нестандартная сеть, контейнер без NET_ADMIN, и т.д.) — два альтернативных варианта.


Вариант A. Обновить бинарь (рекомендуется)

С локальной машины (откуда есть ssh root@187.77.67.17):

# Собираем релизный бинарь под целевую архитектуру сервера.
cargo build --release -p aura-cli --target x86_64-unknown-linux-gnu

# Заливаем и подменяем.
scp target/x86_64-unknown-linux-gnu/release/aura root@187.77.67.17:/usr/local/bin/aura.new
ssh root@187.77.67.17 'systemctl stop aura.service \
    && mv /usr/local/bin/aura.new /usr/local/bin/aura \
    && systemctl start aura.service \
    && systemctl status aura.service --no-pager -n 30'

В логе journalctl -u aura.service -n 30 должна появиться строка вида:

INFO aura::nat: v3.6 implicit auto-NAT: no [server.nat] section in server.toml —
     enabling IPv4 forwarding + MASQUERADE on the host's default egress.
     iface=eth0 pool=10.7.0.0/24
INFO aura::nat: running: sysctl -w net.ipv4.ip_forward=1
INFO aura::nat: running: iptables -t nat -A POSTROUTING -s 10.7.0.0/24 -o eth0 -j MASQUERADE
INFO aura::nat: auto-NAT applied (linux)

Если эти строки на месте — full-VPN на клиенте должен заработать сразу, без правки client.toml или server.toml.


Вариант B. Точечно дописать [server.nat] в server.toml

Если апгрейд бинаря пока не делаем, минимальный патч конфига:

# /etc/aura/server.toml — добавить блок в конец файла
[server.nat]
auto = true
egress_iface = "eth0"   # ваш интернет-интерфейс; обычно eth0/ens3/enp1s0
dry_run = false

Затем systemctl restart aura.service. Это работает на v2+ и на v3.6 одинаково.

Узнать имя интерфейса:

ip route show default | awk '{print $5; exit}'

Вариант C. Настроить NAT руками без участия Aura

Если по политике безопасности aura server не должен трогать nftables/iptables (например, оператор сам управляет фаерволом), то делаем всё руками и явно выключаем implicit auto-NAT через [server.nat] auto = false:

# 1. IP-форвардинг — навсегда.
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-aura.conf
sudo sysctl --system

# 2. MASQUERADE — оператор сам выбирает inframework (iptables/nftables/etc).
sudo iptables -t nat -A POSTROUTING -s 10.7.0.0/24 -o eth0 -j MASQUERADE
sudo apt-get install -y iptables-persistent && sudo netfilter-persistent save

# 3. Сказать aura не лезть.
cat >> /etc/aura/server.toml <<'EOF'

[server.nat]
auto = false
EOF
sudo systemctl restart aura.service

Проверка после фикса

На клиенте (Mac):

# 1) Туннель собран? Должно быть 5/5 и RTT ~70 мс.
ping -c 5 10.7.0.1

# 2) Внешний интернет реально через VPN? IP должен быть IP сервера (не Mac'а).
curl -sS https://ifconfig.co
curl -sS https://ifconfig.co/json | jq .ip,.country

# 3) DNS отвечает?
dig +short cloudflare.com

Если ifconfig.co возвращает IP сервера (187.77.67.17 в нашем случае) — full-VPN действительно работает. Если возвращает прежний IP мобильного оператора — что-то ещё не так и стоит смотреть journalctl -u aura.service -f на сервере.

Откуда вообще проблема

См. crates/aura-cli/src/server.rs (комментарий «Auto-NAT» вокруг проверки cfg.server.nat) и crates/aura-cli/src/nat.rs (linux_apply_plan): до v3.6 секция [server.nat] была опт-ин — без неё сервер вообще не трогал host networking, и оператор должен был помнить ручные sysctl + iptables из docs/deployment.md §2.4. Если оператор этого не сделал, single-IP-туннель работал (пинг внутреннего 10.7.0.1 идёт без NAT), но full-VPN — нет. v3.6 переворачивает поведение: NAT теперь опт-аут, что отсекает основную причину «впн не работает» из коробки.