From 4dc2d9bda136818589b90db3c1b96512433ce659 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Sat, 12 Dec 2020 16:49:23 +0300 Subject: [PATCH] =?utf8?q?=D0=9F=D1=80=D0=BE=D1=82=D0=BE=D0=BA=D0=BE=D0=BB?= =?utf8?q?=D1=8B=20=D0=BE=D0=B1=D0=BC=D0=B5=D0=BD=D0=B0=20=D1=84=D0=B0?= =?utf8?q?=D0=B9=D0=BB=D0=B0=D0=BC=D0=B8,=20IPsec,=20=D1=83=D0=B4=D0=B0?= =?utf8?q?=D0=BB=D1=91=D0=BD=D0=BD=D1=8B=D0=B9=20=D0=B4=D0=BE=D1=81=D1=82?= =?utf8?q?=D1=83=D0=BF?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit В моём идеальном мире между компьютерами должен быть IPsec. Аутентифицированный, всё такое. А не костыли транспортного уровня типа TLS per-application. Мне поэтому жутко не нравится когда протоколы делают без возможности использования TLS (ну вроде HTTP/2 хотели же) или когда говорят что FTP это не безопасно. Если поверх аутентифицированного доверенного IPsec, то какие проблемы? Кроме IPsec у меня на моих машинах гоняется и SSH. Вот зачем он мне? Для управления компьютерами вне IPsec (его же тоже нужно как-то настроить предварительно) конечно нужен, а в общем случае нет. Могу ли использовать старый добрый telnetd для этого? Попробовал -- могу, вроде бы всё терминальное (tmux там) работает. А вот все утилиты типа rlogin, rsh, rcp убраны уже в моей версии FreeBSD. Ну и нужно думать как бы автоматизировать telnet вход. А если чуть подольше подумать, то вообще аутентификация по ключам (для которых локально можно требовать парольную фразу) была бы в любом случае полезна. telnet намекает на то, что нужно Kerberos использовать. Но у меня с ним мало что выходило и я его боюсь. То есть SSH поверх IPsec был бы хорош всем, если бы можно было отключить шифрование трафика, ибо IPsec это делает. Такой опции из коробки нет. И вообще SSH это про удалённый доступ, а это значит мало трафика, ибо интерактив для человека. Поэтому плюнул на telnet+Kerberos идею. SSH всё равно будет для управления out-of-band IPsec и это уже рабочая инфраструктура, пускай и с overhead-ом, но для интерактивных сессий не страшного. А как быть с передачей файлов? NFS работает, но это кардинальное большое решение, не во всех случаях удобное. scp/sftp не хочется, так как это уже серьёзный overhead на шифрование, избыточное в IPsec сети. Один файл можно передать и просто по TCP сокету через netcat. Но продолжить прерванную передачу нельзя, если не считать руками байты и указать их для какого-нибудь dd при повторном запуске. python -m SimpleHTTPServer на одной стороне и fetch/wget/curl позволит продолжить докачку. tftp сервер просто и быстро поднимается, но всё же это уже больно не эффективный протокол. Да и, из-за ограничений размеров счётчиков, в нём только небольшие файлы можно передать. Хотя простота подкупает. А какие протоколы есть для передачи нескольких файлов, для получения списка директорий/файлов? FTP -- мамонт, не рассматриваю, хотя он подходит. Он должен уже не одно десятилетие назад вымереть. Его два TCP соединения -- та ещё заноза для firewall-а, да и много архаичного в нём, совершенно не актуального и избыточного для современного мира. lftp утилита позволяет одной командой зеркалировать целые FTP серверы/директории. SFTP -- подходит, но, как уже писал, ненужный overhead в IPsec сети. Я надеюсь что 9P на практике окажется очень здоровским протоколом, который бы и NFS наверное заменил. Но в FreeBSD его поддержка будет только в следующем релизе. Вспомнил про WebDAV. Который даже позволял из коробки в Windows 98 монтировать удалённые директории. Работало это на Windows у родителей не очень -- уже не помню конкретики, но вроде просто нестабильно. Но WebDAV чисто в теории мне нравится относительной простотой, возможностью использовать без WebDAV клиента (curl хватит или даже броузера), всякими докачками. В принципе годное решение. Да и всякие lighttpd/apache имеют из коробки webdav модуль. rsync ещё могу вспомнить, который по своему собственному протоколу может работать, без всяких SSH. В отличии от FTP, SFTP, WebDAV -- с большим количеством файлов/директорий он очень эффективен для зеркалирования. Никогда не пробовал, но man говорит что и докачивать файлы может (--append). Тоже годное решение, особенно учитывая что rsync часто есть на компьютерах и его демон настраивается куда проще чем HTTP-серверы. FISH https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol мог бы быть интересен, но отдельного клиента с ходу для него не увидел. lftp поддерживает fish://, но при этом запускает его поверх SSH насильно. UUCP мог бы отправлять/докачивать файлы в обе стороны -- в нём есть возможность не копировать файл в spool область. NNCP может только через копирование. Но это уже настройка знаний между компьютерами (хотя UUCP может и анонимным быть). Kermit решение вспомнил. http://www.columbia.edu/kermit/ckututor.html И Zmodem вместе с ним: https://ohse.de/uwe/software/lrzsz.html В lrzsz даже есть сразу поддержка TCP сервера-клиента и протоколов без коррекции ошибок (IPsec же!). Списка файлов нет. Но... по IPv4 оно у меня заработало, а по IPv6 нет -- ругается на какой-то format3, наверное адреса. Kermit, судя по исходникам, аналогично с IPv6 не должен дружить, но в нём хотя бы уже и списки файлов можно было бы получать. Но так можно накопать уже тьму другую софта, особенно ориентированного для быстрой передачи данных (из единственного TCP соединения сложно выжать скорость). -- 2.48.1