Насколько удалённого доступа к файлам?

Кода поднимают вопрос о скоростях для протоколов передачи данных, то принято указывать хотя бы латенси канала.

SMB прекрасно вывозит гигабит+ на канале 2-5 ms, и даёт чуть больше 10 MiB/s на канале в 60-70 ms.

Опять же вопрос о скоростях передачи стоит поднимать только после ответа на вопрос: «А сможет ли твое железо вывозить шифрование этих скоростей?».

Посмотри еще в сторону s3-совместимых протоколов. Например какой-нибудь minio.

Может стоит задача разбить на две:

1. Шифрование тунеля (*swan, ipsec)

2. Передача файлов (NFS)

Есть еще тысчя способов. Передать файлы например тимвьевом или RMS Вам решать.

для доступа к NAS

гигабит в любую сторону

А зачем? Дисковая система на HDD больше 100 Мбит не вытянет.

Дисковая система на HDD больше 100 Мбит не вытянет.

Очень толсто. Если 100 Мбит — это 12.5 МБ, то как же моя система на двух HDD в RAID1 вытягивает 80 МБ/с через SSH?

Один HDD даёт 250 МБ/с на последовательное чтение и запись. Передача большого файла будет близка к этому. Это уже даёт запас в 2 раза по скорости. Я тут вообще пока не вижу повода для беспокойства.

SMB прекрасно вывозит гигабит+ на канале 2-5 ms, и даёт чуть больше 10 MiB/s на канале в 60-70 ms.

Хмм, интересная информация.

Мне важна хорошая скорость в локалке и в пределах города, где я имею гигабитный аплинк. Пинг в локалке меньше 1 мс, по городу — 2.5 мс — проблемы быть не должно. Доступ нужен из любой точки планеты, но там всё равно будет говённый интернет, там я скорости не ожидаю.

А сможет ли твое железо вывозить шифрование этих скоростей?

Это будет уже следующий вопрос, потому что помимо шифрования трафика ещё будет luks. Если армовская плата не потянет, возьму miniITX на x86.

Посмотри еще в сторону s3-совместимых протоколов. Например какой-нибудь minio.

Спасибо, будем посмотреть.

Если будешь наркоманится в сторону FTP, то не забывай, что есть ещё FTPS (FTP+SSL).

Это будет уже следующий вопрос, потому что помимо шифрования трафика ещё будет luks. Если армовская плата не потянет, возьму miniITX на x86.

Так может и начнёшь с cryptsetup benchmark на интересующей тебя ARM-плате? Быстрее перестанешь страдать сабжем, возьмёшь x86, sshfs и вперёд?

Быстрее перестанешь страдать сабжем, возьмёшь x86, sshfs и вперёд?

SSH не едет быстрее 80 МБ/с на x86 тоже, при этом он не упирается ни в процессор, ни в диск. И то, 80 — это по rsync или gvfs, а scp всё так же не пробивает 30.

http(s)

https://www.disk91.com/2014/technology/networks/compare-performance-of-different-file-transfer-protocol-over-latency/

FTP всегда быстрее.

Менять алгоритм congestion control на BBR пробовал уже?

Бот ?

Нет, умный дядя Ринат с интересным советом.

Присоединяюсь к этому анониму. Если речь именно о NAS, то cifs и nfs – единственные стабильные и несложные решения.

Менять алгоритм congestion control на BBR пробовал уже?

Попробовал, нет эффекта. Пока я гоняю байты по локалке, я не думаю, что алгоритм вообще на что-то влияет.

Короче, решил я тут сделать кучу тестов между различными парами имеющихся у меня железок, и обнаружил следующее:

1. Не удалось воспроизвести результат «30 МБ/с с scp, но 80 МБ/с с rsync». Сегодня scp и rsync работают с одинаковой скоростью.
2. Скорость ssh примерно соответствует скорости, замеренной через dd+socat+openssl (была разница в несколько МБ/с, причём с разным перевесом на разных парах машин, но порядок тот же).
3. Во всех тестах в локалке узким местом был процессор более слабой машины. В одном тесте через интернет удалось выжать 100 МБ/с по ssh, и там узким местом была сеть.

