Ходячие мертвецы. Как подружить устаревшие сетевые протоколы с современными

Содержание статьи

• Gopher
• HTTPS
• Telnet и rlogin
• TFTP
• Заключение

Да­же сетевые про­токо­лы иног­да уми­рают. Если заг­лянуть в спи­сок номеров про­токо­лов IP на сай­те IANA, там мож­но уви­деть как исто­ричес­ки важ­ные, но дав­но не исполь­зуемые про­токо­лы вро­де CHAOS, так и нас­толь­ко проч­но забытые, что для них не ука­зана даже рас­шифров­ка аббре­виату­ры. Что такое 49/BNA, нап­ример? Ник­то не вспом­нит.

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

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]

; Redirect all requests to jQuery of versions other than 1.9.1 to Google's CDN with

; the last version supported by Firefox 3.6. This will not touch WebDAV traffic.

; Title: RegExp mask of URLs that should be touched by this Set of edits.

; IgnoreUrl: RegExp mask(s) of URLs which should NOT be touched by this Set of edits.

; OnUrl: additional URL RegExp masks not listed in section's title.

; AddRedirect: the destination URL of this redirection rule

IgnoreUrl=1.9.1

IgnoreUrl=webdav

OnUrl=jquery2.js

OnUrl=jquery-[0-9]*\.[0-9]*\.[0-9]*\.min\.js

IgnoreUrl=webdav

AddRedirect=http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js

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

TELNET И RLOGIN

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

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

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

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

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

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

[dmbaturin@careless ~]$ sudo systemctl start telnet.socket

[dmbaturin@careless ~]$ telnet localhost

Trying ::1...

Connected to localhost.

Escape character is '^]'.

Kernel 5.11.14-200.fc33.x86_64 on an x86_64 (9)

careless login:

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

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

[dmbaturin@careless ~]$ sudo systemctl start rlogin.socket

[dmbaturin@careless ~]$ rlogin localhost

Password:

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

$ echo "localhost dmbaturin" > ~/.rhosts

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

$ rsh localhost uname

Linux

$ rcp localhost:/tmp/test .

INFO

Пог­ружать­ся в исто­рию и экспе­римен­тировать с RSH/RCP луч­ше все­го на машине с отклю­чен­ным SELinux. Мож­но, конеч­но, выс­тавить кон­текст фай­лу коман­дой restorecon -R ~/.rhosts и дать rshd раз­решение на sys_resource, но про­ще вре­мен­но про­писать selinux=0 в опции заг­рузки ядра.

TFTP

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

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

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

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

rg \\ /

ЗАКЛЮЧЕНИЕ

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

Источник