Пинг пропускает правила iptables / postrouting

У меня есть сервер с установкой Proxmox и только 1 исходящим соединением (eth0).

Чтобы заставить машины объединяться в сеть, я создал сетевой мост (vmbr0) в конфигурации интерфейсов и настроил его в соответствии с сетевой моделью Proxmox (Subpoint NAT).

Мост имеет IP 10.1.1.1 и действует в моем понимании как проход между локальной сетью и широким миром.

Для этого на сервере реализованы следующие политики iptable:

 Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 10.1.1.0/24 anywhere ACCEPT all -- anywhere 10.1.1.0/24 Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 10.1.1.0/24 anywhere to:xxxx 

Когда я отправляю эхо-запрос на DNS-сервер Google с одного из виртуальных серверов, установленных на сервере и подключенных через мост, используя ping 8.8.8.8 : ping 8.8.8.8 , ping 8.8.8.8 может получить результат ping с DNS-сервера Google, поэтому кажется, что NAT работает.

(Nat снова для всей подсети (10.1.1.0/24))

Если я ping -I vmbr0 8.8.8.8 : ping -I vmbr0 8.8.8.8 на хост-компьютере, команда ping завершится неудачно. Эта команда проверки связи использует интерфейс моста для проверки связи с DNS-сервером Google, и я ожидал, что политики POSTROUTING позволят ему также устанавливать связь с DNS-сервером Google.

Короче говоря, когда другие клиенты используют мост в качестве шлюза, они могут подключаться к Интернету, но если в качестве исходящего интерфейса выбран сам интерфейс, он не может найти маршрут.

Таким образом, это приводит меня к моему вопросу: явно ли используется интерфейс, каким-то образом пропускающий правила пост-маршрутизации, и действительно ли он считается абсолютной конечной точкой для маршрутизации на соответствующей машине? - in a sense: vmbr0 stays vmbr0 and never will be masqueraded to eth0 if you choose to ping over it -

man ping , жирным шрифтом мой

-Я интерфейс
Интерфейс – это либо адрес , либо имя интерфейса . Если интерфейс является адресом , он устанавливает адрес источника в указанный адрес интерфейса. Если интерфейс в имени интерфейса , он устанавливает исходный интерфейс для указанного интерфейса.

Проблема заключается в принудительном использовании интерфейса с помощью ping -I vmbr0 вместо того, чтобы система в конце концов выбрала правильный интерфейс с помощью ping -I 10.1.1.1 .

Кроме того, даже если это не имеет значения для nat/POSTROUTING (см. nat/POSTROUTING ), вы должны понимать, что вы не выполняете маршрутизацию при запуске команды на хосте, поэтому некоторые цепочки (например, filter/FORWARD ) могут не применяться (но nat/POSTROUTING все еще делает, см. позже). Имейте в виду, что это может дать разные результаты при запуске команд на хосте вместо маршрутизируемой виртуальной машины в зависимости от ваших правил, даже если это не так с правильной командой ping.

этот stream пакетов в схеме Netfilter и General Networking показывает, что после прохождения различных цепочек OUTPUT для пакета, поступающего от локального процесса, nat/POSTROUTING все еще проходит после, так что да, если бы ваш пакет выходил наружу через eth0 он все равно SNATed: это с помощью ping -I 10.1.1.1 8.8.8.8

Вместо этого при форсировании интерфейса с помощью ping -I vmbr0 8.8.8.8 , если вы запустите tcpdump на vmbr0 вы, скорее всего, увидите ARP-запросы от 10.1.1.1 до 8.8.8.8, которые не будут получать ответы.

И последний вопрос: да, форсирование маршрута не может позволить пакету отправиться в нужное место назначения. Вы никогда не vmbr0 маскировать vmbr0 , потому что SNAT / MASQUERADE выполняется для IP-пакетов , а не для интерфейса, и его применение зависит от их маршрута к месту назначения.