Как свя­зать ста­рые сис­темы с новыми сетями.

Большинство исторических протоколов продолжают жить в программном обеспечении еще долго после своего пика популярности и остаются доступными, если вдруг нужны, а иногда и переживают неожиданное возрождение. Одновременно с этим, активные протоко­лы могут утрачивать совместимость и создавать больше неудобств старым клиентам, чем старые-новым.

Gopher

В настоящее время Gopher является прямым предком HTTP и World Wide web. Конец 1980-х годов – это время его взлета и падения. Как бы это не было странно но протокол Gopher, а также его эталонная реализация не были открытыми стандартами и свободными ПО. Это его и сгубило: с ростом популярности протокола его разработчик — университет Миннесоты — решил, что ему нужно получать лицензионные отчисления с серверов, на которых он разместил свои разработки. Ясно что отчисле­ния никто не платил и поэтому все перешло в создающийся World Wide Web, ведь HTTP являлся открытым стандартом. По имеющимся данным, университет Миннесоты принял решение о смене лицензии на свободную, но это было уже поздно.

В общем, о Gopher можно было бы и забыть, но забыли далеко не все. Как ни парадоксально это звучит, в конце 2010-х годов число серваков Gopher снова возросло. Окончательная победа Web и продолжающийся рост сложности браузеров привели к тому, что создать новый браузер с нуля практически невозможно, а сервисы интернета все больше оказываются в руках крупных компаний-конкурентов. Спасти ситуацию может разработка новых про­токо­лов вро­де Gemini, или в возврате к Gopher.

По сравнению с новыми альтер-натив-ными протоко-лами, Gopher обладает довольно неплохой экосистемой. Это поддерживают энту­зиасты, которые помогают в реализации поисковых систем  и серверов а также бесплатный хостинг.

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

Не вер­но обратное: все современные браузеры уже давно отказались от встроенной поддержки (как сейчас отказывают в поддержке FTP), а потом и все API расширений, которые позволяли эту поддержку реализовывать. На данный момент поддержка осталась в Lynx и w3m. Firefox позволяет расширять возможности работы с сетью и добавлять новые протоколы посредстом внешних хелперов а например Google Chrome не пре­дос­тавля­ет даже этого. Это все наталкивает на мысль: может, в словах современных любителей Gopher о монопо­лии браузеров и есть раци­ональное зерно…

HTTPS

А вот с World Wide Web ситуация иная. Сайты на серверах с устаревшим ПО остаются все так же доступны для новых браузероа, а вот старые браузеры зачастую не в состоянмм выполнить запрос на новые сервера.

Ни Gopher, ни обычное HTTP не поддерживали шифрование, поскольку они были разработаны в эпоху, когда в защите было мало потребности, а распространение программного обеспечения для шифрования часто подчинялось тем же правилам, что и экспорт оружия. Сейчас ситуация совершенно иная, поэтому обязательное перенаправление с HTTP на HTTPS давно стало стандартом, а поддержка устаревших алгоритмов шифрования и цифровых подписей регулярно удаляется из новых версий браузеров, чтобы избежать downgrade attacks и угроз дол­говре­мен­ной крип­тостой­кос­ти. По соображениям безопасности это большое преимущество, но для любителей ретро-вычислений или вынужденных пользователей систем, где просто обновить браузер больше невозможно, наоборот, это большая проблема.

Для этих случаев Александр Тауенис разработал проект под названием WebOne. Это специализированный прокси-сервер, который в простейшем случае принимает запрос от клиента на http://example.com, делает запрос на https://example.com и возвращает ответ, как если бы HTPS не было. Поскольку взаимодействие между клиентом и прокси-сервером осуществляется через обычный HTTP, поддержка текущих версий TLS на стороне клиента больше не является проблемой — вы можете использовать Netscape или Mosaic.

Но этим его воз­можнос­ти не огра­ничи­вают­ся. Кроме того, он также поддерживает трансляцию URL, замену регулярной части в тексте страницы и даже транскодирование изображений и видео с помощью внешних скриптов.

Для при­мера мож­но рас­смот­реть нас­трой­ку под­мены адре­са биб­лиоте­ки jQuery из стан­дар­тно­го кон­фига.

