Коммуникации в store-and-forward режиме, UUCP

    Сейчас в мире Интернета преобладающее количество всех служб работают в режиме online: то есть постоянное соединение с Интернетом и серверами. Если HTTP, FTP или IRC сервер недоступен, то вам об этом сразу же явно сообщат. Не всегда есть возможность иметь такую роскошь как постоянный online. Иногда это дорого, иногда просто технически невозможно. Есть опасность что появится Великий Российский Firewall который будет разрешать только whitelist доступ к ресурсам и доступность «полноценного» Интернета, в лучшем случае, будет только от места к месту. Режим работы при котором данные для отправки сохраняются и ожидают пока появится связь называется store-and-forward. Именно этот режим удобно позволяет работать в условиях непостоянного online.



    Из широкораспространённых сервисов только email (SMTP) имеет что-то похожее на это: вы отправляете сообщение и оно сохраняется на сервере до тех пор, пока он не сможет соединиться с принимающим сервером и получить успешный код ответа. И так по всей цепочки пока письмо не дойдёт до адресата. По почте можно передавать и файлы, но крайне неэффективно из-за Base64 кодирования. Заранее настроив почтовый сервер, можно отправлять на специальные адреса сообщения в которых будут команды для выполнения — то есть удалённое выполнение команд не требующих интерактивного вмешательства и гарантированных жёстких сроков выполнения.

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

    Полностью в таком режиме работает сеть FidoNet. Человек, например, пару раз в день подключается к вышестоящей ноде и получает пачку писем, отправляет свою накопившуюся. Затем в offline режиме читает и отвечает на полученные сообщения. Стоит ли возрождать FTN (FidoNet Technology Network) технологии и снова их использовать? Лично я считаю что нет: FTN создавалась любителями для домашних компьютеров. Я бы сказал что FTN это UUCP (UNIX-to-UNIX CoPy) для «бедных», для тех у кого нет UNIX-like операционных систем. Кроме того, весь FTN софт стоит особняком от Интернет технологий. UUCP же хорошо интегрируется с существующими технологиями.

    UUCP позволяет удобно разрешить проблему создания store-and-forward сервисов. Он был очень популярен в 70-х и 80-х годах и был де-факто стандартом связи между UNIX системами, задолго до широкого распространения Интернета.

    • Поведение системы, находись она подключённой к сети, или находясь в offline — не отличимо. Если вы отправляете файл или почтовое сообщение по UUCP: для вас это всегда успешный код возврата. Если в почтовых клиентах вы ещё можете сохранить сообщения в черновиках, то подобного функционала для сообщений от cron демона или git-send-email нет. Это значительно упрощает ПО.
    • У всех участников сети нет чётко заданной модели поведения: вы можете принимать почту или файлы в режиме polling (когда самостоятельно время от времени опрашиваете удалённую систему), можете сделать явный push. Тем самым, вы делаете как вам удобнее и эффективнее в ваших условиях эксплуатации. Вы в состоянии будете связать две системы находящиеся за NAT-ом через промежуточный узел, без использования каких-либо дополнительных протоколов или программных служб.
    • Для приёма и отсылки писем и файлов используется один и тот же протокол — нет разделения, например, на SMTP и POP3. Более того, приём и отправка данных происходят параллельно в пределах одного канала связи, что повышает его эффективность использования.
    • UUCP позволяет продолжить оборванную передачу данных, не начинать с нуля. Это бесценно при плохих или медленных или короткоживущих каналах связи.
    • Есть поддержка приоритезации трафика: в момент отправки сообщений вы можете указать их важность (grade). Так можно гарантировать что тяжёлый большой файл не будет мешать прохождению небольших почтовых сообщений или удалённых команд.
    • Протокол работает поверх любых соединений передающих двусторонний поток байт. Это может быть последовательный COM-порт, модем, TCP, stdin/stdout запущенной программы. Наличие IP протокола не имеет значения.
    • В отличии от электронной почты Интернета, нет ограничений связанных с 7-битными каналами связи. Вы можете передавать бинарные файлы без дополнительных Base64/whatever преобразований, что существенно экономит трафик.
    • UUCP доступен во всех свободных операционных системах. Де-факто используется GNU Taylor UUCP реализация. Она уже много лет не развивается — потому-что в ней просто нечего доделывать, она работает.
    • Все популярные почтовые серверы Интернета типа sendmail, Exim и Postfix из коробки имеют возможность интеграции с UUCP. Сами по себе утилиты имеют классический UNIX way подход: делай одну небольшую вещь, но делай её хорошо. В отличии от FTN сетей, вы можете прозрачно связывать UUCP и Интернет ресурсы воедино.


    Используя современные определения, UUCP является F2F (friend-to-friend) сетью. Вы явно руками самостоятельно прописываете и настраиваете все ваши взаимосвязи с «друзьями». Более того, вы явно управляете маршрутизацией сообщений. Да, это бОльшая ответственность и трудозатраты, но зато хорошая защита от возможных DoS атак, от централизованных серверов которые могут применять цензуру. F2F сети саморегулируются: злоумышленников и людей с плохим поведением из сети просто выкинут, как это происходило в FidoNet. Это работает достаточно хорошо и это на практике уже показало что сеть может иметь глобальные масштабы, а не только быть у кучки любителей.

    Однако в UUCP есть и поддержка неизвестных (unknown), анонимных пользователей. То есть сделать публичный всем доступный сервер для раздачи файлов, или даже с возможностью их закачивания, возможно из коробки.

    UUCP не предлагает ничего связанного с криптографией. В текущих реалиях, когда модемы уже мало у кого есть, как и телефонные линии, использовать криптографию хотя бы для аутентификации нод уже необходимо. Благо вы вольны делать это как вам удобнее. Если для физически изолированных air-gapped, Sneakernet/FloppyNet или соединённым по ЛВС систем на это ещё можно закрыть глаза, то для связи по публичным каналам связи можно быстро поднять stunnel, SSH, VPN или что-то подобное. Поднять UUCP в виде скрытого сервиса Tor или I2P становится тривиально.

    Покажем насколько проста конфигурация UUCP на примере связи двух компьютер через Интернет. Один не делает никаких исходящих соединений (назовём его alpha), в отличии от второго (назовём его beta).
    alpha% cat /usr/local/etc/uucp/config
    nodename alpha
    
    alpha% cat /usr/local/etc/uucp/passwd
    betalogin betapassword
    
    alpha% cat /usr/local/etc/uucp/sys
    system beta
    called-login betalogin
    
    ------------------------ >8 ------------------------
    
    beta% cat /usr/local/etc/uucp/config
    nodename beta
    
    beta% cat /usr/local/etc/uucp/call
    alpha betalogin betapassword
    
    beta% cat /usr/local/etc/uucp/port
    port tcp
    type tcp
    
    beta% cat /usr/local/etc/uucp/sys
    call-login *
    call-password *
    time any
    
    system alpha
    port tcp
    address alpha.com
    


    Это вся конфигурация. Мы задачи порт «tcp», логин/пароль для доступа, названия UUCP нод. Если мы хотим вызывать SSH вместо прямого TCP соединения, то достаточно описать новый «порт»:
    beta% cat /usr/local/etc/uucp/port
    port ssh
    type pipe
    command ssh -o batchmode=yes alpha.com
    


    Если мы хотим соединяться по COM-порту, но при его недоступности попытаться TCP, то создадим ещё один порт и укажем альтернативную конфигурацию для системы (альтернатив может быть много):
    beta% cat /usr/local/etc/uucp/port
    port tcp
    type tcp
    
    port serial
    type direct
    device /dev/cuaU0
    speed 115200
    
    beta% cat /usr/local/etc/uucp/sys
    call-login *
    call-password *
    time any
    
    system alpha
    port serial
    protocol g
    
    alternate
    
    port tcp
    address alpha.com
    protocol t
    


    При этом, для последовательного соединения мы указали использовать протокол «g» (используется для ненадёжных каналов связи, самостоятельно проверяет целостность и перепосылает данные), а для TCP, который уже является надёжным каналом связи, протокол «t».

    При такой конфигурации мы уже можем послать файл с beta на alpha:
    beta% uucp myfile.txt alpha!~/myfile.txt
    


    По-умолчанию в UUCP "~/" это не домашняя директория пользователя, а публичная область для всех, аналог «pub» директории в FTP. В моей системе это директория /var/spool/uucppublic/. В sys файле вы можете для каждой системы указать в какие директории можно посылать файлы или из каких их запрашивать. Таким же образом и alpha может послать файл, но он будет передан только когда beta подсоединится. Есть удобная утилита uuto которая может отправить файл заданному пользователю на заданную систему:
    % uuto myfile.txt remote!username
    


    А на удалённой remote системе пользователь может вызвать uupick которая ему покажет список всех отосланных ему файлов и позволит, например, их переместить в указанную директорию.

    Если вам надо отправить файл на gamma систему, имеющую связь с beta, то вы явно должны указать маршрут следования файла:
    % uucp myfile.txt beta!gamma!~/myfile.txt
    


    UUCP позволяет посылать задание на выполнение команд на удалённой системе:
    % uux "remote!service nginx restart"
    % uux "remote!zfs snap zroot@backup"
    


    На принимающей системе отдельный uuxqt демон занимается запуском принимаемых таким образом команд. В sys файле вы можете управлять тем, какие команды разрешено запускать той или иной системе:
    % grep commands /usr/local/etc/uucp/sys
    commands rmail /home/uucp/wget.sh
    


    В данном случае можно выполнять только команду rmail и wget.sh. wget.sh это пример самописного простого скрипта который скачает Web-страницу и через UUCP отправит её в сжатом зашифрованном виде с минимальным приоритетом:
    #!/bin/sh -e
    WORKDIR=/home/uucp/wget_dir
    name="$1"
    url="$2"
    wget --output-document - "$url" | xz -9 | gpg \
        --homedir /home/uucp/.gnupg --compress-level 0 --encrypt \
        --recipient 0xHIDDEN > $WORKDIR/"$name".xz.gpg
    uuto --grade 9 $WORKDIR/"$name".xz.gpg 'sgtp!vpupkin'
    


    Электронная почта отправляется именно как uux команда вызывающая rmail утилиту которая, фактически, связывается с локальным sendmail сервером и посылает тело сообщения в него. Например, для того чтобы Postfix смог отсылать принимаемую из Интернета почту на UUCP удалённый сервер, то достаточно (также это описано здесь):
    • раскомментировать строчки с uucp/uux в master.cf
    • добавить UUCP домен в relay_domains/relay_domains
    • указать в transport как производить relay на домен:
      % cat /usr/local/etc/postfix/transport
      cypherpunks.ru uucp:sgtp
      cryptoparty.ru uucp:sgtp
      

      Тут видно для доменов cypherpunks.ru/cryptoparty.ru почту нужно слать через UUCP на «sgtp» ноду.


    Чтобы отсылать почту с локальной машины через UUCP шлюз, то кроме раскомментирования uucp/uux строк в master.cf, достаточно добавить в main.cf:
    default_transport = uucp:uucp-gateway
    


    Поддержка UUCP в Exim и sendmail аналогично просто настраивается.

    Таким образом, мы легко можем получить во всех современных свободных операционных системах удобную работу в условиях непостоянной связанности компьютеров между собой. Можно эффективно (без накладных расходов на Base64 например) передавать файлы и обмениваться электронной почтой практически без лишних телодвижений. Кроме того, выполнять пачкой (batch) удалённые команды куда проще чем через создание сервисов управляемых через email.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 7

      +1
      Очень подробная инструкция, но не понятно ответа на один вопрос: «зачем?». Есть достаточно сервисов, которые «из коробки» предлагают пиринговый обмен файлами.
        0
        Какие например? Основное условие: у нас нет Интернета.
          0
          Не могу себе представить такой ситуации. Если нет интернета, но есть телефон с модемом, то лично мне проще тряхнуть стариной и настроить FTN, может только в этой ситуации статья и поможет. Ситуацию со связью компьютеров по ком-порту или через ещё какой-то флоппинет (для сети на переносимых USB-флешках даже термина нет :-) )

          Ну и всё-таки покажите мне пальцем где в статье написано как настраивать копирование нужных файлов на флешку или рассписание модеменых звонков. Потому что я этого в статье не увидел.
            0
            Вот именно это статья и хотела показать: что гораздо проще настроить UUCP чем поднимать FTN-инфраструктуру. UUCP тесно интегрируется например с уже существующими почтовыми серверами, как минимум.

            Термин для сети на флешках: sneakernet.

            Статья не пыталась покрыть все возможные use-case-ы и пошаговые инструкции на все случаи жизни. Для этого уже стоит посмотреть в документацию проекта. Статья призвана показать простоту настройки пары общих случаев: дальше, за деталями, уже в документацию Taylor UUCP (кстати отлично написанную и полную).
              0
              В любом случае спасибо за статью. Она напоминает о том, что прежде чем изобретать велосипед надо подумать какой старый проверенный механизм можно применить :-)
        0
        В uucp не реализован TLS, т.е. нет uucps. Сейчас передавать почту в открытом виде неприемлемо, а поднимать openvpn или ssh-туннель, чтобы внутри него запустить uucp, мало кто захочет.
          0
          Во-первых, не вижу ничего сложного или отпугивающего от того что вам даётся возможность выбора как лучше реализовать шифрование: сделать ssh и туннелировать stdin/stdout, сделать stunnel чтобы организовать TLS по моему проще не куда, тем более что stunnel уже давно является неким де-факто для превращения «протокола» в «протоколs».

          Во-вторых, TLS из коробки сильно заточен под PKI инфраструктуру: то есть это иерархия для «передачи» доверия. UUCP априори не является иерархией или чем-то похожим: в UUCP вы чётко понимаете и знаете как у вас пойдёт пакет данных. Использовать PKI-заточенную инфрраструктуру для end-to-end, friend-to-friend соединений просто неразумно. Плюс TLS хоть и распространён, но на данный момент один из самых громоздких, сложных и плохо продуманных протоколов и многие стараются держаться от него подальше.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое