Тайм-ауты SSH между хостами, которые связаны через несколько маршрутов

У меня неприятная проблема с ssh-соединениями между хостами, которые связаны несколькими путями (маршрутами). Чтобы объяснить это подробно...

Как видите, между узлами есть два возможных пути прохождения пакетов (зеленая и красная линия). И если я скажу, что они могут путешествовать, они могут!;-) На маршрутизаторе нет правил брандмауэра (или nat), просто переадресация пакетов.

Теперь происходит следующее: если я устанавливаю ssh-соединение от хоста A к хосту B через маршрутизатор (или наоборот), так как это намеченный путь (не прямое соединение в той же сети; ssh-сервер слушает только на другом интерфейсе), что это соединение исчезает через несколько секунд, но только если я бездельничаю. Я попробовал несколько опций keepalive на ssh-сервере (и клиенте), но теперь я могу сказать, что это не проблема и не решение.

Покопавшись немного глубже, я понял, что эта проблема должна быть связана с несколькими интерфейсами и маршрутами на обоих хостах - это единственная ситуация, в которой это происходит; но воспроизводится и в других системах (если они используют одну и ту же настройку if).

Таким образом, я сделал несколько следов и увидел некоторый трафик ssh на обоих хостах, проходящих через интерфейсы, которые совместно используют одну и ту же сеть (не через маршрутизатор, как предполагалось).

Что я испытываю, так это то, что если я ssh с хоста A на B (помните, единственный интерфейс, на котором слушает ssh - это тот, который подключен к маршрутизатору) и отключает интерфейс в общей сети, SSH соединение умирает немедленно!

Я предполагаю, что более поздний трафик ssh использует другой способ, чем первоначальное соединение. Может быть, оба экземпляра ssh (клиент / сервер) "видят", что между ними есть общая сеть, так почему бы не использовать ее (конечно, это "прямое" соединение имеет гораздо более высокий приоритет в таблице маршрутизации)?!

Я пытался блокировать трафик ssh на хостах напрямую с помощью фильтрации пакетов, но столкнулся с тем же временем ожидания. Единственное решение, которое работает, это отключить интерфейс к общей сети; это сразу помогает, и соединение долго "простаивает".

Кто-нибудь с хорошей идеей?!

Большое спасибо!:-)

- ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ, ЗАПРОШЕННАЯ В КОММЕНТАРИИ -

Все последующие выходные данные были сгенерированы на "хосте B" (ssh "target").

"хост A" находится на "192.168.110.0/24"-subnet!

"ifconfig -a" (несущественные интерфейсы удалены):

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
  ether 00:00:00:00:00:00
  inet 192.168.100.5 netmask 0xffffff00 broadcast 192.168.100.255
  media: Ethernet autoselect (1000baseT <full-duplex>)
  status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
  ether 00:00:00:00:00:00
  inet 192.168.110.5 netmask 0xffffff00 broadcast 192.168.110.255
  media: Ethernet autoselect (1000baseT <full-duplex>)
  status: active

"netstat -rna" (несущественные маршруты (интерфейсы)):

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.100.1      UGS         0      807    em0
127.0.0.1          link#9             UH          0        0    lo0
192.168.100.0/24   link#1             U           0   113430    em0
192.168.100.5      link#1             UHS         0    10437    lo0
192.168.110.0/24   link#2             U           0      319    em1
192.168.110.5      link#2             UHS         0        0    lo0
(...)

"sockstat -l" (другие процессы для полноты сохранены):

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
dhcpd    dhcpd      1416  10 udp4   *:67                  *:*
dhcpd    dhcpd      1416  20 udp4   *:58917               *:*
dhcpd    dhcpd      1416  21 udp6   *:33125               *:*
mysql    mysqld     1629  10 tcp4   192.168.100.5:3306    *:*
root     apcupsd    1353  4  udp4   *:18755               *:*
root     apcupsd    1353  5  udp4   *:162                 *:*
root     apcupsd    1353  7  tcp4   192.168.100.5:3551    *:*
root     collectd   1635  10 udp4   *:65262               *:*
root     collectd   1635  11 udp4   *:49993               *:*
root     collectd   1635  12 udp4   *:51224               *:*
root     collectd   1635  13 udp4   *:58446               *:*
root     collectd   1635  4  udp4   192.168.100.5:25826   *:*
root     collectd   1635  7  udp4   *:16430               *:*
root     collectd   1635  8  udp4   *:12406               *:*
root     collectd   1635  9  udp4   *:16113               *:*
root     inetd      1676  5  udp4   *:69                  *:*
root     monit      1358  7  tcp4   127.0.0.1:2812        *:*
root     sshd       1656  3  tcp4   192.168.100.5:22      *:*
root     syslog-ng  1295  10 dgram  /var/run/logpriv
root     syslog-ng  1295  12 tcp4   192.168.100.5:514     *:*
root     syslog-ng  1295  13 udp4   192.168.100.5:514     *:*
root     syslog-ng  1295  14 tcp4   192.168.100.5:601     *:*
root     syslog-ng  1295  9  dgram  /var/run/log
_ntp     ntpd       1425  6  udp4   192.168.100.5:123     *:*