Получается, что SSH не такой медленный, как я думал, и другие зашифрованные протоколы вряд ли будут быстрее (вряд ли они будут быстрее, чем передача ноликов через socat+openssl).

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

Если будет время, хочу ещё поднять ipsec и погонять iperf3 через него, вдруг по какой-то причине это будет быстрее, чем шифрование на прикладном уровне.

FTP бысрее ssh Проверено. И не раз.

Вопрос плавно перетекает в «Какой туннель самый быстрый»?

Не недо тут всупливать VPN Походу Бот отаетил.ь Реагирует боты на «переменые' и пролчию фигню.

Коллеги проверьте. На символ $ сбегаетеся тучв ботов.

Это не бот, слишком туп.

WebDAV. Умеет ли он сохранять mtime при выгрузке файлов на сервер?

Стандартно - нет.

Хорошая мысль, поддерживаю. Лучше реально эти задачи шифрования и передачи разделять и тогда и ftp отлично подойдёт.

Эта хорошая мысль становится не такой уж хорошей, когда тебе внезапно понадобилось поделиться файлом с посторонним юзером, у которого глаза не красные и винда за натом. Я хочу сказать, что в некоторых сценариях может понадобиться лепить многопротокольную шару, типа rw nfs|s3|ftps + ro http|webdav|hezapp.

Есть некий патчсет HPN-SSH, который должен что-то ускорить, но патчить SSH не очень хочется из соображений секурности.

Этот патчсет довольно продолжительное время поставляли по дефолту в генте и ЕМНИП он из коробки в CentOS 7 поставляется. Так что это не какие-то поделки васянов, а вполне себе стабильный продукт.

NFS. Вроде не работает через интернет?

Работает. Но лучше не надо. Плюс опять же вопрос безопасности там нормально решается только через Kerberos, ты заманаешься это всё через голый Интернет(без VPN) настраивать...

WebDAV. Умеет ли он сохранять mtime при выгрузке файлов на сервер?

owncloud/nextcloud использует webdav в качестве бэкенда. Дата модификации файлов - сохраняется. Умеет ли это делать нормально тот же davfs2 - хз, не интересовался.

помимо шифрования трафика ещё будет luks

без AES-NI будет кисло, не уверен в наличии аппаратно-ускоренного AES(и в поддержке этой фичи в Linux, если таковая имеется) на arm-платах

Один HDD даёт 250 МБ/с на последовательное чтение и запись. Передача большого файла будет близка к этому.

Это когда первый раз идет закачка файла, то все упирается в скорость дисков, следующий раз файл закачивается с кеша оперативы и скорость дисков уже не влияет. Все упрется в скорость сети или проц по шифрованию. Можно несколько сетевух в связку для увеличения скорости в многопользовательском режиме. На ARM64 надо пересобирать криптуху с оптимизацией под его «Neon» инструкции.

Дата модификации файлов - сохраняется. Редактируешь файл в среду, заливаешь в пятницу, скачиваешь в субботу и видишь в mtime среду? Родным клиентом или любым?

SSH (SFTP). По непонятным причинам медленный

По вполне понятным, тот cipher, что быстр на x86 (в котором есть avx2 и прочие разгрузочные инструкции), может быть ужасен на arm. Либо выключать шифрование для передачи файлов (что не интересно), либо играться с cipher’ами.

А ещё лучше, как уже посоветовали выше - раздели доступ к файлам и шифрование трафика. Под второе возьми wireguard, под первое - что угодно подходящее.

Родным клиентом Nextcloud - дата сохраняется.

Щаз глянул, у меня в нём лежат файлы помеченные как «изменен 17 лет назад». У меня тогда Интернета нормального не было, не то, что owncloud/nextcloud :-)

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

Даже на затхлом orange pi h6 есть какое-то аппаратное ускорение aes. Если платка от мобилки с поддержкой отпечатков пальцев, то там будет побольше крипты ускоренной чем на любом x86:)

не уверен в наличии аппаратно-ускоренного AES(и в поддержке этой фичи в Linux, если таковая имеется) на arm-платах

Конкретно на этой плате есть, но только AES-CBC: https://wiki.kobol.io/helios4/cesa/. В линуксе работает либо через AF_ALG, либо через /dev/crypto.

