Таймауты SSH между хостами, подключенными по нескольким маршрутам

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

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

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

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

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

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

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

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

У кого-нибудь есть хорошая идея ?!

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

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

Весь следующий вывод был создан на «хосте B» (ssh «target»).

"хост A" находится в подсети "192.168.110.0/24"!

"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     *:*