Проблема с соединением SSH с отказоустойчивым шлюзом
Вероятно, это связано с режимом UAS(USB Attached SCSI ). Официально он доступен только начиная с USB 3.0, что объясняет, почему USB 2.0 работает нормально (UAS не выбран ).
Проблема обычно связана, возможно, с плохо реализованной прошивкой на адаптере или, в любом случае, с проблемой взаимодействия при взаимодействии с драйверами Linux. Коммерческие драйверы, созданные поставщиком аппаратного/микропрограммного обеспечения, могут иметь специальную обработку этих ошибок, поскольку они известны поставщику.
Если исправить проблему невозможно, иногда ее можно обойти, отключив некоторые функции. В Linux есть как минимум 5 флажков Usb Storage для отключения функций UAS(f,g,j,t,u )вручную. Когда модели явно идентифицируются как плохо ведущие себя, они добавляются во внутренний черный список, чтобы автоматически применять эти причуды. Вручную вы должны добавить опцию загрузки или опцию модуля хранения USB -.
Итак, сначала попробуйте полностью отключить UAS с помощью quirk u, посмотрите, решит ли это проблему. См. позже, может быть достаточно, например, использования опции t или g вместо u.
опция загрузки из командной строки ядра (с использованием VID :PID, указанный в ваших журналах):
usb-storage.quirks=067b:2773:u
опция модуля (создать файл в /etc/modprobe.d):
options usb-storage quirks=067b:2773:u
UAS предлагает меньшие накладные расходы, иначе это не должно быть проблемой.
Вы должны попробовать тот же жесткий диск с другим адаптером от другого поставщика (с другим VID ), чтобы действительно увидеть разницу в поведении в режиме UAS.
Я не уверен на 100%, но... У вас есть два сетевых адаптера, и у каждого своя сеть. Если ваш «Шлюз по умолчанию» установлен на 192.168.1.1/24, 172.16.0.0/17не будет разрешен доступ к первому. Это функция, которая должна быть включена/разрешена. Вы пересекаете сети, вы говорите о маршрутизации. Поэтому либо установите следующую настройку, либо установите мост:
echo 1 > /proc/sys/net/ipv4/ip_forward
И если это работает, сделайте его постоянным с помощью:
/etc/sysctl.conf:
net.ipv4.ip_forward = 1
sysctl -p /etc/sysctl.conf
service network restart
Когда вы говорите входящие , вы имеете в виду подключения от удаленных интернет-клиентов, которые были открыты для службы SSH (или HTTP )на вашем локальном хосте?
Если да, то какие внешние IP-адреса? Я предполагаю, что они разные для каждого интерфейса. В этом случае у вас также могут возникнуть проблемы с тайм-аутами для записей NAT и соединений NAT, в зависимости от ваших шлюзов-маршрутизаторов.
Вы не можете управлять внешней общедоступной маршрутизацией для входящих подключений, особенно если они открыты. Если вы потеряете подключение для данного интерфейса, то все подключения к нему прервутся по тайм-ауту (, за исключением случаев, когда соединение и маршрутизация восстанавливаются до истечения тайм-аута ).
Если вы можете контролировать DNS, используемый удаленными клиентами для подключения к вашему (, например. )SSH, тогда вы, возможно, сможете иметь разумный контроль над тем, какой IP-адрес они используют для новых соединений, в течение некоторого разумного времени между ошибками -, например.минимум через 300 секунд после объявления нового IP-адреса вы можете ожидать, что клиенты начнут его использовать.