Отладка маскарадинга iptables с мостом

Вопрос или проблема

Я создал сетевое пространство имен с одной половиной пары veth, другая половина находится в корневом пространстве имен, подключенном к мосту. Я создал правило маскарадинга iptables следующим образом:

sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 ! -o my-br -j MASQUERADE

где 10.0.0.0/24 — это подсеть для моего моста. Вывод команды ip route в корневом пространстве имен:

default via 192.168.88.1 dev wlo1 proto dhcp metric 600 
10.0.0.0/24 dev my-br proto kernel scope link src 10.0.0.1

Внутри сетевого пространства имен я успешно пингую мост на 10.0.0.1, а также хост на 192.168.88.198. Однако, если я пытаюсь пинговать какой-либо хост в публичном интернете, то мои ping’и не получают ответов:

$ sudo ip netns exec my-ns ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
(зависает)

Я включил IP-форвардинг.

Кажется, что мое правило маскарадинга не работает. Я вижу выходящие ICMP-пакеты через tcpdump, и никаких возвращающихся пакетов в другую сторону:

$ sudo tcpdump -i my-br icmp                            
прослушивание my-br, тип канала EN10MB (Ethernet), длина снимка 262144 байта
17:43:14.288051 IP 10.0.0.50 > dns.google: ICMP echo request, id 2477, seq 4, length 64
17:43:15.311982 IP 10.0.0.50 > dns.google: ICMP echo request, id 2477, seq 5, length 64
17:43:16.336076 IP 10.0.0.50 > dns.google: ICMP echo request, id 2477, seq 6, length 64

Если я сделаю то же самое на основной сетевой интерфейсе моего хоста, я ничего не вижу. Должен ли я ожидать увидеть что-то здесь, если маскарадинг работал? Я думал, что увижу выходящие ICMP-пакеты здесь, если бы это работало.

$ sudo tcpdump -i wlo1 icmp
прослушивание wlo1, тип канала EN10MB (Ethernet), длина снимка 262144 байта
(ничего нет)

У меня установлен docker. Возможно, его правила NAT каким-то образом мешают моей настройке? Подсеть, которую я использую, 10.0.0.x, похоже, не конфликтует с тем, что использует docker. Моя полная таблица iptables nat:

$ sudo iptables -t nat --list-rules
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N DOCKER
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 ! -o my-br -j MASQUERADE
-A DOCKER -i docker0 -j RETURN

Я не совсем понимаю, как это интерпретировать. Значит ли строка -N DOCKER, что все передается в цепочку docker?

Ответ или решение

Для решения проблемы с masquerade в вашей конфигурации сети с использованием namespace и моста, давайте рассмотрим несколько ключевых моментов.

Правила маскарада: Ваше правило маскарада выглядит верно, но есть некоторые нюансы, которые нужно учитывать. Вы используете следующее правило:
```
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 ! -o my-br -j MASQUERADE
```
Это правило применимо для исходящих пакетов с адресом из подсети 10.0.0.0/24, которые не выходят через интерфейс my-br. Однако, пакеты должны выйти через интерфейс, который имеет доступ в интернет (например, wlo1). Попробуем поправить правило, добавив другое правило для исходящих пакетов, чтобы они могли использовать интерфейс, выходящий в интернет:
```
sudo iptables -t nat -A POSTROUTING -o wlo1 -j MASQUERADE
```
Проверка перенаправления IP: Убедитесь, что IP-перенаправление включено. Это можно проверить с помощью:
```
cat /proc/sys/net/ipv4/ip_forward
```
Если результат 0, включите его:
```
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
```
Проблемы с Docker: У вас установлен Docker, который добавляет свои собственные правила NAT. Ваше правило для маскарада:
```
-A POSTROUTING -s 10.0.0.0/24 ! -o my-br -j MASQUERADE
```
не будет конфликтовать с правилами Docker, поскольку вы используете другую подсеть. Однако, если Docker изменяет поведение сети или правила маршрутизации, это может влиять на работу вашего маскарада.
Проверка маршрутизации: Убедитесь, что маршруты настроены правильно в вашей сетевой пространственной среде и на хост-машине. Внутри вашего namespace проверьте маршруты с помощью:
```
ip route
```
Убедитесь, что по умолчанию есть маршрут в интернет, например:
```
default via 10.0.0.1 dev <ваш_интерфейс>
```
Отладка трафика: Попробуйте использовать tcpdump для отслеживания трафика на интерфейсе wlo1 и убедитесь, что пакеты return приходят обратно:
```
sudo tcpdump -i wlo1 icmp
```
Если вы не видите ответа на ping, это может быть связано с тем, что ответ не возвращается или блокируется iptables или правилами маршрутизации.
Проверка iptables: Вся конфигурация iptables может быть проверена с помощью:
```
sudo iptables -L -v
```
Убедитесь, что правила INPUT и FORWARD разрешают трафик. Если у вас есть блокирующие правила, измените их.
Дополнительный анализ: Если после вышеизложенного пинг все еще не работает, вам может понадобиться просмотреть логи системы или использовать такие инструменты, как traceroute, чтобы отследить путь пакетов до их назначения.

Следуя этим шагам, вы сможете диагностировать и, вероятно, исправить проблему с маскарадом в вашей конфигурации. Если все удается, вы сможете успешно пинговать внешний адрес, выходя из вашего namespace.