LINUX.ORG.RU
ФорумAdmin

Быстрый протокол для удалённого доступа к файлам

 , , ,


0

4

Разыскивается протокол для доступа к NAS со следующими требованиями:

  1. Должен вывозить гигабит в любую сторону.
  2. Шифрование. Безопасность такая, чтоб не страшно было через интернет этим пользоваться.
  3. Отсутствие тупорылых ограничений в стиле «имена файлов не могут содержать запрещённые в венде символы», «каталоги не имеют reliable mtime».
  4. Метаданные (такие как mtime) не теряются при копировании и перемещении между локальной и удалённой ФС.

Что я рассматривал/пробовал:

  • SSH (SFTP). По непонятным причинам медленный. scp просто упирается примерно в 30 МБ/с. gvfs и rsync выжимают 80 МБ/с между машинами на x86, но когда сервер — плата на ARM (helios4 NAS), оно тоже останавливается примерно на 30 МБ/с. Я ожидаю числа, более близкие к 125 МБ/с. Узкое место не в дисках. На ARM идёт жор процессора на 100%, на x86 нет. Есть некий патчсет HPN-SSH, который должен что-то ускорить, но патчить SSH не очень хочется из соображений секурности.
  • FTP. Не годится из-за отсутствия шифрования, ещё эта наркомания с двумя соединениями, пассивным режимом, conntrack и т.д.
  • SMB. Не годится из-за наркоманских ограничений на имена файлов, стрёмно использовать через интернет из-за критических уязвимостей в прошлом.
  • NFS. Вроде не работает через интернет?
  • WebDAV. Умеет ли он сохранять mtime при выгрузке файлов на сервер? Как минимум реализация в gvfs это не делает, насколько я вижу из кода. Если сам протокол это поддерживает, gvfs можно починить (gvfs-sftp я уже чинил).

Какие вообще остаются варианты нормального доступа к файлам по сети в 2021?

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

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

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

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

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

BOOBLIK ★★★★
()

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

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

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

anonymous
()

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

Bootmen ☆☆☆
()

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

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

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

vvn_black ★★★★★
()
Ответ на: комментарий от vvn_black

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

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

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

gentoo_root ★★★★★
() автор топика
Ответ на: Насколько удалённого доступа к файлам? от BOOBLIK

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

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

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

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

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

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

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

gentoo_root ★★★★★
() автор топика

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

beastie ★★★★★
()
Ответ на: комментарий от gentoo_root

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

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

t184256 ★★★★★
()
Ответ на: комментарий от t184256

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

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

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от Bootmen

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

t184256 ★★★★★
()
Ответ на: комментарий от anonymous

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

i586 ★★★★★
()
Ответ на: комментарий от i-rinat

Менять алгоритм 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 через него, вдруг по какой-то причине это будет быстрее, чем шифрование на прикладном уровне.

gentoo_root ★★★★★
() автор топика

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

fulmar_lor
()
Ответ на: комментарий от fulmar_lor

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

anonymous
()

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

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

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

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

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

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от gentoo_root

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

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от gentoo_root

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

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

anonymous
()
Ответ на: комментарий от Pinkbyte

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

anonymous
()

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

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

zemidius
()

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

zemidius
()
Ответ на: комментарий от anonymous

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

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от zemidius

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

pon4ik ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

pon4ik ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

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

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

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

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

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

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

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

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

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

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

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

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

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

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от gentoo_root

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

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от pon4ik

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

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

zemidius
()

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

theurs ★★
()
Ответ на: комментарий от gentoo_root

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

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

поднять ipsec

Wireguard тоже в ядре.

i-rinat ★★★★★
()
Ответ на: комментарий от gentoo_root

Там её 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.

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

boowai ★★★★
()

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

Rost ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.