Компания, в которой я работаю, производит и продает промышленное оборудование. Один из наших продуктов - это машина, которой управляет ПК под управлением Windows. Эта конкретная машина использует сетевое устройство с цифровыми входами и выходами, подключенными к машине. Наше программное обеспечение отправляет команды по сети Ethernet для чтения и записи значений точек ввода-вывода на этом устройстве. Устройство использует протокол UDP для связи.
Используемые нами ПК обычно имеют две или более сетевых карт (NIC). Одну из этих сетевых карт мы называем Machine LAN, и ей назначается частный адрес 192.168.1.49/24. Устройства ввода-вывода имеют IP-адреса 192.168.1.11/24, 192.168.1.12/24 и т. Д.
Вторая сетевая карта может быть подключена к общей сети завода (заказчика) и называется локальной сетью завода. Обычно это настраивается для адресации DHCP.
Наше приложение настроено с IP-адресом устройства ввода-вывода и, таким образом, генерирует трафик UDP для этого адреса. В нормальных условиях я могу отслеживать этот трафик с помощью Wireshark и видеть UDP-пакеты, проходящие туда и обратно на IP-адрес устройства через интерфейс локальной сети компьютера. Я также могу проверить связь с устройством ввода-вывода и наблюдать, как ICMP-пакеты передаются между ПК и устройством ввода-вывода через интерфейс локальной сети компьютера.
Поскольку это промышленное приложение, мы хотим убедиться, что все работает максимально надежно и что наше приложение восстанавливается после сбоев сети. С этой целью я провожу тесты здесь, на нашем производственном предприятии, где я отключаю устройство ввода-вывода от сети, отслеживаю поведение нашего приложения, затем повторно подключаю устройство ввода-вывода и проверяю, что приложение снова начинает разговаривать с устройством. Иногда все выздоравливает, а иногда нет. Мне кажется, что иногда при проведении этого теста Windows начинает отправлять трафик для адреса 192.168.1.11 через интерфейс Mill LAN, а не через интерфейс Machine LAN. Когда это происходит, очевидно, что устройство ввода-вывода не отвечает, и приложение не может взаимодействовать с устройством. Я изучил сетевую конфигурацию ПК и таблицы маршрутизации, а также потратил много времени на поиск идей в Интернете, но я не могу понять причину такого поведения.
Я подтвердил, что Windows отправляет IP-трафик на интерфейс Mill LAN, а не на интерфейс Machine LAN, наблюдая за трафиком с помощью Wireshark. Я могу наблюдать это как с UDP-пакетами, сгенерированными моим приложением, так и с ICMP-пакетами, сгенерированными ping.exe, и поэтому я прихожу к выводу, что проблема лежит вне нашего приложения.
Одна из вещей, которые я пробовал, - это манипулирование метриками маршрутизации (метриками интерфейса и шлюза) в попытке заставить Windows использовать интерфейс локальной сети компьютера. Кажется, это не помогает. Вы увидите эти скорректированные / преувеличенные показатели в списках конфигураций ниже.
Когда возникает симптом, я все еще могу успешно пропинговать устройство ввода-вывода, если я явно укажу ping.exe, какой интерфейс использовать:
C:\>ping -S 192.168.1.49 192.168.1.11
Pinging 192.168.1.11 from 192.168.1.49 with 32 bytes of data:
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Reply from 192.168.1.11: bytes=32 time=7ms TTL=16
Reply from 192.168.1.11: bytes=32 time=7ms TTL=16
Reply from 192.168.1.11: bytes=32 time=7ms TTL=16
Ping statistics for 192.168.1.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 7ms, Average = 6ms
Иногда симптом проходит сам по себе через короткое время, но обычно сохраняется в течение длительного времени (я предполагаю, что бесконечно). Я также могу избавиться от симптома, отключив интерфейс Mill LAN; это имеет смысл, потому что теперь Windows имеет только один интерфейс для маршрутизации всего трафика. Я также могу избавиться от симптома, удалив запись ARP для устройства ввода-вывода (я понятия не имею, почему это работает):
C:\>arp -d 192.168.1.11
Когда возникает симптом, я все еще могу пинговать другие устройства в локальной сети компьютера, поэтому маршрутизация пакетов через соответствующие интерфейсы в целом работает (только не для одного конкретного адреса). Каким бы ни было явление, похоже, оно связано с одним IP-адресом. Поскольку удаление записи ARP для этого адреса устраняет симптом, я подозреваю, что что-то связано с ARP, но я точно не знаю.
Похоже, что запись ARP для 192.168.1.11 исчезает, когда возникает симптом. Перед появлением симптома есть запись (с правильным MAC-адресом):
C:\>arp -a | findstr 192.168.1.11
192.168.1.11 00-50-8e-00-26-e2 dynamic
После появления симптома запись исчезает:
C:\>arp -a | findstr 192.168.1.11
C:\>
По какой-то причине кажется, что удаление несуществующей записи ARP восстанавливает связь.
Еще одно наблюдение: я отслеживал вывод непрерывного пинга (ping -t 192.168.1.11). Вот случай, когда мне удалось отключить кабель на несколько секунд, снова подключить, и ping смог возобновить разговор:
Reply from 192.168.1.11: bytes=32 time=9ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Request timed out.
Request timed out.
Reply from 192.168.1.11: bytes=32 time=2005ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Похоже, когда появляются симптомы (связь не восстанавливается), я вижу сообщение «Целевой хост недоступен»:
Reply from 192.168.1.11: bytes=32 time=9ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Request timed out.
Request timed out.
Reply from 192.168.1.49: Destination host unreachable.
Request timed out.
Request timed out.
Я не уверен на 100%, что это всегда так.
Вот интерфейсы (обратите внимание на метрики, которые я назначил вручную):
C:\>netsh interface ip show config
Configuration for interface "Machine LAN"
DHCP enabled: No
IP Address: 192.168.1.49
Subnet Prefix: 192.168.1.0/24 (mask 255.255.255.0)
Default Gateway: 0.0.0.0
Gateway Metric: 1
InterfaceMetric: 1
Statically Configured DNS Servers: None
Register with which suffix: Primary only
Statically Configured WINS Servers: None
Configuration for interface "Mill LAN"
DHCP enabled: Yes
IP Address: ***.16.1.31
Subnet Prefix: ***.16.0.0/20 (mask 255.255.240.0)
Default Gateway: ***.16.0.58
Gateway Metric: 500
InterfaceMetric: 500
DNS servers configured through DHCP: ***.16.6.20
***.16.16.131
Register with which suffix: Primary only
WINS servers configured through DHCP: ***.16.6.20
***.16.16.131
Configuration for interface "Loopback Pseudo-Interface 1"
DHCP enabled: No
IP Address: 127.0.0.1
Subnet Prefix: 127.0.0.0/8 (mask 255.0.0.0)
InterfaceMetric: 50
Statically Configured DNS Servers: None
Register with which suffix: None
Statically Configured WINS Servers: None
Вот таблица маршрутизации (отображаемая командами netsh и route):
C:\>netsh int ip show route
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
No Manual 100 0.0.0.0/0 3 ***.16.0.58
No Manual 1 0.0.0.0/0 4 Machine LAN
No System 256 ***.16.0.0/20 3 Mill LAN
No System 256 ***.16.1.31/32 3 Mill LAN
No System 256 ***.16.15.255/32 3 Mill LAN
No Manual 1 192.168.1.0/24 4 Machine LAN
No System 256 192.168.1.49/32 4 Machine LAN
No System 256 192.168.1.255/32 4 Machine LAN
No System 256 224.0.0.0/4 3 Mill LAN
No System 256 224.0.0.0/4 4 Machine LAN
No System 256 255.255.255.255/32 3 Mill LAN
No System 256 255.255.255.255/32 4 Machine LAN
C:\>route print
===========================================================================
Interface List
4...00 40 05 10 4e 9c ......D-Link DFE-530TX+ PCI Adapter
3...00 1a a0 e8 72 59 ......Intel(R) 82566DM-2 Gigabit Network Connection
1...........................Software Loopback Interface 1
5...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
7...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 ***.16.0.58 ***.16.1.31 600
0.0.0.0 0.0.0.0 On-link 192.168.1.49 2
***.16.0.0 255.255.240.0 On-link ***.16.1.31 756
***.16.1.31 255.255.255.255 On-link ***.16.1.31 756
***.16.15.255 255.255.255.255 On-link ***.16.1.31 756
192.168.1.0 255.255.255.0 On-link 192.168.1.49 2
192.168.1.49 255.255.255.255 On-link 192.168.1.49 257
192.168.1.255 255.255.255.255 On-link 192.168.1.49 257
224.0.0.0 240.0.0.0 On-link ***.16.1.31 756
224.0.0.0 240.0.0.0 On-link 192.168.1.49 257
255.255.255.255 255.255.255.255 On-link ***.16.1.31 756
255.255.255.255 255.255.255.255 On-link 192.168.1.49 257
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 192.168.1.49 1
===========================================================================
Я видел те же симптомы на ПК с XP, Windows 7 и Windows 8, хотя я использовал Wireshark только для наблюдения за трафиком, проходящим через неправильный интерфейс в Windows 8.
Время исповеди: У нас нет узлов в локальной сети Machine LAN с адресом 192.168.1.1, но я получаю ответы ping с этого адреса через интерфейс Mill LAN. Что-то где-то в локальной сети завода (или доступное из него) имеет этот адрес. Вот трассировка, которая показывает, что это всего в одном прыжке и, вероятно, во внутренней сети моей компании:
C:\>tracert 192.168.1.1
Tracing route to 192.168.1.1 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms ***.16.0.58
2 12 ms 47 ms 24 ms 192.168.1.1
Trace complete.
Я предполагаю, что существование этого устройства 192.168.1.1, вероятно, представляет собой неправильно настроенную сеть, и что я должен выяснить, почему оно видно моему ПК (я не думал, что эти частные адреса должны быть маршрутизируемыми). В любом случае я хотел бы выяснить, как заставить вещи работать так, как они есть, потому что, по моему опыту, устройства с адресами 192.168.1. * Иногда действительно появляются на сайтах клиентов (в локальной сети завода), и я хотел бы, чтобы наша система продолжала работать. работают, даже если они это делают. Другими словами, я хотел бы, чтобы мой компьютер использовал только интерфейс Machine LAN для трафика с 192 адресами. Если у кого-то есть идеи, как я могу этого добиться, я бы хотел их услышать!
Сначала я собирался сказать, что на этот вопрос лучше ответить на Superuser или Serverfault, но я хочу решить стратегическую проблему, которая у вас возникнет:
Вы выбрали 192.168.0.0 для своей «частной» LAN. К сожалению, вы выбрали наиболее часто используемый адрес частной сети и, вероятно, часто будете сталкиваться с конфликтами адресов - похоже, вы это сделали здесь.
Неправда, что адреса 192.168.0.0 не могут быть маршрутизированы. Они могут и постоянно маршрутизируются в сети компании. Однако их нельзя маршрутизировать через Интернет. Вы, вероятно, думаете о «локальной сети», 169.254.0.0/16. Эта сеть вообще не маршрутизируется (как предполагается), поэтому у вас не будет конфликтов адресов, с которыми вы сталкиваетесь.
Вы должны использовать адреса из диапазона адресов 169.254.0.0/16. Выберите небольшую подсеть из этого диапазона для количества имеющихся у вас устройств (например. 169.254.55.64/28 для менее чем 10 устройств ввода-вывода).
Два слова: кеш маршрута
UDP не имеет состояния, поэтому система создаст «соединение», чтобы передать ему состояние. Пока вы продолжаете отправлять пакеты, кеш для этого соединения будет оставаться действующим. Таким образом, когда локальная сеть машины отключена, ваш трафик по умолчанию будет направлен в локальную сеть завода. Приложение не будет работать, пока не истечет срок действия кеша неверного маршрута (из-за бездействия).
Есть два способа решить эту проблему: 1) добавить код в ваше приложение, чтобы напрямую связать правильный интерфейс, и / или 2) добавить правила брандмауэра, чтобы запретить 192.168.1.0/24 когда-либо использовать интерфейс Mill LAN.
(Как указывает @Ron, 192.168.1.0/24 - очень плохой выбор сети.)
Примечание:
netsh interface ip show destinationcache и
netsh interface ip delete destinationcache
Кроме того, Machine LAN никогда не должна быть вашим шлюзом по умолчанию, и ее метрика никогда не должна быть «1».