SSHFS через VPN зависает на большом куске

487
Alfe

Я использую SSHFS через VPN-соединение. При попытке отправить фрагмент размером 1270 байт в файл в этой удаленной файловой системе:

head -c 1270 /dev/urandom > /path/into/the/sshfs/foo 

вся файловая система зависает и позволяет любому процессу зависать, который пытается получить к нему доступ. Это можно исправить, только убив процесс sshfs.

Если я попытаюсь вместо этого отправить 1269 байт, никаких проблем не возникает.

Я много играл с параметрами командной строки sshfs и обнаружил, что только один параметр имеет какое-либо влияние на это:

-o max_write=1240 

Если я передам здесь значение меньше 1270, то предел, где начинается ошибка, будет снижен до этого значения + 1 (хотя значение 300 уменьшило его до 1183). К сожалению, повышение значения не помогает, ограничение остается в 1270 байтов.

Это как-то связано с буферами. Если я использую последовательные записи, все работает нормально:

(head -c 1269 /dev/urandom head -c 1269 /dev/urandom) > /path/into/the/sshfs/foo 

Похоже, что это не проблема лежащего в основе ssh, потому что

ssh remote_host "bash -c 'head -c 2000 /dev/zero | tr \\\0 0'" | wc -c 

работает нормально и печатает 2000как положено.

Тем не менее, X - экспедиторская, кажется, не работает, либо, так что, возможно, это является проблемой SSH ниже.

Я попытался изменить размер MTU с 1412 до 1500:

ifconfig tun0 mtu 1500 

но без какого-либо эффекта.

Это известная проблема? Можно ли как-то это исправить / предотвратить / обойти?

РЕДАКТИРОВАТЬ: Я использую FritzBox (домашний маршрутизатор) VPN (очевидно, в стиле "Cisco", но я не эксперт в этой теме) и Ubuntu 16.04 для доступа к нему извне.

Я также заметил, что, когда я проверяю это через мобильную телефонную линию с ноутбуком, проблема не возникает. Это происходит только когда я на удаленном сайте, который находится за каким-то ограничительным брандмауэром. Однако обратите внимание, что VPN работает в целом, только аспект sshfs (и переадресация X) представляется проблематичным.

1

1 ответ на вопрос

2
davidgo

Скорее всего, у вас проблема с MTU, вызванная издержками VPN. Увеличение MTU, как вы это сделали, не решит проблему, потому что это делает MTU больше, чем доступный максимальный размер пакета для носителя (я предполагаю, что вы не используете большие кадры в среде только для локальной сети).

Действительно, решение может быть в том, чтобы УМЕНЬШИТЬ MTU туннельного устройства.

Вы не указали VPN или маршрутизаторы. Мы решаем эту проблему с помощью фиксации MTU на уровне операционной системы. В качестве альтернативы / дополнительно, если вы используете OpenVPN, существуют директивы, которые вы можете использовать для фрагментированных пакетов, например, используя mssfix - вы можете посмотреть https://www.sonassi.com/help/trou устранение неисправностей/setting-correct-mtu-for-openvpn а также опция фрагмента - https://blog.hambier.lu/post/solving-openvpn-mtu-issues

Спасибо за Ваш ответ. Я добавил некоторые подробности о моем VPN и т. Д. Можно ли изменить MTU на лету, когда соединение установлено и работает? Это отражается в выводе `ifconfig`, но я не уверен, что он используется. Пока не вижу эффекта (пока дома); даже если я установлю MTU на большие значения, такие как 10000, я не смогу создать проблему здесь. Я постараюсь уменьшить MTU на удаленном сайте завтра, чтобы проверить, помогает ли он там. Alfe 6 лет назад 0
После уменьшения размера MTU до 1000 байт проблема исчезла. Также работает переадресация X Сотрудник также упомянул, что он решил такие проблемы, уменьшив размер MTU. Так что это кажется довольно солидным решением ;-) Спасибо! Alfe 6 лет назад 0

Похожие вопросы