СМУЩЕНИЕ С TORCH

Torch работает с интерфейсом и видит все пакеты, проходящие через него. Сопоставление адресов происходит следующим образом:  
a) Если указать dst-address, то принятые (RX) пакеты на интерфейсе должны иметь этот IP как адрес назначения;  
b) Если указать dst-address, то отправляемые (TX) пакеты на интерфейсе должны иметь этот IP как адрес источника.  

Torch устроен так, чтобы вы могли комбинировать пункты A и B и видеть полный поток. Вы видите реальный трафик в обоих направлениях.

Спасибо всем, кто ответил. Вот мое «правило», которому я научился. Если вы делаете torch на интерфейсе, удалённый IP с той же стороны роутера, что и интерфейс, всегда является источником, а любой другой IP — назначением, независимо от того, находится он внутри роутера или через другой интерфейс. Если пакеты приходят и уходят через один и тот же интерфейс, тогда src становится неоднозначным, так как оба IP — удалённые для этого интерфейса. В любом случае я бы пожаловался, что использовать src и dst в однострочном описании двусторонних пакетов — изначально неправильное и мало полезное решение, не говоря уже о том, что это трудно запомнить. Называть их remote и local могло бы сработать, если бы не ситуация, когда пакет приходит и уходит через один и тот же интерфейс. Присваивание src и dst согласно какому-то внутреннему алгоритму роутера может быть понятно тем, кто писал код, но приводит в полный ступор tcpdump-юзеров, у которых уже есть устоявшееся определение src и dst. Сам пакет показывает, какой IP — src, а какой — dst, так что то, что показывает torch, — это что-то иное, не соответствующее привычному tcp/ip-языку. И при этом до сих пор непонятно, что именно это за «иное». Homer W. Smith CEO Lightlink

Все еще непонятно. Разве нельзя добавить запрос на функцию, чтобы трафик в TORCH отображался так же, как при запуске «Packet Sniffer» на том же интерфейсе с последующим просмотром результатов, скажем, в Wireshark? Сейчас это слишком запутанно, и чтобы в этом разобраться, нужен целый мануал!

P.S. Я специально зарегистрировался, чтобы оставить комментарий на этом форуме, хотя я пользователь Mikrotik около 10 лет, но никогда не был так разочарован функцией, как сейчас.

Похоже, что torch использует такие функции, как «отслеживание соединений» (connection tracking), чтобы показывать источник и назначение трафика, и при этом исходный и конечный адрес на самом деле относятся к стороне, которая установила L3-соединение, а не к L2-трафику, который вы анализируете с помощью torch. Поэтому сложно предсказать, что будет источником, а что назначением при анализе трафика на полностью маршрутизируемых интерфейсах. В типичной ситуации с «NAT-маршрутизатором с одним интернет-подключением» это не так критично.