Назад | Перейти на главную страницу

Поведение ARP при использовании VPN-моста

У меня проблемы с подключением инфраструктуры через VPN. У меня мало прав на виртуальную машину, которую я использую, поэтому сложно дать вам точную информацию, поэтому эта тема должна быть теоретической.

Есть 3 интерфейса:

Вот конфигурация ifconfig:

br-dd5a54c6d409: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::42:2fff:fec9:ba04  prefixlen 64  scopeid 0x20<link>
        ether 02:42:2f:c9:ba:04  txqueuelen 0  (Ethernet)
        RX packets 5019  bytes 549801 (536.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5791  bytes 676602 (660.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 02:42:b4:34:2c:04  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.160.10  netmask 255.255.254.0  broadcast 192.168.161.255
        inet6 fe80::215:5dff:fe38:10b  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:38:01:0b  txqueuelen 1000  (Ethernet)
        RX packets 7819  bytes 1062488 (1.0 MiB)
        RX errors 0  dropped 4345  overruns 0  frame 0
        TX packets 770  bytes 48554 (47.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Проблема в том, что когда я подключаю устройство к коммутатору, к которому подключен eth0, и даю адрес в 192.168.0.0/24 (например, 192.16.0.1), устройство отправляет ARP-запрос для предотвращения дублирования IP-адреса (нормальное поведение) , но есть ответ ARP от виртуальной машины, который сообщает мне, что IP-адрес в настоящее время используется (проверьте выделенный пакет).

Кстати, это правда, потому что один из контейнеров использует этот IP-адрес, но поскольку мое устройство не связано с VPN, виртуальная машина не должна отвечать на запрос ARP, верно? Только устройство, которое подключено через VPN, должно получать ARP-пакет?

Я думал, что этот прокси-сервер был включен, поэтому поведение было бы нормальным, но похоже, что нет

[support@TPE-HOST ~]$ cat /proc/sys/net/ipv4/conf/br-dd5a54c6d409/proxy_arp
0
[support@TPE-HOST ~]$ cat /proc/sys/net/ipv4/conf/eth0/proxy_arp
0

Чтобы предотвратить это, я предложил добавить в сеть VLAN, которая полностью разъединит интерфейс, но клиент не хочет, чтобы это решение было в его сети.

Итак, теперь я полностью потерялся, существовал ли механизм, который мог вызвать эту проблему?