Кстати, там же есть результаты бенчмарков, и они вообще не впечатляют. Наверное, даже нет смысла пробовать — 47 МБ/с далеко от желаемого.

Очень странно, что они делали плату «специально для NAS», но не позаботились о нормальном шифровании.

следующий раз файл закачивается с кеша оперативы

Там её 2 гигабайта всего, ничего он не с кеша будет. Кроме чтения, ещё бывает запись на диск.

Родным клиентом Nextcloud - дата сохраняется.

Nextcloud, кстати, не умеет в mtime у каталогов. Потому что бывает, что не все подкаталоги синхронизированы, потом ты решил синхронизировать ещё один — mtime у родителя поменялось, следить и фиксить слишком геморно.

Но я не знаю, что для mtime использует nextcloud, там могут быть проприетарные расширения webdav или вообще кастомный эндпоинт. Интересовало как раз, как будет с условным davfs2 или gvfs.

Этот патчсет довольно продолжительное время поставляли по дефолту в генте и ЕМНИП он из коробки в CentOS 7 поставляется. Так что это не какие-то поделки васянов, а вполне себе стабильный продукт.

Это радует, что не поделки васянов. В генте юз-флаг есть, но по дефолту уже выключен. Если на armbian ставить, то тут малой кровью не обойтись, надо будет самому всё время собирать пакет при каждом обновлении.

Кстати, я видел на их сайте упоминание, что в ванильный openssh когда-то давно добавили AES-NI, и стандартное шифрование может быть быстрее, чем многопоточное из HPN. Не знаешь случайно, не допилили ли с тех пор в HPN поддержку AES-NI?

Не знаешь случайно, не допилили ли с тех пор в HPN поддержку AES-NI?

Тут я хз, для openssh придерживаюсь дефолта - мне такие скорости либо не нужны(передаю файлы не через SSH или через него, но эпизодически и всякие конфиги), либо SSH у меня упирается в скорость сети(дома до сих пор ADSL)

тем больше лишнего трафика шифруется

Ничего страшного, там единицы процентов при правильно начтроенной маршрутизации

rsync?

У ssh по умолчанию шифр чача используется и он не ускоряется аппаратно, если переделать на aes то возможно перестанет упираться в 100% цпу.

Пока я гоняю байты по локалке, я не думаю, что алгоритм вообще на что-то влияет.

Да, так и есть. В локалке задержки минимальные, и проблем с пропускной способностью нет. Но в локалке все методы расшаривания одинаково хорошо работают. Проблемы начинаются, когда растёт задержка пересылки пакетов и появляются потери. В таких условиях bbr выжимает почти весь канал. В моём случае rsync-через-ssh разогнался с 1-2 мегабайт в секунду до 10.

поднять ipsec

Wireguard тоже в ядре.

Там её 2 гигабайта всего, ничего он не с кеша будет.

Присматриваюсь к нормальным платам для NAS: https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-workstation/

ARM Cortex-A72 аппаратно умеет только AES, SHA1, SHA256: https://developer.arm.com/documentation/100097/0003/introduction/about-the-cortex-a72-processor-cryptography-engine?lang=en

Кроме чтения, ещё бывает запись на диск

Используй опции монтирования диска: lazytime , relatime, noatime, nodiratime, async.

Используй опции монтирования диска: lazytime , relatime, noatime, nodiratime, async.

только не все разом.
strictatime, relatime, noatime - основные и взаимоисключающие, из которых relatime по умолчанию давно и нет смысла его указывать.
nodiratime - модификатор, и с noatime смысла не имеет.
lazytime тоже модификатор.

я предпочитаю ленивый и правильный lazytime,strictatime

Для ARM ускорение есть или за счет Neon или в ARM64 свои инструкции для AES, SHA1, SHA256: https://www.linaro.org/blog/accelerated-aes-for-the-arm64-linux-kernel/

Есть тест Raspberry Pi 3 (as well as any other system using version r0p4 of the Cortex-A53), we can summarize the AES performance as follows..

чудес не бывает. всё что использует шифрование будет пробуксовывать на слабеньких армах.