Леонид, нет в сети такого "видит", в сети есть только пакет( ну еще состояние ).
Пакет может ходить не разных уровнях, условно l2, l3 и т.д. ( очень условные уровни ).
На l2 сеть сегментируется VLAN и физическими устройствами.
На l3 адресами и масками( ну еще межсетевыми экранами ).
Адреса в сети которые вы указали ничего не говорят ни о l2 топологии( может быть между ними просто нет линка на l2 ), ни о l3( для этого еще нужны маски и маршруты ).
Вы упускаете из задачи значимые детали.
Если у вас ping c 10.5.0.92 до 10.5.1.1 идет, а пинг с 10.5.1.1 до 10.5.0.92 нет. То вы упускаете какую-то значимую диагностическую деталь. Это может быть или, что эти адреса разные( адреса одинаковые, но привязаны к разным устройствам или в реальности вы ping делает не этого адреса, а другого адреса того же устройства ), или где-то вы работаете с пакетами( фаервол, NAT, прямая модификация пакетов и т.д. ).
Если ping идет в одну сторону, то он должен идти и в обратную( поскольку пакеты они при ping идут и туда и обратно ) если нигде в трафик руками по дороге не вмешиваться.
Пример:
10.5.0.92 вообще не отвечает на ping
10.5.0.92 и 10.5.0.110 находятся в разных l2 сегментах и имеют маски 16.
10.5.1.1 имеет маску 16 и находится в двух l2 сегментах имеющих связность с 10.5.0.92 и 10.5.0.110 соответвенно.
В такой конфигурации у вас будет именно такая картина.
10.5.0.92 может пинговать 10.5.1.1.
10.5.0.92 не может пинговать 10.5.0.110
10.5.1.1 может пинговать 10.5.0.110
10.5.1.1 не может пинговать 10.5.0.92
10.5.0.110 может пинговать 10.5.1.1.
10.5.0.110 не может пинговать 10.5.0.92
Леонид, Какие остальные стеки, у вас она схеме один стек? Что значит работают без проблем, пинг вообще не показатель, что что-то работает или нет.
Я до сих пор не понимаю от куда куда у вас не идут/идут пинг.
Если какие-то остальные стеки работают, значит они или имеют отличая на l3 уровне или на l2( вместе с "l1" ).
Но судя по текущему описанию у вас отсутствует l2 связность через 10.5.0.1. При таком сценарии, все что идет через шлюзы будет работать, а все что работает в рамках локальной подсети будет работать только в зоне разделенной l3 коммутатором.
Леонид,
1. Проверьте, что при пинге с 10.0.145.65 на 10.0.128.3 пингуется именно ваш СКУД сервер, возможно у вас не один такой адрес в сети.
2. Поправьте маску в СКУД сети( по меньшей мере на 10.0.145.65 и 10.0.128.3 ). С такой маской с 10.0.128.3 и не должен пинговаться 10.5.0.92 и 10.5.0.97.
3. Распишите нормально пинги. На схеме пронумеруйте коммутаторы.
Формат типа такого: ip адрес x.x.x.x порт номер 20 коммутатора 4 VLAN7 пинг на y.y.y.y порт номер 15 коммутатора 7 VLAN 7 не проходит/проходит.
4. Судя по всему( описание у вас очень много деталей опускает ) пинги у вас не проходят через l3 коммутатор когда пинг должен идти по "l2 уровню"( одна подсеть ). Значит у вас на нем нет "коммутации" на l2 уровне, т.е. у вас фактически два раздельных VLAN7 разделенных l3 коммутатором. Но в этом я не уверен.
Леонид, у вас очень запутанное описание и похоже вы путаетесь в терминах. Нарисуйте l2 и l3 схемы, так будет понятнее.
Если пакет в одну сторону проходит, а обратно нет, то дело или в маршрутах или в фаерволе.
Гипотетически, ещё может быть хитрый косяк с вланами, когда у вас пакеты в одну сторону теряю vlan и доходят, а обратно маркируются и не доходят, но с ходу такую конфигурацию не распишу, и не уверен, что она вообще возможна.
Ping работает на l3, значит у коммутатора должен быть ip и он должен быть привязан к интерфейсу, вероятно если не проходит ping, значит между этими интерфейсами отсутствует "связность" на l3. Если ip коммутатора в той же подсети, что и конечного устройства он будет искать по мак таблице и интерфейс коммутатора должен быть в таком случае в том же vlan. Но это теория, как на практике у Allied Telesis оно работает я не подскажу.
Дѣаволъ, изначально цикл статей был именно на linkmeup. На момент написания ссылка работала( может быть кэш ), я ее открывал.
Спасибо за корректные ссылки.
В основном 264, несколько каналов 265. Trassir не со всеми камерами умеет 265 из тех, что его поддерживают.
Он не перекодирует, что камера отдает, то и пишет из поддерживаемого списка. Т.е. если камера 265 не поддерживает, то и он его писать не будет, но если камера поддерживает, не значит, что трассир с ней по 265 заработает.
Если вы хотите обезопасить ваши ресурсы с помощью туннеля, то почему вы обращаетесь к ним по публичным адресам?
В таком случае ваши ресурсы должны быть закрыты для доступа по публичным адресам и доступны только по приватным( туннельным ) адресам.
Почему в первом случае вы обращаетесь к 51.XX.XX.1, а во втором к 78.ХХ.ХХ.19?
Трафик до:
51.ХХ.ХХ.80/32
78.ХХ.ХХ.19/32
При наличии тунелей в любом случае будет идти через интернет, а не через тунели, иначе у вас тунели работать не будут.
Виталий Соколов,
есть один вариант, при котором у вас остаются публичными адреса, но при этом можно получать защищенный доступ прямо по ним, ipSec.
Вам VPN вообще зачем? Нарисуйте схему, сервера, публичные адреса, туннели, приватные адреса в туннелях, сервисы.
Так vpn от куда куда идёт, с mikrotik куда-то наружу?
Если да, то пропишите маршрут по умолчнаию на том который тоже хочет на "внешний" интерфейс mikrotik( он должен быть соответствующим образом настроен ).