[Edit:jquery.min.js]

Проект написан на C #, но он также хорошо работает в Linux через ядро ​​.NET. По умолчанию после запуска исполняемого файла WebOne он слышит на адресе 0.0.0.0:8080. Для своих виртуальных машин на VirtualBox я прописываю параметр DefaultHostName = 192.168.56.1 в конфигурации /etc/WebOne/webone.conf, чтобы он слушал только внутренний интерфейс (адаптер только для хоста).

TFTP

Протокол-долгожитель TFTP (Trivial File Transfer Protocol), появившийся в 1981 году (RFC 784), до сих пор актуален. По этой причине стандартным способом загружать по сети образ ОС является PXE, использующий именно этот протокол для передачи образа операционной системы и ее файлов.Технически современные сис­темы с UEFI вполне могли бы себе позволить встроенный клиент HTTPS, но PХE требует соответствующей опции DHCP для передачи адреса и пути к файлу, так что поменять этот стандарт не так просто. С другой стороны — всё и так неплохо работает.

Как правило не плохо, но бывает всякое). К сожалению некоторые прошивки материнских плат и встраиваемых устройств реализуют TFTP не корректным или просто непонятным способом, и отправляют кривые пути к файлам, которые сервер не понимает. Но чаще всего это бывает так, что обновление этой прошивки не планируется и не планировалось.

При этом важно помнить, что некоторые реализации сер­вера TFTP могут транслировать запросы. Кроме того, в частнос­ти, tftpd-hpa за авторством извес­тного разработчика ядра Linux Ганса Петера Анвина под­держивает опцию mapfiles.

Син­таксис замен напоми­нает син­таксис sed. Нап­ример, мож­но заменить (r) все (g) обратные сле­ши пря­мыми.

rg \\ /

Telnet и rlogin

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

В пакете inetutils в комплекте с актуальными ping и whois присутствуют также telnetd и rlogsind/rshd. Разумеется, пользоваться этими вещами в локальной сети — это просто отвратительно, а выставлять их в публичную сеть просто немыслимо.

Однако, если вы хотите войти в современную систему или скопировать файлы из нее в какую-нибудь древнюю Unix-подобную ОС, они вполне могут пригодиться. Поскольку rlogin / RSH / RCP появился еще в 1981 году, а Telnet — еще раньше, этот метод может работать даже с самыми старыми системами, если они могут быть подключены к современной сети.

По словам разработчиков, в Fedora компоненты inetutils находятся в отдельных пакетах. Следует отметить, что эти программы, как и многие другие старые демоны, являются не «обычными» демонами, а скорее службами Inetd. К счастью, разработчики пакетов создали для них служебные файлы systemd, поэтому начать работу легко — вам не нужно возиться с xinetd вручную.

По словам разработчиков, в Fedora компоненты inetutils находятся в отдельных пакетах. Следует отметить, что эти программы, как и многие другие старые демоны, являются не «обычными» демонами, а скорее службами Inetd. К счастью, разработчики пакетов создали для них служебные файлы systemd, поэтому начать работу легко — вам не нужно возиться с xinetd вручную.

Пос­мотрим на моей Fedora 33. Нач­нем с Telnet.

[dmbaturin@careless ~]$ sudo dnf install telnet-server telnet

За­пус­тить rlogind ничуть не слож­нее.

[dmbaturin@careless ~]$ sudo dnf install rsh-server rsh

В отличие от реализации SSH, telnetd и rlogind поддерживают только интерактивные сеансы. Утилиты RSH и RCP взаимодействуют не с rlogind, а с соответствующим демоном, rshd. Если rlogin хотя бы знает, как запрашивать пароль (даже если он передается в виде открытого текста), то в настоящее время rshd поддерживает только один совершенно абсурдный метод «аутентификации» — файл ~ / .rhosts.

$ echo "localhost dmbaturin" > ~/.rhosts

Да, что­бы успешно исполь­зовать rcp или rsh, дос­таточ­но знать имя поль­зовате­ля и ука­зать вер­ное имя хос­та, ничего дру­гого знать не надо.

$ rsh localhost uname