История изменений
Исправление aicg, (текущая версия) :
#iptables -vn -L FORWARD
Chain FORWARD (policy ACCEPT 101M packets, 93G bytes)
pkts bytes target prot opt in out source destination
sysctl net.bridge.bridge-nf-call-iptables = 1
Интерфейсов куча, суть в том что на хосте есть куча физ интерфейсов, которые прокинуты в контейнер и вот контейнере уже рулит всем трафиком и не только.
Т.е. в оригинале это все шло именно в него, и на нем уже настроены iptables’ы и прочие, а на хосте вообще у всего этого даже IP нету и iptables пустой, только на одном из мостов IP прокинут в безопасную зону.
И вот для чистоты экспиримента я закинул сам. физ интерфейс на хосте в отдельный netns без моста (а net.bridge.bridge-nf-filter-vlan-tagged вообще везьде 0), и в этом же netns сделал ip link add … eth80.5
Так что родительский iptables влиять на него никак не должен вообще, хотя и он и в этом netns они пустые с полным разрешением.
И в мостах интерфейс не состоит.
Более того, как я уже писал, если в том же netns все тоже, просто без vlan напрямую IP на интерфейсе получить выключив тэгирование, то все работает.
И конструкция вида host:vlan - netns - мост - veth - lxc - veth - netns - cont:vlan (netns’ы делал, что бы IP не пересикались) нормально пропускала трафик между host-cont vlan’ами, но выдавали ту же картину для gw.
При этом на другой машине, тоже с lxc, тоже с nf-call…iptables, так же выдавив все в netns в том же vlan на том же свитче, все работает (в смысле тестовая может tcp шлюзу и gw, но server не может tcp к gw и тестовой машине).
Т.е. еще раз: в рамках одного netns iptables пустой все в accept, и нет моста, и route/rule девственно чист кроме шлюза этого самого 192.168.66.1, другие мосты и контейнеры не имеют к нему отношения.
Но на всякий я вообще во всех iptables’а делал accept на все, и маркировку пакетов отключал в контейнере (хотя и не знаю каким боком оно может влиять).
Если бы сервер был не рабочий и можно было бы все погасить остальное вопросов бы не было… Может это вообще глюк, я на как-том из позапрошлогодних ядер центоси ловил странные вещи с netns’ами лечащиеся только ребутом, но пока ищу логическое объяснение.
Исходная версия aicg, :
#iptables -vn -L FORWARD
Chain FORWARD (policy ACCEPT 101M packets, 93G bytes)
pkts bytes target prot opt in out source destination
sysctl net.bridge.bridge-nf-call-iptables = 1
Интерфейсов куча, суть в том что на хосте есть куча физ интерфейсов, которые прокинуты в контейнер и вот контейнере уже рулит всем трафиком и не только.
Т.е. в оригинале это все шло именно в него, и на нем уже настроены iptables’ы и прочие, а на хосте вообще у всего этого даже IP нету и iptables пустой, только на одном из мостов IP прокинут в безопасную зону.
И вот для чистоты экспиримента я закинул сам. физ интерфейс на хосте в отдельный netns без моста (net.bridge.bridge-nf-filter-vlan-tagged = 0), и в этом же netns сделал ip link add … eth80.5
Так что родительский iptables влиять на него никак не должен вообще, хотя и он и в этом netns они пустые с полным разрешением.
И в мостах интерфейс не состоит.
Более того, как я уже писал, если в том же netns все тоже, просто без vlan напрямую IP на интерфейсе получить выключив тэгирование, то все работает.
И конструкция вида host:vlan - netns - мост - veth - lxc - veth - netns - cont:vlan (netns’ы делал, что бы IP не пересикались) нормально пропускала трафик между host-cont vlan’ами, но выдавали ту же картину для gw.
При этом на другой машине, тоже с lxc, тоже с nf-call…iptables, так же выдавив все в netns в том же vlan на том же свитче, все работает (в смысле тестовая может tcp шлюзу и gw, но server не может tcp к gw и тестовой машине).
Т.е. еще раз: в рамках одного netns iptables пустой все в accept, и нет моста, и route/rule девственно чист кроме шлюза этого самого 192.168.66.1, другие мосты и контейнеры не имеют к нему отношения.
Но на всякий я вообще во всех iptables’а делал accept на все, и маркировку пакетов отключал в контейнере (хотя и не знаю каким боком оно может влиять).
Если бы сервер был не рабочий и можно было бы все погасить остальное вопросов бы не было… Может это вообще глюк, я на как-том из позапрошлогодних ядер центоси ловил странные вещи с netns’ами лечащиеся только ребутом, но пока ищу логическое объяснение.