Ubuntu 19.10 forward пакетов на USB Ethernet интерфейсе

[slbond86]

Имеется шлюз на ubuntu server
На нем есть три интерфейса
встроенный ethernet                - enp3s0   - смотрящий в сторону интернета
usb wi-fi адаптер                       - wlx(mac) - IP:192.168.4.1/24 раздающий интернет для wi-fi клиентов
usb ethernet adapter Dlink E100    - enx(mac) - IP:192.168.3.1/24 для подключение локальной сети

Есть необходимость клиенту wi-fi сети (IP:192.168.4.2) соединиться c клиентом сети LAN (IP:192.168.3.50)
Пинг от шлюза к 192.168.3.50 проходит.

Клиенту сети wi-fi добавлен доп маршрут
192.168.3.0  255.255.255.0       192.168.4.1       192.168.4.2     66

IPtables на шлюзе
Chain INPUT (policy ACCEPT)
Chain FORWARD (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)

Передача между интерфейсами разрешена
# grep forward /etc/sysctl.conf
net.ipv4.ip_forward = 1

Пинг от host (192.168.4.2) сети Wi-fi не идет. Пишет
Превышен интервал ожидания для запроса.

Пробовал поменять IP на адаптерах и подключить локальную сеть к адаптеру enp3s0

Пинг от host (192.168.4.2) сети Wi-fi пошел.

Значит какие-то проблемы с подключением USB/Ethernet адаптера.
Почему-то на нем не включается forwarding пакетов.

Как можно исправить данную проблему?

[valrust]

Давайте разбираться.

На шлюзе Ubuntu включена ли маршрутизация пакетов?

Код: [Выделить]

sysctl net.ipv4.ip_forward
Верно ли настроены IP адреса на шлюзе Ubuntu?

Код: [Выделить]

ip addr show
Какая таблица маршрутизации на шлюзе Ubuntu?

Код: [Выделить]

ip route show
Доступен ли клиент из LAN со шлюза Ubuntu?

Код: [Выделить]

ping -c4 192.168.3.50
Доступен ли клиент из WiFi со шлюза Ubuntu?

Код: [Выделить]

ping -c4 192.168.4.2

Так же нужны данные по таблицам маршрутизации на клиенте в LAN и на клиенте в WiFi. Если на клиентах Windows, то команда получения таблицы маршрутов

Код: [Выделить]

route print -4
Нужны выводы команд, которые лучше оформить в тег spoiler.

[slbond86]

Код: [Выделить]

Netbook:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Netbook:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.5/24 brd 192.168.2.255 scope global enp3s0
       valid_lft forever preferred_lft forever
5: wlp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: wlxcXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.1/24 brd 192.168.4.255 scope global wlxcXXXXXXXXXXX
       valid_lft forever preferred_lft forever
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 192.168.5.1/24 brd 192.168.5.255 scope global tun0
       valid_lft forever preferred_lft forever
8: enxXXXXXXXXXXX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/24 brd 192.168.3.255 scope global enxXXXXXXXXXXX
       valid_lft forever preferred_lft forever


Netbook:~$ ip route show
default via 192.168.2.1 dev enp3s0 onlink
192.168.2.0/24 dev enp3s0 proto kernel scope link src 192.168.2.5
192.168.3.0/24 dev enxXXXXXXXXXXX proto kernel scope link src 192.168.3.1
192.168.4.0/24 dev wlxcXXXXXXXXXXX proto kernel scope link src 192.168.4.1
192.168.5.0/24 dev tun0 proto kernel scope link src 192.168.5.1

Netbook:~$ ping -c4 192.168.3.50
PING 192.168.3.50 (192.168.3.50) 56(84) bytes of data.
64 bytes from 192.168.3.50: icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from 192.168.3.50: icmp_seq=2 ttl=64 time=1.84 ms
64 bytes from 192.168.3.50: icmp_seq=3 ttl=64 time=1.02 ms
64 bytes from 192.168.3.50: icmp_seq=4 ttl=64 time=1.70 ms

--- 192.168.3.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 1.016/1.504/1.841/0.314 ms


Netbook:~$ ping -c4 192.168.4.2
PING 192.168.4.2 (192.168.4.2) 56(84) bytes of data.

--- 192.168.4.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 75ms

Клиент Wi-fi (192.168.4.2)

Код: [Выделить]

Обмен пакетами с 192.168.4.1 по с 32 байтами данных:
Ответ от 192.168.4.1: число байт=32 время=2мс TTL=64
Ответ от 192.168.4.1: число байт=32 время=2мс TTL=64
Ответ от 192.168.4.1: число байт=32 время=5мс TTL=64
Ответ от 192.168.4.1: число байт=32 время=5мс TTL=64

Статистика Ping для 192.168.4.1:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 2мсек, Максимальное = 5 мсек, Среднее = 3 мсек


C:\WINDOWS\system32>netstat -r
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0       192.168.4.1       192.168.4.2     65
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
       192.168.3.0    255.255.255.0       192.168.4.1       192.168.4.2     66
      192.168.3.50  255.255.255.255       192.168.4.1       192.168.4.2     66
       192.168.4.0    255.255.255.0         On-link        192.168.4.2    321
       192.168.4.2  255.255.255.255         On-link        192.168.4.2    321
     192.168.4.255  255.255.255.255         On-link        192.168.4.2    321
       192.168.7.0    255.255.255.0       192.168.4.1       192.168.4.2     66
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link        192.168.4.2    321
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link        192.168.4.2    321
===========================================================================

Клиент LAN (192.168.3.50) raspberry

Код: [Выделить]

~$ netstat -r
Kernel IP routing table
Destination  Gateway      Genmask         Flags  MSS  Window  irtt  Iface
192.168.3.0  0.0.0.0      255.255.255.0   U      0    0          0  eth0
192.168.4.0  192.168.3.1  255.255.255.0   UG     0    0          0  eth0
192.168.7.0  0.0.0.0      255.255.255.0   U      0    0          0  wlan0


[valrust]

Netbook:~$ ping -c4 192.168.4.2
PING 192.168.4.2 (192.168.4.2) 56(84) bytes of data.

--- 192.168.4.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 75ms

Скорее всего из-за включённого сетевого экрана на клиенте Wi-fi (192.168.4.2) была 100% потеря пакетов.

Отключите сетевой экран или разрешите нужные порты и ICMP пакеты (для ping) на Клиент Wi-fi (192.168.4.2). А потом проверьте связь между клиентами.

[slbond86]

Да вы правы на клиенте Wi-fi (192.168.4.2). Я тоже обратил на это внимание когда копировал на форум вывод команды. Это блокирует входящие icmp пакеты Kassperskii на windows клиенте. Но это не мешает исходящим.

Как я обнаружил дело было в другом
 на стороне малины изначально не было маршрута:

~$ netstat -r
Kernel IP routing table
Destination  Gateway      Genmask         Flags  MSS  Window  irtt  Iface
192.168.3.0  0.0.0.0      255.255.255.0   U      0    0          0  eth0
192.168.4.0  192.168.3.1  255.255.255.0   UG     0    0          0  eth0
192.168.7.0  0.0.0.0      255.255.255.0   U      0    0          0  wlan0

Я добрался до малинки, подключил монитор, клавиатуру, и прописал его вручную пока ждал ответа на форуме.

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

Сейчас добавил маршрут по умолчанию и все заработало.

Большое спасибо за помощь.
Виноват. Сразу не сообразил.

[AnrDaemon]

Объедините оба интерфейса в мост с одним адресом и не мучайтесь.
Это в предположении, что в локалке и WiFi одни и те же клиенты.