Files
AuraVPN/docs/server_nat_fix.md
T
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

130 lines
5.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Чиним 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`):
```bash
# Собираем релизный бинарь под целевую архитектуру сервера.
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`
Если апгрейд бинаря пока не делаем, минимальный патч конфига:
```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 одинаково.
Узнать имя интерфейса:
```bash
ip route show default | awk '{print $5; exit}'
```
---
## Вариант C. Настроить NAT руками без участия Aura
Если по политике безопасности `aura server` не должен трогать nftables/iptables
(например, оператор сам управляет фаерволом), то делаем всё руками **и явно
выключаем implicit auto-NAT** через `[server.nat] auto = false`:
```bash
# 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):
```bash
# 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 теперь опт-аут, что отсекает основную
причину «впн не работает» из коробки.