У меня проблемы с подключением инфраструктуры через 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, которая полностью разъединит интерфейс, но клиент не хочет, чтобы это решение было в его сети.
Итак, теперь я полностью потерялся, существовал ли механизм, который мог вызвать эту проблему?