Спасибо за ваше время, я неправильно спросил это в Сетевом проектировании, поэтому перемещаю его сюда.
У меня есть удаленный офис и главный офис, связанные через IPSec, причем главный офис - 192.168.16.0/24, а удаленный - 192.168.1.0/24. Я могу пинговать все устройства в главном офисе из удаленного офиса и наоборот.
Ниже представлено упрощенное изображение нашей сети:
Мы используем роутеры TP-Link ER-6020 v2 с последней прошивкой в обеих сетях. Наш интернет-провайдер использует беспроводное соединение, поскольку мы живем в сельской местности, хотя я не думаю, что это действительно имеет значение.
Программное обеспечение Time Clock Server работает на Windows Server 2012 (192.168.16.107) вместе с несколькими другими приложениями. Серверное программное обеспечение может без проблем подключать / обнаруживать часы времени в сети 192.168.16.0/24, но не может подключиться к часам времени (192.168.1.105) в удаленной сети, даже если оно может быть отправлено с помощью пинга. Часы используют UDP 30303 и 30304 для связи. Я изменил часы, чтобы исключить неисправность устройства.
Поставщик Time Clock предложил мне установить некоторые правила «Layer3 Management» или создать несколько «Custom Routing Tables», но это, похоже, выходит за рамки моего уровня знаний. Их исследование заставляет меня мыслить кругами без конца.
Пожалуйста, предложите либо путь к решению, либо Букварь, который может помочь мне понять, к чему стремится поставщик, чтобы я мог это понять.
SmallClanger, вы вдохновили меня посмотреть на это под другим углом. Я взломал пароль базы данных, который записывает обнаруженные часы (благодаря плохой безопасности Microsoft Access), и вручную ввел данные часов, минуя процесс обнаружения, и после выезда на удаленный сайт, похоже, он работал без проблем. В программном обеспечении на сервере все еще есть красная точка предупреждения, показывающая, что часы не подключены, но связь есть. Так что единственной неудачей было обнаружение / обнаружение часов через UDP, и я могу жить с красной точкой.