В настоящее время NetFlow показывает пункт назначения (входящего трафика) как наш внешний IP, а не внутренний IP. Кроме того, для всего исходящего трафика источник отображается как наш брандмауэр, а не как рабочие станции. Есть идеи о том, как найти для них истинный источник / место назначения?
Я согласен с предыдущим ответом. У нас есть 8 маршрутизаторов, на которых я отслеживаю netflow, и я использовал этот метод.
Я так понимаю, у вас есть установка, несколько похожая на эту:
LAN - FW - Router ---- Internet
С NAT в брандмауэре? Если это так, то нет очевидного способа получить истинные места назначения непосредственно в NetFlow, потому что с точки зрения входов маршрутизатора единственным источником пакетов является пул NAT в брандмауэре. Возможно, можно будет регулярно извлекать сопоставления NAT из брандмауэра, а затем обрабатывать данные NetFlow, но я подозреваю, что для этого потребуется специальное кодирование и будет подвержено ошибкам.
Короче нет, я думаю, тебе не повезло.
редактировать:
Если мы позволим себе несколько вольностей с реальными IP-адресами: Внутри: 192.168.0.0/24 Пул NAT: 172.27.10.3 - 172.27.10.5
Давайте отследим TCP-пакет от внутреннего хоста 192.168.0.17 до внешнего хоста 66.102.9.104
Source IP: 192.168.0.17 [ INSIDE ]
Source port: 16732
Dest IP: 66.102.9.104
Dest port: 80
-------------------
NAT location
-------------------
Source IP: 172.27.10.3 [ OUTSIDE ]
Source port: 16732
Dest IP: 66.102.9.104
Dest port: 80
В конце концов приходит ответный пакет:
Source IP: 66.102.9.104 [ OUTSIDE ]
Source port: 80
Dest IP: 172.27.10.3
Dest port: 16732
-------------------
NAT location
-------------------
Source IP: 66.102.9.104 [ INSIDE ]
Source port: 80
Dest IP: 192.168.0.17
Dest port: 16732
Поскольку NAT происходит в брандмауэре, маршрутизатор всегда видит только «внешние» адреса и не может соотнести «внутренний» IP-адрес с любым заданным пакетом.
Я давно не играл с этим, но думаю, что у меня была похожая проблема. Если память не изменяет, я должен был сказать IOS, чтобы он ссылался на трафик с моего интерфейса LAN, а не с интерфейса WAN. Очевидно, это зависит от вашей топологии, но я думаю, что следующая команда решила это за меня:
ip flow-export source FastEthernet0/0