IP fix

2026-06-27 00:39:28 +03:00
parent f4d04d5375
commit 90b69667c1
2 changed files with 65 additions and 20 deletions
@@ -91,10 +91,13 @@ post-up echo 1 > /proc/sys/net/ipv4/ip_forward
 post-up iptables -t nat -A POSTROUTING -s '192.168.100.0/24' -o enp7s0 -j MASQUERADE
 post-down iptables -t nat -D POSTROUTING -s '192.168.100.0/24' -o enp7s0 -j MASQUERADE

-post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
-post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
+post-up iptables -t raw -C PREROUTING -i fwbr+ -j CT --zone 1 2>/dev/null || iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
+post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1 2>/dev/null || true
 ```

+
+
+
 ## OVH

 ```bash
@@ -177,29 +180,71 @@ post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
 post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1 || true
 ```
 ```bash
-✅ Что было причиной
-В конфигурации контейнера был установлен firewall=1
+Проверил prox14 / тестовый LXC 111. Ничего не менял.

-Но Proxmox firewall был отключён (pve-firewall stop)
+  Что видно
+  CT 111:

-В итоге трафик из контейнера проходил в bridge, но обратно — не возвращался
+  net0: firewall=1, ip=192.168.100.24/24, gw=192.168.100.1

-После удаления firewall=1 — контейнер подключился напрямую к vmbr100, и всё заработало
+  Внутри контейнера:

-🧩 Что запомнить на будущее
-Компонент	Рекомендация
-bridge=vmbr100	Указывать в net0
-type=veth	Обязательно
-firewall=1	Оставлять только если firewall активен
-pve-firewall	Должен быть запущен, если включён firewall=1
-NAT (MASQUERADE)	Должен быть без -o, если bridge без портов
-ip_forward=1	Всегда включать
+  ping 192.168.100.1: OK
+  ping 1.1.1.1: FAIL
+  DNS: FAIL
+  curl наружу: timeout

-📦 Хочешь — могу сохранить тебе:
-шаблон interfaces с NAT и vmbr100
+  Хост prox14 в интернет ходит нормально. LXC без firewall=1 тоже ходит наружу. Значит проблема именно в связке firewall=1 + NAT.

-шаблон 500.conf (или net0) без firewall
+  Причина
+  На prox14 есть MASQUERADE:
+
+  -A POSTROUTING -s 192.168.100.0/24 -o enp7s0 -j MASQUERADE
+
+  Но отсутствует runtime raw-правило conntrack zone для fwbr+:
+
+  iptables-save -t raw
+  # raw table пустая, правила fwbr+ нет
+
+  При этом в /etc/network/interfaces оно прописано:
+
+  post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
+
+  Но в активных правилах его нет. Поэтому для LXC с firewall=1, которые проходят через fwbr/fwln/fwpr, NAT работает неправильно.
+
+  Это подтверждается conntrack:
+
+  src=192.168.100.24 dst=185.12.64.2 ... [UNREPLIED]
+  reply dst=192.168.100.24
+  mark=111
+
+  То есть пакет от CT 111 не получает нормальный SNAT на публичный IP 23.88.7.159; ответ ожидается обратно на приватный 192.168.100.24, что с интернета невозможно.
+
+  Для LXC без firewall conntrack другой:
+
+  src=192.168.100.29 dst=1.1.1.1 ...
+  reply dst=23.88.7.159
+  [ASSURED]
+  mark=0
+
+  Там NAT работает.
+
+  Как решить
+  Нужно восстановить raw conntrack-zone правило для firewall bridge:
+
+  iptables -t raw -C PREROUTING -i fwbr+ -j CT --zone 1 || \
+  iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
+
+  После этого новые соединения из LXC с firewall=1 должны начать NAT’иться корректно. Старые UNREPLIED conntrack-записи можно либо подождать, либо аккуратно удалить для
+  конкретного CT.
+
+  Постоянно лучше сделать idempotent-вариантом, а не голым -I, чтобы не плодить дубли после reload:
+
+  post-up iptables -t raw -C PREROUTING -i fwbr+ -j CT --zone 1 || iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
+  post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1 || true
+
+  Коротко: проблема не в правилах самого CT 111; outbound из него firewall разрешает. Проблема в отсутствующем активном raw/conntrack-zone правиле для fwbr+ после
+  переустановки prox14.

-команду на быструю проверку сети внутри LXC
 ```