Уважаемые гуру, подскажите, если кто сталкивался.
Хочу опросить по SNMP маршрутизатор, посылаю запрос на один IP-адрес, а маршрутизатор мне отвечает с другого IP-адреса. Этот ответ на мою сетевую карту приходит, но отправитель пакета его не воспринимает:admin@server:~$ snmpwalk -v 1 -c public 10.111.0.1
Timeout: No Response from 10.111.0.1Но tshark ответ от маршрутизатора показывает:
1.118100 10.111.23.63 -> 10.111.0.1 SNMP 85 get-next-request
1.120292 172.16.2.2 -> 10.111.23.63 SNMP 351 get-response10.111.23.63 - это адрес сервера, с которого отправляю SNMP-запрос.
10.111.0.1 - адрес маршрутизатора, на который отправляю SNMP-запрос.
172.16.2.2 - второй адрес маршрутизатора, с которого поступает SNMP-ответ.Можно ли заставить snmpwalk воспринимать ответы с IP-адреса, отличающегося от изначального?
Я бы на вашем месте искал способ заставить маршрутизатор отвечать с правильного интерфейса.
> Я бы на вашем месте искал способ заставить маршрутизатор отвечать с правильного
> интерфейса.Проблема в том, что его не я конфигурировал =(
>> Я бы на вашем месте искал способ заставить маршрутизатор отвечать с правильного
>> интерфейса.
> Проблема в том, что его не я конфигурировал =(тогда задайте на вашем сервере маршрут до 172.16.2.2 через 10.111.0.1, ну это если между ними ничего активного нет, конечно
> тогда задайте на вашем сервере маршрут до 172.16.2.2 через 10.111.0.1, ну это
> если между ними ничего активного нет, конечновместо этого проще сразу запрос слать на 172.16.2.2 и от него же получать ответ.
> вместо этого проще сразу запрос слать на 172.16.2.2 и от него же
> получать ответ.На 172.16.2.2 нельзя послать запрос - запрещено в аксес-листах маршрутизатора.
> тогда задайте на вашем сервере маршрут до 172.16.2.2 через 10.111.0.1, ну это
> если между ними ничего активного нет, конечноНа самом маршрутизаторе нет маршрута от 10.111.0.1 к 172.16.2.2.
> 1.118100 10.111.23.63 -> 10.111.0.1 SNMP 85 get-next-request
> 1.120292 172.16.2.2 -> 10.111.23.63 SNMP 351 get-response
> Можно ли заставить snmpwalk воспринимать ответы с IP-адреса, отличающегося от изначального?SNAT на сервере из 172.16.2.2 в 10.111.0.1 ?
>> 1.118100 10.111.23.63 -> 10.111.0.1 SNMP 85 get-next-request
>> 1.120292 172.16.2.2 -> 10.111.23.63 SNMP 351 get-response
>> Можно ли заставить snmpwalk воспринимать ответы с IP-адреса, отличающегося от изначального?
> SNAT на сервере из 172.16.2.2 в 10.111.0.1 ?Так?
iptables -t nat -A POSTROUTING -s 172.16.2.2 -j SNAT --to-source 10.111.0.1
Не помогает.
>[оверквотинг удален]
> приходит, но отправитель пакета его не воспринимает:
> admin@server:~$ snmpwalk -v 1 -c public 10.111.0.1
> Timeout: No Response from 10.111.0.1
> Но tshark ответ от маршрутизатора показывает:
> 1.118100 10.111.23.63 -> 10.111.0.1 SNMP 85 get-next-request
> 1.120292 172.16.2.2 -> 10.111.23.63 SNMP 351 get-response
> 10.111.23.63 - это адрес сервера, с которого отправляю SNMP-запрос.
> 10.111.0.1 - адрес маршрутизатора, на который отправляю SNMP-запрос.
> 172.16.2.2 - второй адрес маршрутизатора, с которого поступает SNMP-ответ.
> Можно ли заставить snmpwalk воспринимать ответы с IP-адреса, отличающегося от изначального?маршрут к 10.111.23.63 с 172.16.2.2/10.111.0.1 через какой интерфейс? таблицу маршрутизации с 172.16.2.2/10.111.0.1 покажите
> маршрут к 10.111.23.63 с 172.16.2.2/10.111.0.1 через какой интерфейс? таблицу маршрутизации
> с 172.16.2.2/10.111.0.1 покажите10.111.0.0/16 *[Direct/0] 17w1d 06:15:03
> via lo0.3172.16.2.2/32 *[Local/0] 17w1d 06:24:11
Local via lo0.7
http://www.juniper.net/techpubs/en_US/junos/topics/task/conf...
> http://www.juniper.net/techpubs/en_US/junos/topics/task/conf...Но это только для SNMP-трапов. Указать нужный интерфейс для обычных ответов на SNMP-запросы там нельзя, они отсылаются с того интерфейса, через который проходит маршрут к тому IP-адресу, с которого пришел запрос - http://www.juniper.net/techpubs/en_US/junos12.2/topics/refer...
What is the source IP address used in the response PDUs for SNMP requests? Can this be configured?
The source IP address used in the response PDUs for SNMP requests is the IP address of the outgoing interface to reach the destination. The source IP address cannot be configured for responses. It can only be configured for traps.
А сеть 10.111.0.0/16 находится в отдельной VRF-таблице, поэтому маршрутизатор отправляет ответ не с того интерфейса, с которого надо, а с того, который по-умолчанию.
Может быть, это вообще проблема не с snmpwalk? Может, он должен воспринимать ответы с любых адресов, а это у меня на сервере что-то не так? Кто-нибудь может точно сказать - должен snmp-ответ быть с того же айпишника или нет?
>[оверквотинг удален]
> is the IP address of the outgoing interface to reach the
> destination. The source IP address cannot be configured for responses. It
> can only be configured for traps.
> А сеть 10.111.0.0/16 находится в отдельной VRF-таблице, поэтому маршрутизатор отправляет
> ответ не с того интерфейса, с которого надо, а с того,
> который по-умолчанию.
> Может быть, это вообще проблема не с snmpwalk? Может, он должен воспринимать
> ответы с любых адресов, а это у меня на сервере что-то
> не так? Кто-нибудь может точно сказать - должен snmp-ответ быть с
> того же айпишника или нет?Зависит от реализации многоинтерфейсного режима в софте. Не весь софт с udp правильно отрабатывает эту ситуацию. Если многоинтерфейсного режима нет вы можете получить ответный пакет с ip адресом интерфейса через который идет маршрут к адресу запросившего, хоть запрос был на другой ip.
Поэтому и просил показать таблицу маршрутизации. Но как у них с поддержкой многоинтерфейсного режима я не знаю.
ПРОБЛЕМА РЕШЕНА!iptables -A OUTPUT -d 172.16.2.2 -j DNAT --to-destination 10.111.0.1
И опрашиваю маршрутизатор по адресу 172.16.2.2.
Всем большое спасибо =)
> ПРОБЛЕМА РЕШЕНА!
> iptables -A OUTPUT -d 172.16.2.2 -j DNAT --to-destination 10.111.0.1
> И опрашиваю маршрутизатор по адресу 172.16.2.2.
> Всем большое спасибо =)dnat делает обратное преобразование не глядя на ip отправителя?
интересно глянуть бы на tcpdump
>> ПРОБЛЕМА РЕШЕНА!
>> iptables -A OUTPUT -d 172.16.2.2 -j DNAT --to-destination 10.111.0.1
>> И опрашиваю маршрутизатор по адресу 172.16.2.2.
>> Всем большое спасибо =)
> dnat делает обратное преобразование не глядя на ip отправителя?
> интересно глянуть бы на tcpdumpСовершенно верно, я просто теперь обманываю snmpwalk, чтобы он думал, что опрашивает 172.16.2.2, а на самом деле он опрашивает 10.111.0.1.
Вот вывод tshark:
1.842915 10.111.23.63 -> 10.111.0.1 SNMP 91 get-next-request
1.844480 172.16.2.2 -> 10.111.23.63 SNMP 93 get-response
>[оверквотинг удален]
>>> iptables -A OUTPUT -d 172.16.2.2 -j DNAT --to-destination 10.111.0.1
>>> И опрашиваю маршрутизатор по адресу 172.16.2.2.
>>> Всем большое спасибо =)
>> dnat делает обратное преобразование не глядя на ip отправителя?
>> интересно глянуть бы на tcpdump
> Совершенно верно, я просто теперь обманываю snmpwalk, чтобы он думал, что опрашивает
> 172.16.2.2, а на самом деле он опрашивает 10.111.0.1.
> Вот вывод tshark:
> 1.842915 10.111.23.63 -> 10.111.0.1 SNMP 91 get-next-request
> 1.844480 172.16.2.2 -> 10.111.23.63 SNMP 93 get-responseскорей обратного преобразования не происходит, но так как пакет пришел и так с правильным заголовком он отдается в snmpwalk , иначе это опасная фича dnat.
может на шлюзе отдельно к 10.111.23.63 маршрут прописать?
> скорей обратного преобразования не происходит, но так как пакет пришел и так
> с правильным заголовком он отдается в snmpwalk , иначе это опасная
> фича dnat.
> может на шлюзе отдельно к 10.111.23.63 маршрут прописать?Маршрут от 172.16.2.2 к 10.111.0.1 есть, а в обратную сторону маршрута нет из соображений безопасности. Иначе бы я сразу опрашивал 172.16.2.2 без всякого dnat.