Он же сказал им: цари господствуют над народами, и владеющие ими благодетелями называются, а вы не так: но кто из вас больше, будь как меньший, и начальствующий — как служащий. Лк. 22:25,26
Грешить Интернетом я начал с 2004 года, а соблазном на первых порах выступила местная локальная сеть. Точнее, программа под названием DC++ 0.401, магическим образом дававшая доступ к файлам, которыми делились другие абоненты той же локалки. Для этого нужно было подключиться к одному или нескольким узлам файлообменной сети, называемым хабами. Сами хабы держали на своих компьютерах местные энтузиасты.
В этом была своя прелесть. Вот ты вне сети, а вот уже и внутри, среди людей, совершивших примерно те же действия, что и ты ранее. Удивительно, правда?
Скоро выяснилось, что то же самое можно, в принципе, делать не только в пределах локальной сети, но и сквозь Интернет… Общаться, дружить, ругаться, договариваться, создавать свои ресурсы, продвигать их, улучшать, пробовать другие клиенты, искать дыры и уязвимости, заниматься промышленным шпионажем, связываться с разработчиками и т.д. и т.п.
Тёплый ламповый DC++ v. 0.401
В-общем, DC с его простыми функциями общения и обмена файлами с успехом служило социальной сетью тех времён. И человеческое лицо по ту сторону экрана проглядывало настолько, насколько ты сам хотел его увидеть.
Прошли годы. Локальные хабы сдулись и издохли. Под натиском Фейсбука, ВКонтакте и торрента DC съёжилось до менее чем пяти сотен публичных хабов на старом NMDC протоколе и десятка (sic!) на протоколе Advanced Direct Connect.
Как уважаемые читатели уже знают, весь трафик россиян сохраняется до поры до времени. Дарить его в открытом виде — негигиенично, но именно это делают пользователи Direct Connect.
Итак, что требуется? Во-первых, шифровать общение DC клиента с хабом. Во-вторых, шифровать общение клиентов между собой.
И вот тут начинаются проблемы на всех уровнях этой простой и столь похожей на человеческое общество цифровой иерархии.
Внезапно, подходящих хабов не обнаруживается. На старом NMDC протоколе их нет физически. ADCs же хабы существуют примерно с 2008 года, но погоды не делают, ибо так и остались малютками. Стало быть, такой ресурс придётся развернуть самостоятельно из уже существующего ADC хаба.
Программная поддержка TLS в DC клиентах есть уже давно, но, поскольку не было кейсов её применения, в этот раздел настроек тоже никто особо не заглядывал. А зря!
Перевести существующий ADC хаб на шифрование несложно. Сгенерировать самоподписанный сертификат, скормить его движку, выбрать «политику» TLS.
Но дело в том, что безопасное соединение с хабом устанавливается при использовании ссылки вида adcs://hub.address.com:port
Настройка же «политики» TLS состоит в том, чтобы или одобрять обычные соединения (то есть переход по ссылке вида adc://hub.address.com:port), или перенаправлять такого пользователя куда-нибудь (например, на «правильный» адрес).
Первый вариант оставляет возможность подключения к хабу пользователей с клиентами, которые не умеют TLS версии выше 1.0 (или вообще не умеют), что создаст проблемы; а второй обещает резкое падение посещаемости.
Да, получается, хаб в этом случае выступает своеобразным цензором и гарантом номинальной возможности безопасных соединений.
Есть у старого протокола один глобальный недостаток: невозможность для сети работать как единое целое при количестве хабов больше одного. Да, для локальных сетей один большой хаб это норма, но де-факто один пользователь на двух разных хабах это два совершенно разных пользователя со всех возможных точек зрения (кроме самого пользователя, но и это не точно).А если уж получится подключиться к хабу более одного раза, то начинается полный фарш.
Администраторам и владельцам крупных DC хабов на данный момент интересно только количество пользователей онлайн и что с этого можно поиметь. Пользователи покупаются и продаются; отсутствует культура взаимодействия между админами и пользователями, отсутствует сообщество. Отсутствует, если хотите, мораль, вместе с ней этика и понятие нормы, а возникающие проблемы решаются по понятиям. А Вы помните буквальный перевод слова server?..
Вот и получается феодальная раздробленность. Выгоднее (для кого?) оказывается разрешать всё всем (например, использовать устаревшие 10 и более лет назад клиенты с известными уязвимостями), чем выступать гарантом чего бы то ни было.
Что владельцы хабов сделали наверняка — так этозадолбали замучали юзеров спамом с требованием зайти куда-то или зачем-то зарегистрироваться вместо распространения внятных инструкций в случае наступления типичных ситуаций.
Не добавила в своё время DC популярности и необходимость проброса портов на роутере и знание «качества» своего IP-адреса. Процедура нетрудная, но по сей день вызывающая проблемы.
Как следствие, на данный момент донести до пользователя хаба в пределах самого хаба полезную информацию проблематично. Не читают!
Мы рассмотрели теорию и проблемы перевода уютного файлообмена в рамках Direct Connect на использование современного шифрования, необходимого в наши дни. Как видите, для этого пришлось указать на изъяны взаимодействия юзер <=> программа-клиент <=> хаб <=> администратор и придумать его заново.
Во второй части статьи планируется рассмотреть практику выбора и настройки DC клиента для работы на ADCs хабе.
История
Грешить Интернетом я начал с 2004 года, а соблазном на первых порах выступила местная локальная сеть. Точнее, программа под названием DC++ 0.401, магическим образом дававшая доступ к файлам, которыми делились другие абоненты той же локалки. Для этого нужно было подключиться к одному или нескольким узлам файлообменной сети, называемым хабами. Сами хабы держали на своих компьютерах местные энтузиасты.
«DC++» это название клиента. Протокол называется «Direct Connect». DC хабы. DC клиенты.
В этом была своя прелесть. Вот ты вне сети, а вот уже и внутри, среди людей, совершивших примерно те же действия, что и ты ранее. Удивительно, правда?
Скоро выяснилось, что то же самое можно, в принципе, делать не только в пределах локальной сети, но и сквозь Интернет… Общаться, дружить, ругаться, договариваться, создавать свои ресурсы, продвигать их, улучшать, пробовать другие клиенты, искать дыры и уязвимости, заниматься промышленным шпионажем, связываться с разработчиками и т.д. и т.п.
Тёплый ламповый DC++ v. 0.401
В-общем, DC с его простыми функциями общения и обмена файлами с успехом служило социальной сетью тех времён. И человеческое лицо по ту сторону экрана проглядывало настолько, насколько ты сам хотел его увидеть.
Прошли годы. Локальные хабы сдулись и издохли. Под натиском Фейсбука, ВКонтакте и торрента DC съёжилось до менее чем пяти сотен публичных хабов на старом NMDC протоколе и десятка (sic!) на протоколе Advanced Direct Connect.
Начало
Как уважаемые читатели уже знают, весь трафик россиян сохраняется до поры до времени. Дарить его в открытом виде — негигиенично, но именно это делают пользователи Direct Connect.
Итак, что требуется? Во-первых, шифровать общение DC клиента с хабом. Во-вторых, шифровать общение клиентов между собой.
И вот тут начинаются проблемы на всех уровнях этой простой и столь похожей на человеческое общество цифровой иерархии.
Хабы
Внезапно, подходящих хабов не обнаруживается. На старом NMDC протоколе их нет физически. ADCs же хабы существуют примерно с 2008 года, но погоды не делают, ибо так и остались малютками. Стало быть, такой ресурс придётся развернуть самостоятельно из уже существующего ADC хаба.
Клиенты
Программная поддержка TLS в DC клиентах есть уже давно, но, поскольку не было кейсов её применения, в этот раздел настроек тоже никто особо не заглядывал. А зря!
Перевести существующий ADC хаб на шифрование несложно. Сгенерировать самоподписанный сертификат, скормить его движку, выбрать «политику» TLS.
Но дело в том, что безопасное соединение с хабом устанавливается при использовании ссылки вида adcs://hub.address.com:port
Настройка же «политики» TLS состоит в том, чтобы или одобрять обычные соединения (то есть переход по ссылке вида adc://hub.address.com:port), или перенаправлять такого пользователя куда-нибудь (например, на «правильный» адрес).
tls_private_key="/etc/uhub/babylon.aab21pro.org.key"
tls_certificate="/etc/uhub/babylon.aab21pro.org.crt"
tls_enable=yes
tls_require=yes
tls_require_redirect_addr=adcs://babylon.aab21pro.org:412Первый вариант оставляет возможность подключения к хабу пользователей с клиентами, которые не умеют TLS версии выше 1.0 (или вообще не умеют), что создаст проблемы; а второй обещает резкое падение посещаемости.
*** Connecting to adcs://babylon.aab21pro.org:412…Такое сообщение при попытке соединения с ADCs хабом отображает клиент, умеющий только TLS v.1.0
*** SSL Error 1: tlsv1 alert protocol version
Да, получается, хаб в этом случае выступает своеобразным цензором и гарантом номинальной возможности безопасных соединений.
Админы
Есть у старого протокола один глобальный недостаток: невозможность для сети работать как единое целое при количестве хабов больше одного. Да, для локальных сетей один большой хаб это норма, но де-факто один пользователь на двух разных хабах это два совершенно разных пользователя со всех возможных точек зрения (кроме самого пользователя, но и это не точно).
Администраторам и владельцам крупных DC хабов на данный момент интересно только количество пользователей онлайн и что с этого можно поиметь. Пользователи покупаются и продаются; отсутствует культура взаимодействия между админами и пользователями, отсутствует сообщество. Отсутствует, если хотите, мораль, вместе с ней этика и понятие нормы, а возникающие проблемы решаются по понятиям. А Вы помните буквальный перевод слова server?..
Вот и получается феодальная раздробленность. Выгоднее (для кого?) оказывается разрешать всё всем (например, использовать устаревшие 10 и более лет назад клиенты с известными уязвимостями), чем выступать гарантом чего бы то ни было.
Пользователи
Что владельцы хабов сделали наверняка — так это
Не добавила в своё время DC популярности и необходимость проброса портов на роутере и знание «качества» своего IP-адреса. Процедура нетрудная, но по сей день вызывающая проблемы.
Как следствие, на данный момент донести до пользователя хаба в пределах самого хаба полезную информацию проблематично. Не читают!
Итоги
Мы рассмотрели теорию и проблемы перевода уютного файлообмена в рамках Direct Connect на использование современного шифрования, необходимого в наши дни. Как видите, для этого пришлось указать на изъяны взаимодействия юзер <=> программа-клиент <=> хаб <=> администратор
Во второй части статьи планируется рассмотреть практику выбора и настройки DC клиента для работы на ADCs хабе.
