Пакет многоадресной рассылки не поступил внутрь подмана правильно. Обходной путь найден, но неясно, является ли это проблемой брандмауэра или проблемой подмана? - PullRequest
Новая
       93

Пакет многоадресной рассылки не поступил внутрь подмана правильно. Обходной путь найден, но неясно, является ли это проблемой брандмауэра или проблемой подмана?

0 голосов
/ 26 января 2020

Я схожу с ума от firewalld, podman и UDP / Multicast. Пока я вижу UDP-пакеты, поступающие в podman; подтверждено командой tcpdump. Кажется, я не могу настроить с помощью настроенной зоны firewalld с именем knx_multicast, которая должна принимать только когда пакет UDP от группы многоадресной рассылки 224.0.23.12:3671.

Приведенный минимальный пример, записанный в Java: 

import java.net.DatagramPacket;
import java.net.InetAddress;
import java.net.MulticastSocket;
import java.net.NetworkInterface;

public class Test {
    public static void main(String[] args) throws Throwable {
        final var group = InetAddress.getByName("224.0.23.12");
        final var s = new MulticastSocket(3671);

        final var ni = NetworkInterface.getByName("enp1s0");
        s.setNetworkInterface(ni);
        s.joinGroup(group);

        System.out.println("Start listening ... @" + ni );

        final var buf = new byte[1000];
        DatagramPacket recv = new DatagramPacket(buf, buf.length);
        s.receive(recv);

        System.out.println(recv.getData());

        s.leaveGroup(group);
        s.close();
    }

}

У меня firewalld настроен как: 

knx_multicast (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 224.0.23.12
  services: 
  ports: 3671/udp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 


public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp1s0
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Тестирование многоадресного пакета на CentOS 8.1

Теперь я протестировал первый в CentOS 8.1, работающем и это работает, когда я получаю некоторые данные (см .: [B@61a52fbd ниже) 

[root@PIT-Server ~]# javac Test.java && java Test
Start listening ... @name:enp1s0 (enp1s0)
[B@61a52fbd

Тестирование многоадресного пакета с использованием PODMAN на CentOS 8.1

Следующим шагом сейчас является тестирование в контейнере podman (изображение: 'accepttopenjdk / openjdk11: latest', работающее в "Ubuntu 18.04.3 LTS") с использованием: podman run --rm -it --net host docker.io/adoptopenjdk/openjdk11 /bin/bash

Внутри podman я также вижу, что UDP-пакеты поступают из PIT-KNX (маршрутизатор KNX). 

root@PIT-Server:/tcpdump -i enp1s0 udp port 3671
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:49:35.583901 IP PIT-KNX.pit-router.3671 > 224.0.23.12.3671: UDP, length 17
19:49:36.032139 IP PIT-KNX.pit-router.3671 > 224.0.23.12.3671: UDP, length 18
... lines omitted ...

Запуск того же приложения java (которое работало вне среды контейнера) Я не могу получить какие-либо данные (байтовый массив не поступил после "Начать прослушивание" ") 

root@PIT-Server:/# javac Test.java && java Test
Start listening ... @name:enp1s0 (enp1s0)

Работа вокруг (firewalld)

После исследования нескольких часов / кофе я выяснил, что разрешения порта в зоне = knx_multicast недостаточно. Я также должен добавить порт к zone=public, используя: firewall-cmd --add-port=3671/udp. Конфигурация firewalld теперь: 

knx_multicast (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 224.0.23.12
  services: 
  ports: 3671/udp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 


public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp1s0
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 3671/udp    <== ADDED!!!! (that one fixes the problem)
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Повторное тестирование многоадресного пакета с использованием PODMAN на CentOS 8.1

Перезапустив приложение java, я сейчас нахожусь возможность видеть прибывающий пакет многоадресной рассылки UDP (см .: [B@61a52fbd ниже) 

root@PIT-Server:/# javac Test.java && java Test
Start listening ... @name:enp1s0 (enp1s0)
[B@61a52fbd

Мои вопросы ... что случилось? Следующие шаги?

Может кто-нибудь помочь мне понять, в чем именно проблема? Почему я тоже должен добавить порт к zone=public? Это ошибка или проблема конфигурации на моей стороне? Как я могу решить это, не добавляя порт к zone=public? Есть ли у меня недопонимание?

Мне было бы удобнее добавить только новую зону огненного мира (называемую knx_multicast); и не изменяйте конфигурацию зоны firewalld public. Предложения?

Спасибо, Кристоф

1 Ответ

0 голосов
/ 27 января 2020

Спасибо @Ron Maupin за указание на проблему. Моя конфигурация брандмауэра была неправильной.

Проблема была решена путем создания новой службы: 

firewall-cmd --permanent --new-service=knx
firewall-cmd --permanent --service=knx --set-description="KNXnet/IP is a part of KNX standard for transmission of KNX telegrams via Ethernet"
firewall-cmd --permanent --service=knx --set-short=KNX
firewall-cmd --permanent --service=knx --add-port=3671/udp

Чтобы иметь возможность добавить вновь созданную службу, перезагрузите firewalld и добавьте его 

firewall-cmd --reload
firewall-cmd --permanent --add-service=knx

Это создаст служебный файл: /etc/firewalld/services/knx.xml со следующим содержимым: 

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>KNX</short>
  <description>KNXnet/IP is a part of KNX standard for transmission of KNX telegrams via Ethernet</description>
  <port port="3671" protocol="udp"/>
</service>

И конфигурация брандмауэра будет выглядеть так: 

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp1s0
  sources: 
  services: cockpit dhcpv6-client knx ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
...