TELNET— основы использования. Методы подключения к удаленным устройствам при помощи команды telnet

Telnet – базовый протокол ОС UNIX, обеспечивающий терминальный доступ пользователей к удалённому компьютеру .

Первоначально терминалом являлось устройство типа пишущей машинки, на котором оператор (пользователь) печатал команды и наблюдал результаты. Позднее терминал разделили на монитор и клавиатуру.

По умолчанию в Telnet используется 23 порт. На удалённом компьютере должна быть запущена серверная часть, а на компьютере пользователя – клиентская. Клиентская программа носит то же название – telnet и допускает ввод параметров из командной строки. К этим параметрам относятся:

Имя (IP адрес) сервера и номер порта

Тип текстового терминала

Имя пользователя

Имя журнала соединения

Определение действий некоторых функциональных клавиш клавиатуры и др.

Синтаксис командной строки зависит от программной реализации telnet и с этой точки зрения telnet можно рассматривать как службу или сервис.

Работа протокола telnet предусматривает передачу серверу (удалённому компьютеру) по протоколу ТСР каждого набранного пользователем знака в отдельном пакете. В случае включённого эха сервер возвращает знак на монитор пользователя. Результаты выполнения запущенных на сервере программ передаются уже блоками. В пределах прав пользователя и возможностей терминала telnet обеспечивает полный доступ к программам и файлам сервера. При установлении соединения в процессе аудентификации символы имени пользователя и пароля передаются в открытом виде, что делает использование telnet крайне опасным.

Наиболее популярный метод повышения безопасности прикладных терминальных протоколов (например, telnet) является протокол SSH (Secure SHell), использующий 22 порт по умолчанию. Так же, как и в telnet, на удалённом компьютере запускается серверная часть SSH, а на пользовательском компьютере – клиентская. После установления соединения все данные передаются в зашифрованном виде и все данные прикладных протоколов туннелируются по этому защищённому соединению как это показано на рисунке 3.5.3.1.

Перед использованием telnet удалённый компьютер и компьютер пользователя устанавливают защищённое соединение по 22 порту (подразумевается, что до использования SSH в клиентской и серверной части уже определены пароли криптографической защиты). При вызове telnet открывается 23 порт, но передаваемые пакеты перехватываются клиентом SSH, шифруются и отправляются по защищённому каналу. Сервер SSH расшифровывает данные и по 23 порту передаёт серверу telnet. Реакция сервера передаётся в обратном порядке. Пользователь не ощущает работы протокола SSH и работает как с обычным клиентом telnet по 23 порту.

Протоколы электронной почты

Электронная почта (E-mail) – один из старейших и наиболее распространённых сетевых сервисов, популярных как в локальных, так и глобальных сетях .

Система электронной почты появилась в 1982 г. как сервис предка Internet сети ARPANET. Эта система значительно отличалась от принятых CCITT рекомендаций серии X.400. Сложность рекомендаций Х.400 и их непродуманность привели к редкому для сетевых технологий случаю, когда инициативная разработка победила международный стандарт. Службы электронной почты, отвечающие Х.400, не нашли широкого применения и представляют скорее научный интерес.

Электронное почтовое сообщение, как и в обычной почте, содержит конверт с необходимой для доставки информацией, заголовка с полезными для автоматизированной обработки адресатом данными и собственно сообщения.

Конверт и заголовок имеют формализованные поля. Наиболее важными из них являются (обязательные для заполнения отправителем поля выделены жирным шрифтом):

То: - адрес (а) получателя (лей) в формате имя_ящика@имя_почтового_сервера

Сс: - (carbon copy) адрес (а) дополнительного (ных) получателя (лей)

Bcc: - (blind carbon copy) слепой (ые) адрес (а) получателя (лей), о которых другим не сообщается

Sender: - адрес отправителя письма

Received: - поле, куда при прохождении каждого узла добавляется имя узла, дата и время приёма

Return-Path: - имена узлов на пути письма

Date: - дата и время отправки письма

Reply-to: - адрес, куда надо ответить

Message-id: - уникальный идентификатор письма (для ссылок)

In-Reply-id: - идентификатор письма, на которое даётся ответ

Subject: - тема письма

Тело сообщения представляет собой набор строк из не более, чем 1000 (рекомендуется до 78) ASCII (American Standard Code for Information Interchange) знаков, т. е. 7-и битных чисел, представляющих буквы латинского алфавита, знаки препинания и цифры (популярным для такого представления является термин «кодировка»). Символы национальных кодировок (например, знаков кириллицы), двоичные файлы (например, с аудио, или видео информацией) и др. отображаются в соответствии с соглашением MIME (Multipurpose Internet Mail Extension – многоцелевые расширения электронной почты в Интернете), которое предусматривают поле с указанием способа кодировки (например, Base64 – см. параграф 3.5.2).

Базовым методом обеспечения конфиденциальности электронной почты является её криптографическая защита. Наиболее популярная система именуется PGP (Pretty Good Privacy - достаточно хорошая конфиденциальность). Эта система предложена Филом Циммерманом (Phil Zimmerman) и предусматривает использование нескольких алгоритмов шифрования (RSA, IDEA, MD5).

Другая система носит название PEM (Privacy Enhanced Mail – почта повышенной секретности) и отличается от PGP необходимостью связи с центрами сертификации ключей, меньшей степенью защиты (для кодирования данных в системе PGP используется ключи длинной 128 бит, а в системе PEM – только 56 бит), но полным соответствием рекомендациям ITU-T (Х.400 и Х.509).

Протоколы электронной почты характеризуются значительным разнообразием от фирменных, пригодных в программных продуктах конкретных фирм-производителей, до общепризнанных. Речь идёт о протоколах именно систем электронной почты, а не о распространённых системах эмуляции почтовых служб на базе протокола НТТР (см., например, www. mail. ru).

Среди почтовых протоколов можно выделить:

SMTP (Simple Mail Transfer Protocol – простой протокол электронной почты) – протокол, используемый для обмена почтой между узлами и отправки писем от клиента к почтовому серверу. По умолчанию протокол использует 25 порт.

РОР3 (Post Office Protocol v.3 –протокол электронной почты версии 3) – протокол для получения почты клиентом. По умолчанию протокол использует 110 порт.

IMAP v4 (Internet Message Access Protocol v.4 –протокол интерактивного доступа к электронной почте версии 4) – протокол, аналогичный РОР3, но позволяющий клиенту хранить и обрабатывать почту на самом почтовом сервере. По умолчанию протокол использует 585 порт

Протокол SMNP

Протокол SNMP (Simple Network Management Protocol – простой протокол сетевого управления) первоначально разрабатывался для управления маршрутизаторов, но затем был расширен на любые сетевые устройства (по умолчанию порты 161/162). В настоящее время актуальна версия 2 протокола (1999 г.) .

Протокол построен по принципу клиент - сервер (на управляемом сетевом устройстве должна быть запущена программа клиента) и включает в себя протокол управления (взаимодействие управляемого и управляющего узлов), язык ASN.1 (Abstract Syntax Notation v.1 - абстрактная синтаксическая нотация версии 1) описания модели управления и собственно модель управления MIB (Management Information Base - база управляющей информации). Распространению протокола мешает его низкая защищённость и ориентация на использование протокола UDP, приводящего к возможной потере сообщенийDNS

Задача разрешения имен подразумевает определение IP адреса узла по его символьному имени и определение символьного имени по заданному IP адресу.

Исторически первый, но до сих пор действующий механизм разрешения имен связан с прямым заданием таблицы соответствия символьных имён и IP адресов в файле hosts/lmhosts (первый файл используют UNIX/Linux и некоторые др. операционные системы (ОС), а второй – ОС фирмы Microsoft). Оба файла текстовые и их форматы и ключи можно найти в MS Windows в одноимённых файлах с расширением. sam (sample – образец). Очевидно, для сколько-нибудь крупной сети решить задачу таким образом полностью не представляется возможным, хотя запись в эти файлы сведений об основных серверах, маршрутизаторах, шлюзах и пр. весьма эффективна для ускорения старта компьютера в сетевом окружении.

Другой, достаточно популярный способ разрешения имён связан с использованием NetBIOS (Network Basic Input/Output System) поверх TCP/IP . Эта система была разработана совместными усилиями Microsoft и IBM в 80-е годы как сетевой сервис ввода/вывода для операционной системы Windows. Позже, для реализации доступа пользователей к ресурсам сети был разработан протокол NetBEUI (NetBIOS Extended User Interface – расширенный пользовательский интерфейс NetBIOS) как основной сетевой протокол в ОС Windows for Workgroups и NT. Наконец, с повсеместным распространением стека TCP/IP компания Microsoft была вынуждена выпустить реализацию NetBIOS, использующую протокол IP для передачи необходимых данных (NetBIOS поверх TCP/IP). До сих пор продолжается поддержка NetBIOS в ОС Windows 2000/NT/XP, правда уже не как основного механизма доступа к ресурсам сети. NetBIOS целесообразно использовать в небольших, одноранговых сетях.

Изначально, каждый узел в сети с NetBIOS имеет символьное имя (до 15 знаков) с идентификатором ресурса (16-ый знак), который указывает на роль узла (файловый сервер, принт-сервер, рабочая станция и пр.). «Чистый» NetBIOS применим только для небольших сетей и считается «немаршрутизируемым», т. к. –

система имён не позволяет идентифицировать сеть

широко используются широковещательные запросы для получения и обновления сведений об узлах сети (большинство маршрутизаторов широковещательные запросы не пропускают)

Для устранения указанных недостатков компания Microsoft предложила службу WINS (Windows Internet Name Service – служба Windows имен Internet) на базе серверов имен NetBIOS. Следует отметить, что несмотря на упоминание сети Internet, WINS не применяется в этой глобальной сети.

Первый недостаток NetBIOS устраняется в WINS тем, что вводится групповое имя для сети, а второй – тем, что запросы при разрешении имён обращены к конкретным серверам WINS. Неустойчивость в работе службы, трудности администрирования и затруднительность использования в глобальной сети Internet, к настоящему моменту заставили компанию Microsoft перейти к полноценной поддержке DNS.

DNS (Domain Name System – доменная система имён) реализуется с помощью одноименного прикладного протокола, использующего по умолчанию 53 порт . Система DNS была разработана в рамках ОС UNIX и соответствующая служба, использующая DNS, имеет ту же аббревиатуру, но расшифровывается как Domain Name Service.

Имена в DNS строятся по иерархическому принципу в виде перевёрнутого дерева. Домены верхнего уровня (корневые) делятся по профессиональному принципу (. com - коммерческие,. gov - государственные,. net - сетевые и пр. узлы) или по национальному (. ru - русские,. fi - финские,. fr - французские и т. д.). ОС UNIX разрабатывалась в США и, само собой считалось, что все узлы находятся там же. Сейчас можно встретить двойные имена доменов, например,. com. tw – коммерческие тайваньские.

В свою очередь, каждый домен содержит поддомен, имя которого добавляется слева и отделяется точкой, и т. д. Заканчивается запись добавлением слева имени узла. Имя каждого домена, поддомена или узла не должно превышать 63 символа, а полное имя – 255 символов. Для обозначения имён традиционно используется латинский алфавит, цифры и тире (знак _ недопустим), но, в принципе, можно зарегистрировать домен с именем на кириллице, но смысл этого проблематичен.

Данные об именах зарегистрированных в любом домене поддоменов/узлов и их IP адресах хранятся в двух таблицах на DNS-серверах, где также имеется имя и адрес вышележащего домена. По первой таблице для заданного символьного имени определяется цифровой адрес (прямое преобразование и, соответственно, т. н. «прямая зона»), а по второй - по заданному адресу находится символьное имя (обратное преобразование и «обратная зона»).

Для повышения надёжности в каждом домене должно быть не менее 2-х серверов (primary - первичного и secondary - резервного), причём физически эти серверы должны находиться в разных сетях и могут располагаться не в тех доменах, имена узлов которых они содержат.

Корневой домен поддерживают свыше 10 DNS серверов, IP адреса и имена которых «зашиты» в сетевые ОС. Регистрацию новых имён и выделение соответствующих IP адресов производит владелец домена. Например, регистрацию в домене. ru производит РосНИИРОС, где регистрация имени и получение IP адреса обойдётся приблизительно в 50$, а годовая поддержка адреса – в 10$.Все изменения в таблице имен производятся на первичном DNS сервере, резервные серверы только обновляют свои записи по записям первичного сервера. Репликация (обновление) зоны производится с помощью надёжного протокола TCP, в то время, как для DNS запросов клиентов, применяется протокол UDP. Для ускорения процесса разрешения имени и уменьшения трафика в сети иногда устанавливают так называемые кэш-серверы DNS, которые записывают часто используемые имена и адреса.Режим работы DNS сервера может быть рекурсивным и не рекурсивным. В случае рекурсивного режима при невозможности разрешить DNS запрос этот запрос транслируется специально заданному другому DNS серверу (форвардеру – forfarders), который затем возвращает полученный ответ. При не рекурсивном режиме - в отсутствии информации о запрашиваемом узле производится обращение к корневым DNS серверам, а от них вниз по цепочке до получения ответа.

NAT (Network Address Translation - трансляция сетевых адресов) реализует преобразование (подмену) IP адресов локальных сетей во внешние IP адреса глобальной сети Internet . Необходимость такого преобразования следует из соглашения об использовании части IP адресов только в локальных сетях (см. п. 3.2), по которому маршрутизаторы глобальной сети уничтожают пакеты с этими адресами.

NAT действует на сетевом и частично на транспортном уровнях, обеспечивая преобразование в IP пакетах адресов узлов локальной сети во внешний адрес. Преобразование производится путём замены адреса внутреннего узла на внешним адрес. Заменяемые адреса запоминаются в таблице, с помощью которой производится обратная замена при получении ответного пакета. Следует отметить, что для устранения возможной неразличимости преобразуется не только IP адрес, но и с помощью PAT (Port Address Translation) номер порта.

Кроме преобразования адресов NAT позволяет уменьшить потребность в IP адресах для глобальных сетей, т. к. все пользователи локальной сети могут получать доступ к ресурсам глобальной сети через один внешний адрес.

NAT - не единственный способ отправки пакетов из локальной сети в глобальную, альтернативой трансляции адресов является использование сервера-посредника.

Telnet (англ. TE rminaL NET work ) - протокол прикладного уровня, используемый для реализации двунаправленного интерактивного текстового интерфейса в сети через виртуальный терминал. Данные от пользователя перемешиваются с управляющими командами TelNet в восьмибитные байт-ориентированные данные, передаваемых по протоколу TCP. TelNet был разработан в 1969 году. Первой версией была RFC 15 , далее расширенная в RFC 854 и далее стандартизированная в один из первых интернет-стандартов IETF STD 8. Telnet обеспечивает доступ к командной строке операционной системы на удалённом хосте, поддерживая большинство видов сетевого оборудования и операционных систем с утилитой конфигурации, однако из-за серьёзных проблем в безопасности использования Telnet в открытой сети (Интернет), всё чаще для этих целей используют протокол SSH. Однако, Telnet часто используют также и для ссылки на программное обеспечение, содержащее клиентскую часть протокола, так как клиентские приложения Telnet доступны практически для всех компьютерных платформ.

История и стандарты

Telnet это протокол клиент-сервер. Как правило, он используется, чтобы установить соединение с TCP порт 23, где находится серверное приложение Telnet. Однако, до появления TCP/IP Telnet использовал протокол NCP. Официальную огласку Telnet получил 5 марта 1973 года, после того как стандарт протокола был определён в UCLA. Из-за нечёткой архитектуры опций протокола было сделано много расширений, некоторые из которых были приняты (STD 27, STD 32), широко реализованы, а так же предложены в числе стандартов IETF.

Безопасность

При первоначальной разработке telnet в 1969 году большинство пользователей подключенных к сети компьютеров или находились в компьютерных отделениях академических учреждений, или являлись частью правительственных/частных исследований. Поэтому вопросы безопасности вставали не так остро, как это стало позднее, в 1990-х. Резко выросло людей, имеющих доступ к Интернету, а значит и количество людей, пытающихся взломать чужие сервера. Это вызвало необходимость в зашифрованных альтернативах. Эксперты компьютерной безопасности рекомендовали, чтобы использование Telnet для удалённых входов в систему было прекращено во всех нормальных обстоятельствах по следующим причинам:

• Telnet по умолчанию не шифрует оправленные данные (включая и пароли), а значит очень легко подслушать канал и узнать пароли. Для этого достаточно иметь доступ к маршрутизатору, свитчу, хабу или шлюзу, расположенных между двумя использующимися узлами Telnet, и любой имеющий к ним доступ может прервать передачу пакетов, получить логин и пароль вне зависимости от анализатора пакетов.
• Во многих реализациях Telnet нет аутентификации, которая обеспечила бы гарантию передачи пакетов и отсутствия вторжения посередине.
• Обнаружено несколько уязвимостей демонов, который обычно использует Telnet

Эти связанные с безопасностью недостатки наглядно показывали, что использование протокола Telnet в общедоступной сети опасно и неоптимально. Позже, в 1995 году, появился протокол SSH (Secure Sell), который обеспечивал большинство функций Telnet, а так же предоставлял устойчивое шифрование и публичный ключ аутентификации, для того, чтобы предотвратить перехват уязвимых данных и подтвердить подлинность удалённого компьютера. Как и и другие ранними интернет-протоколами, расширения Telnet используют TSL и SASL для обеспечения начального уровня безопасности. Однако, поддерживают эти функции далеко не все расширения, а интереса к реализации более защищённых средств не было из-за появления SSH, достаточного для большинства целей.

Известно, что большое количество промышленных и научных устройств для коммуникации есть только Telnet. Некоторые имеют только стандартный порт RS-232 и используют серверные устройства для передачи данных между TCP/Telnet и RS-232. В таких случаях устройства не могут быть сконфигурированы под SSH и этот стандарт неприменим.

Telnet 5250

Эмулятор рабочей станции IBM 5250 или 3270 поддерживается через пользовательские клиенты Telnet - TN5250/TN3270. Клиентские и серверные части разработаны так, чтобы передать данные IBM 5250 потоком через Telnet с использованием шифрования SSL, как делает это SSH и не включая эмцляцию 5250. С OS/400, 992 порт является по умолчанию портом защищённого Telnet.

Вид данных в Telnet

Все байты кроме 0xff передаются по Telnet как есть. Поэтому клиент Telnet может использоваться для установки интерактивной чистой TCP-сессии, и обычно такая не использующая IAC(0xff или 255) считается функционально идентичной. Однако, на деле всё не так: существуют иные правила виртуального терминала NVT, такие как требование сопровождения символа возврата каретки пустым символом NULL, которые отличают протокол Telnet от чистой сессии TCP. С другой стороны сегодня множество систем обладают настоящим необработанным TCP, например netcat или socat на UNIX и PuTTY на Windiws, которые можно использовать чтобы вручную обмениваться данными с другими службами без специального клиентского ПО. Тем не менее, Telnet всё ещё используется в отладке некоторых сетевых служб, таких как SMTP, IRC, HTTP, FTP или серверов POP3 - Telnet посылает команды к серверам и исследует ответы, но из всех этих стандартов только FTP использует специфичный формат данных Telnet

Ещё одно отличие Telnet от необработанного сеанса TCP - Telnet по умолчанию не чисто восьмибитный. Восьмибитный режим может быть согласован, но октеты высокого набора битов могут быть искажены до согласования, и это очевидно не требуется в не-Telnet соединении. 8-битный режим предназначен для передачи двоичных данных, а не символов. Стандарт предполагает интерпретацию кодов 000-176 как ASCII, но не предполагает значения для октетов высокого набора битов. Была попытка представить переключаемую опцию поддержки кодировки символов (например, как у HTTP), но сейчас ничего не известно о её актуальной программной поддержке

Связанные RFC

Интернет-стандарты

• RFC 854 , Telnet Protocol Specification
• RFC 855 , Telnet Option Specifications
• RFC 856 , Telnet Binary Transmission
• RFC 857 , Telnet Echo Option
• RFC 858 , Telnet Suppress Go Ahead Option
• RFC 859 , Telnet Status Option
• RFC 860 , Telnet Timing Mark Option
• RFC 861 , Telnet Extended Options: List Option

Предполагаемые стандарты

• RFC 885 , Telnet end of record option
• RFC 1073 , Telnet Window Size Option
• RFC 1079 , Telnet terminal speed option
• RFC 1091 , Telnet terminal-type option
• RFC 1096 , Telnet X display location option
• RFC 1123 , Requirements for Internet Hosts - Application and Support
• RFC 1184 , Telnet Linemode Option
• RFC 1372 , Telnet Remote Flow Control Option
• RFC 1572 , Telnet Environment Option
• RFC 2941 , Telnet Authentication Option
• RFC 2942 , Telnet Authentication: Kerberos Version 5
• RFC 2943 , TELNET Authentication Using DSA
• RFC 2944 , Telnet Authentication: SRP

1. Когда устанавливается TELNET соединение, предполагается, что на каждом конце соединения порождается и завершается "Виртуальный Сетевой Терминал" или ВСТ. ВСТ - это воображаемое устройство которое предоставляет стандартное, доступное через cеть, промежуточное представление классического терминала. Это устраняет необходимость в "серверном" и "клиентском" узлах для хранения информации о характеристиках каждого терминала и договоренностей о взаимодействии. Все узлы, как клиентский, так и серверный, отображают свои локальные характеристики устройства с тем, чтобы выступать в сети как ВСТ, и каждый мог принять похожее отображение с другой стороны. ВСТ предназначен для сведения баланса между чрезмерным ограничением и чрезмерными возможностями.
   Примечание : "Пользовательский" хост - это обычно хост с привязанным к нему физическим терминалом, а "серверный" хост - это обычно хост предоставляющий некий сервис. Как альтернативную точку зрения, можно рассматривать случай когда соединяются равные хосты: терминал-терминал или процесс-процесс. Таким образом будем считать "пользовательским" хостом тот хост который инициирует соединение.
2. Принцип оговоренных опций охватывает тот факт, что многие хосты скорее всего будут хотеть предоставить дополнительные сервисы до или после их доступности в ВСТ, и многие пользователи захотят иметь сложные терминалы с элементами изысканности, вместо минимальных, для получения таких дополнительных сервисов. Независимые от, но структурированные в TELNET протоколе различные "опции" санкционированы и могут быть использованы с "DO, DON"T, WILL, WON"T" структурой (обсуждается ниже) для того, чтобы позволить пользователю и серверу сходиться в использовании более продуманного (или отличного) набора соглашений для их TELNET соединения. Такие опции включают изменение набора символов, режима эха, и т.д.
   Базовая стратегия для налаживания использования опций - это на одной из сторон (или на обоих) инициировать запрос: будет ли определенная опция иметь какой либо эффект. Другая сторона может либо принять, либо отвергнуть запрос. Если запрос принимается, то опция немедленно вступает в силу; если же опция отвергается, то связанный аспект соединения остается как специфицировано для ВСТ. Очевидно, что сторона может всегда отвергать запрос на включение, и никогда не должна отвергать запрос на отключение некоторой опции начиная с момента когда стороны договорились о поддержке ВСТ.
   Синтаксис оговоренной опции должен быть таким, чтобы если обе стороны запросят одновременно опцию, то каждый будет рассматривать запрос с другой стороны как положительное подтверждение этой опции.
3. Симметричность синтаксиса согласования может потенциально привести к бесконечному циклу согласования - когда каждая сторона видит входящие команды не подтверждает их, но для подтверждения посылает новый запрос. Для предотвращения таких циклов, необходимо придерживаться следующих правил:
   • Стороны могут запрашивать только изменение статуса опции; т.е. сторона может не посылать "запрос" только для того, чтобы сообщить, что данная опция поддерживается.
   • Если сторона получает что-то, что интерпретируется как запрос переключения в некоторый режим в котором эта сторона уже находится, то на такой запрос не нужно отправлять подтверждения.
   • Всякий раз, когда одна сторона отправляет команду опции на другую сторону, не важно запрашивая или подтверждая, и использование опции должно иметь какой либо эффект на обработку данных, отсылаемых первой стороной второй стороне, то команда опции должна быть вставлена в потоке данных в том месте, с которого желательно, чтобы опция вступила в силу. (Следует отметить, что пройдет некоторое время между передачей запроса и получением подтверждения, и оно может быть отрицательным. Таким образом, хост может буферизовать данные, после отправки запроса опции и до получения ответа с принятием или отвержением опции, для того, чтобы скрыть "период неопределенности" от пользователя.)

Вероятно, что сразу после установки TELNET соединения, запросы опций будут шквалом передаваться в обоих направлениях соединения, из-за того, что каждая сторона будет пытаться получить наилучший сервис от другой стороны. Кроме того, опции могут быть использованы для динамического изменения характеристик соединения с тем, чтобы соответствовать изменяющимся локальным условиям. Например, ВСТ, как будет описано ниже, использует дисциплину передачи, хорошо подходящую для многих приложений "строка за раз" (таких как BASIC), но плохо подходит для приложений "символ за раз" (таких как NLS). Сервер мог бы выделить дополнительное процессорное время требуемое для дисциплины "символ за раз" если это подходит для локального процесса и договориться о соответствующей опции. Хотя, вместо того, чтобы надолго обременяться дополнительной тратой процессорного времени, можно переключиться (т.е. договориться) вернуться назад к ВСТ, когда детальный контроль больше не требуется.

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

Проектировщики опции не должны себя чувствовать стесненными несколько ограниченным синтаксисом для оговоренной опции. Смысл простого синтаксиса состоит в том, чтобы упростить принятие опции. Если некоторая специфическая опция требует более сложной структуры согласований чем имеющаяся в "DO, DON"T, WILL, WON"T", то необходимо сначала договориться через существующую структуру согласований, а после того, как обе стороны удостоверятся в понимании этой опции, использовать свободно более экзотический синтаксис. Например, одна из сторон могла бы послать запрос на изменение (установку) длинны строки. Если он принимается, то может быть использован отличный от базового синтаксис для того, чтобы фактически договориться о длине строки; такие "под-согласования" могли бы включать поля для минимально, максимально и желательных длин строки. Важно то, что такие расширенные согласования никогда не должны начинаться, пока "стандартные" переговоры не привели к тому, что обе стороны могут понимать расширенный синтаксис.

В итоге, WILL XXX посылается одной из двух сторон, для того чтобы показать желание (предложение) стороны исполнять опцию XXX, DO XXX и DON"T XXX являются подтверждением и отвержением опции XXX соответственно, на запрос WILL XXX; аналогично, DO XXX отправляется для того, чтобы показать желание другой стороны (т.е. получателя DO) начать исполнять опцию XXX, WILL XXX и WON"T XXX являются подтверждением и отвержением опции XXX соответственно, на запрос DO XXX. Так как ВСТ - это то, что остается когда никакие опции не включены, ответы DON"T и WON"T гарантируют что соединение останется в состоянии которым обе стороны могут управлять. Таким образом, все хосты могут реализовать свои TELNET процессы так, чтобы они вообще не знали об опциях которые не поддерживаются, просто возвращая отвержение (т.е. отказываясь от опции) на любой запрос опции, которую данный процесс не может понять.

Протокол TELNET был сделан максимально симметричным по отношению к связке пользователь-сервер, для того, чтобы он легко и естественно покрывал случаи пользователь-пользователь и сервер-сервер. Желательно, но не обязательно, чтобы опции сохраняли этот принцип. В любом случае явно признается, что симметрия - это принцип, а не правило.

Сопутствующий документ "TELNET Option Specifications" предназначен для того, чтобы черпать из него информацию о процедуре написания новых опций.

Виртуальный Сетевой Терминал

Виртуальный Сетевой Терминал (ВСТ) является двунаправленным символьным устройством. У ВСТ есть принтер и клавиатура. Принтер отвечает за входящие данные, а клавиатура производит исходящие данные, которые передаются по TELNET соединению и если необходимо "эхо" - то эти данные так же передаются и на принтер ВСТ. Предполагается, что "эхо" не будет передаваться по сети (хотя существуют опции, которые позволяют включать "удаленный" режим эха операции, но хост не обязан поддерживать эту опцию). Набор символов - это семибитовый USASCII в восьмиразрядном поле, кроме изменений описанных в данном документе. Любое преобразование кодировки и анализ времени - это локальные проблемы и не затрагивают ВСТ.

Передача данных

Хотя сетевому TELNET подключению свойственен полный дуплекс, ВСТ должен рассматриваться как полудуплексное устройство, работающее в буферизированном строковом режиме. Таким образом пока стороны не договорились об опциях, следующие условия должны выполняться по умолчанию для передачи данных по TELNET соединению:

1. Насколько позволяет локальный размер буфера, данные должны накапливаться на том хосте, где они вводятся, до тех пор пока не будет готова к передаче полная строка данных или пока не будет подан явный локальный сигнал к передаче. Этот сигнал может быть сгенерирован процессом или человеком.
   Причиной этого правила является высокая стоимость обработки входящих сетевых прерываний для некоторых хостов, а так же заданное спецификацией ВСТ "эхо" которое не должно передаваться через cеть. Таким образом кажется разумным буферизовать некоторое количество данных на стороне их источника. Многие системы предпринимают некоторые действия по обработке в конце каждой входящей строки (например, устройства построчной печати) и таким образом передача данных должна быть инициирована в конце строки. С другой стороны, пользователю или процессу может иногда понадобиться передать данные, которые не заканчиваются переводом строки и поэтому необходимо предусмотреть методы, которыми можно передать все буферизированные локальные данные немедленно.
2. Когда процесс завершил отправку данных на принтер ВСТ и не имеет никакого очередного ввода с клавиатуры ВСТ для дальнейшей обработки (т.е., в случае когда процесс на одном конце TELNET соединения не может продолжить без входящих данных с другой стороны) он должен передать команду Go Ahead (GA).
   Это правило не является обязательным и не требует, чтобы команда GA отправлялась в конце каждой строки, так как серверы обычно не требуют специального сигнала (в дополнение к концу строки или другим локально определенным символам) чтобы начать обработку. Правильнее будет сказать, что команда TELNET GA сделана, чтобы помочь локальному компьютеру пользователя управлять физическим полудуплексным терминалом (например, IBM 2741) у которого есть "блокируемая" клавиатура. Описание этого терминала может помочь в понимании правильного использования команды GA.
   Соединение терминал-компьютер всегда находится под контролем пользователя или компьютера. Ни один не может в одностороннем порядке захватить контроль над другим. На стороне терминала аппаратные средства реализованы так, чтобы отдавать контроль всякий раз, когда "строка" закончена (т.е. когда клавиша "конец строки" нажата пользователем). И когда это происходит, присоединенный (локальный) компьютер обрабатывая входные данные, решает, должен ли генерироваться вывод и если не должен, возвращает контроль терминалу. Если вывод должен генерироваться, то контроль сохраняется за компьютером пока все данные не будут переданы.
   Трудности использования терминала такого типа по сети очевидны. "Локальный" компьютер более не в состоянии решить, сохранять ли контроль или нет после того, как был обнаружен сигнал конца строки; это решение может быть принято только "удаленным" компьютером, который обрабатывает данные. Поэтому команда TELNET GA обеспечивает механизм, посредством которого "удаленный" (сервер) компьютер может сообщить "локальному" (пользователю) компьютеру, что настало время передачи управления пользователю терминала. Это должно быть передано тогда и только тогда, когда пользователь должен контролировать терминал. Отметим, что преждевременная отправка команды GA, может привести к блокированию вывода, так как пользователь, вероятно, будет предполагать, что передающая система сделала паузу и поэтому он вряд ли введет перевод строки вручную.

Вышесказанное, конечно, не относится к направлению соединения пользователь-сервер. В этом направлении, GA можно отправить в любой время, но эта команда в этом направлении никогда не должна посылаться. Кроме того, если TELNET соединение используется для коммуникации типа процесс-процесс, то команду GA нельзя отправлять ни в одном из направлений. И в заключении, для соединения терминал-терминал, команда GA может не потребоваться в одном или обоих направлениях. Если хост планирует поддерживать соединение типа терминал-терминал, предполагается, что такой хост предоставит пользователю возможность вручную сообщить, когда нужно отправить команду GA; это требование не является обязательным для реализующего сторону типа "процесс".

Отметим, что симметричная модель TELNET требует, по крайней мере концептуально, чтобы ВСТ присутствовал на каждом конце TELNET соединения.

Стандартное представление управляющих функций

Как уже говорилось во Введении к этому документу, основная цель протокола TELNET - это обеспечить стандартный сетевой интерфейс терминальным устройствам и терминал-ориентированным процессам. Ранний опыт с этим типом соединения показал, что определенные функции осуществимы для большинства серверов, а вот методы вызова этих функций достаточно широко различаются. Для человека, который взаимодействует с несколькими серверными системами, эти отличия представляют достаточно большое неудобство. Поэтому ниже будет приведено стандартное представление для пяти функций. Эти стандартные представления являются стандартом, но не требуются в обязательном порядке (за исключением функции Interrupt Process (IP), которая может понадобиться другим протоколам, которые используют TELNET); то есть система, которая не предоставляет функцию локальным пользователям не должна предоставлять ее и сетевым пользователям и может обрабатывать стандартное представление для функции как пустую команду (No-operation). С другой стороны, система, которая предоставляет функцию локальному пользователю, обязана предоставлять ту же самую функцию и сетевому пользователю, который передает стандартное представление для функции.

Interrupt Process (IP)

Многие системы предоставляют функцию которая приостанавливает, прерывает, аварийно прекращает или обрывает деятельность пользовательского процесса. Эта функция часто используется, когда пользователь полагает, что его процесс находится в бесконечном цикле или когда был активизирован нежелательный процесс. IP - это стандартное представление для вызова этой функции. Необходимо отметить, что IP может потребоваться другим протоколам, которые используют TELNET, и поэтому эта функция должна быть реализована, если такие протоколы поддерживаются реализацией.

Abort Output (AO)

Многие системы предоставляют функцию, которая позволяет процессу, который генерирует вывод, завершаться (или достигнуть той же самой точки останова, которой он бы достиг, если бы добрался до завершения), но без отправки вывода на пользовательский терминал. Затем, эта функция обычно очищает любой уже произведенный вывод, но еще фактически не напечатанный (или отображенный) на терминале пользователя. AO - это стандартное представление для того, чтобы вызвать эту функцию. Например, некоторая подсистема могла бы принять команду пользователя, послать длинную текстовую строку на терминал пользователя как ответ, и наконец сообщить о готовности принять следующую команду, посылая символ "prompt" (упреждая его) на пользовательский терминал. Если бы AO была получена во время передачи текстовой строки, то реализация должна былв бы подавить остаток текстовой строки, но передать символ prompt упреждающие. (Это отличается от действия, которое могло быть предпринято, при получении IP; IP мог бы вызвать подавление текстовой строки и выход из подсистемы.)

Следует отметить, что серверные системы, которые предоставляют эту функцию должны иметь в виду, что могут быть внешние к системе буфера (сетевые или на пользовательском локальном хосте) которые должны быть очищены; соответствующий способ сделать так, это передать сигнал "Synch" (описанный ниже) пользовательской системе.

Are You There (AYT)

Многие системы предоставляют функцию которая предоставляет пользователю видимое (например, напечатанное) доказательство, что система функционирует и выполняется. Эта функция может быть вызвана пользователем, когда система неожиданно "затихает" на продолжительное время, из-за непредвиденно (для пользователя) длительных вычислений, необычно тяжелой системной нагрузки, и т.д. AYT - стандартное представление, чтобы вызвать эту функцию.

Erase Character (EC)

Многие системы предоставляют функцию, которая удаляет последний символ перед не удаляемым символом или "позицией печати" из потока данных поставляемого пользователем. Эта функция обычно используется, чтобы редактировать ввод с клавиатуры, когда были сделаны ошибки при печати. EC - стандартное представление для того, чтобы вызвать эту функцию.

Примечание : "Позиция печати" может содержать несколько символов, которые являются результатом наложений, или последовательностей, таких как BS ...

Erase Line (EL)

Многие системы предоставляют функцию, которая удаляет все данные в текущей "строке" ввода. Эта функция обычно используется, чтобы редактировать ввод с клавиатуры. EL стандартное представление для того, чтобы вызвать эту функцию.

Сигнал "Synch"

Многие системы с разделением времени (многозадачные системы) предоставляют механизмы, которые позволяют пользователю терминала восстанавливать управление над "бесконечным" процессом; функции IP и AO, описанные выше, являются примерами этих механизмов. Такие системы, когда они используются локально, имеют доступ ко всем сигналам которые вводит пользователь, являются ли они обычными символами или специальными сигналами, такими как поддерживаемая телетайпом кнопка "BREAK" или IBM 2741 кнопка "ATTN". Это не всегда так, когда терминалы подключены к системе через сеть; сетевые механизмы могут заставить такой сигнал быть забуферизированным в другом месте, например на хосте пользователя.

Чтобы решить эту проблему, в TELNET был введен механизм "Synch". Сигнал Synch включается в TCP Urgent notification (срочное уведомление) вместе с TELNET командой DATA MARK. Срочное уведомление, которое не подвергается дополнительному управлению сетевыми механизмами, управляющие TELNET соединением, используется, чтобы вызвать специальную обработку потока данных процессом, который получает эти данные. В этом режиме поток данных будет немедленно просканирован на предмет "интересных" сигналов как описано ниже, отказываясь от пришедших данных. TELNET команда DATA MARK (DM) является меткой синхронизации в потоке данных, которая указывает, что некоторый специальный сигнал уже попался и получатель может возвратиться к нормальной обработке потока данных.

Synch отправляется через TCP отправкой операции с флагом Urgent и DM как последним октетом данных.

Когда несколько Synch отправляются как непрерывная последовательность, срочные уведомления могут быть объединены. Невозможно посчитать количество срочных уведомлений, так как количество полученных будет меньше или равно количеству отправленных. В обычном режиме, DM не имеет действия; в срочном режиме, он сообщает конец срочной (urgent) обработки.

Если TCP указывает на конец срочных (urgent) данных раньше, чем будет найден DM, TELNET должен продолжить специальную обработку потока данных, пока не встретиться DM.

Если TCP указывает на то, что срочные (urgent) данные еще есть, после того как найдет DM, то такое может случиться из-за следующего Synch. TELNET должен продолжить специальную обработку данных, пока другой DM не будет найден.

"Интересные" сигналы определены, чтобы быть: стандартными TELNET представлениями IP, AO и AYT (но не EC или EL); локальными аналогами этих стандартных представлений; всеми другими TELNET командами; другими определенными по месту сигналами которые могут задействоваться без задержки сканирования потока данных.

Так как один из эффектов механизма SYNCH - это отказ от всех символов (исключая TELNET команды) между отправителем Synch и получателем, то этот механизм определен как стандартный путь очистки данных. Например, если пользователь в терминале передает AO, сервер, который получает AO (если он вообще обеспечивает эту функцию) должен вернуть пользователю Synch.

В итоге, так же как TCP Urgent notification требуется уровень TELNET как сигнал out-of-band, так и другим протоколам использующим TELNET, могут понадобиться TELNET команды, которые могут рассматриваться как out-of-band сигналы на различном уровне.

В соответствии с соглашением последовательность должна использоваться как такой сигнал. Например, предположим, что некоторый другой протокол, который использует TELNET, определяет строковую строку STOP аналогично TELNET команде AO. Предположим, что пользователь этого протокола желает, чтобы сервер обработал строку STOP, но соединение блокировано, потому что сервер обрабатывает другие команды. Пользователь должен проинструктировать свою систему:

1. Отправить символ TELNET IP;
2. Отправить последовательность TELNET SYNCH, которая состоит из:
   Отправки Data Mark (DM) как единственного символа который посылается в срочном режиме TCP.
3. Отправка символьной строки STOP; и
4. Отправка аналога TELNET DM для другого протокола, если требуется.

Пользователь (или процесс действующий от его имени) должен передать последовательность TELNET SYNCH на шаге 2, чтобы гарантировать, что TELNET IP пройдет на серверном интерпретаторе TELNET.

Срочное уведомление должно разбудить процесс TELNET; IP должен разбудить следующий высокоуровневый процесс.

Принтер и клавиатура ВСТ

Принтер ВСТ имеет неопределенную ширину каретки и длину страницы и может произвести представление всех 95 USASCII график символов (коды с 32 по 126). Только следующие из 33 управляющих кодов USASCII (от 0 до 31, а так же 127), и 128 открытых кодов (128-255) имею смысл для принтера ВСТ:

Кроме того, следующие коды должны быть определены, но не требуют эффекта от принтера ВСТ. Ни на какое из концов TELNET соединения не может предполагать, что другая сторона будет что-то предпринимать при получении или передачи следующего:

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

Последовательность "CR LF", как определено, заставит ВСТ перейти на крайнюю левую позицию следующей строки печати (так же как, например, последовательность "LF CR"). Однако, есть много систем и терминалов которые не обрабатывают CR и LF независимо, и нужно потратить некоторые усилия, чтобы смоделировать этот эффект. (Например, у некоторых терминалов нет независимого CR от LF, но на таких терминалах можно реализовать CR через backspacing.) Поэтому, последовательность "CR LF" должна обрабатываться как единый символ "новая строка" и использоваться всякий раз, когда требуется их объединенное действие; последовательность "CR NUL" должна использоваться, где требуется требуется только возврат каретки; и использования символа CR следует избегать в других контекстах. Это правило дает гарантию системам, которые должны решить, выполнять ли функцию "новая строка" или выполнять множественный backspace когда TELNET поток содержит символ CR, принять рациональное решение.

Примечание: Последовательности "CR LF" или "CR NUL" должны использоваться в обоих направлениях (в режиме ASCII по умолчанию), для сохранения симметрии ВСТ. И даже в том случае если известно (например, с удаленным эхом или эффектом подавления опции Go Ahead), что символы не передаются на реальный принтер, для согласованности, протокол требует, чтобы NUL был вставлен после CR, не сопровождаемого переводом строки в потоке данных. Обратная сторона того, что NUL будет получен в потоке данных после CR (если отсутствуют согласованные опции, которые определяют иное поведение), это то, что NUL должен быть удален до применения ВСТ к локальному набору символов.

Клавиатура ВСТ должна имеет клавиши, или комбинации клавиш, или последовательности клавиш для воспроизведения всех 128 кодов USASCII. Отметим, что хотя некоторые из них не будут иметь никакого эффекта для принтера ВСТ, клавиатура ВСТ способна их генерировать.

В доплнение к этим кодам, клавиатура ВСТ должна быть способна к генерации следующих дополнительных кодов, исключая, как было описано, определенные, но не требуемые значения. Фактическое определение кодов для этих "символов" находится в разделе "Команды TELNET", потому, что они рассматриваются как данность и являются в некотором сиысле универсальными и должны быть доступны даже когда поток данных интерпретируется в другой кодировке.

Смысл этих "дополнительных" клавиш, а так же исполнительных элеменов принтера в том, что они должны представлять естественное расширение отображения, которое обязательно должно присутствовать в "ВСТ" и "локальной системе". Так же как байт данных ВСТ 68 (104 в восьмеричной системе) должен быть отображен в локальный код для "заглавной D", так же и символ EC должен быть отображен в то, что локально отвечает за функцию "удаление символа". Далее, так же как отображение для 124 (174 в восьмеричной системе) в некоторых системах интерпретируется несколько произвольно как символ "вертикальной полосы", так и символ EL может иметь несколько произвольную трактовку отображения (или не иметь отображения вообще) если не имеется никакой локальной функции "Стирания строки". Подобное истинно и для других исполнительных элементов формата: если терминал имеет "вертикальную табуляцию", то отображение для VT очевидно, а если терминал не имеет вертикальной табуляции, то еффект VT непредсказуем.

Структура TELNET команд

Все команды TELNET состоят по крайне мере из двухбайтовой последовательности: эскейп символа "Interpret as Command" (IAC) и кода команды. Команды, отвечающие за договоренности по опции, являются трехбайтовыми последовательностями, где третий байт является кодом опции. Такой формат был выбран для более полного использования "пространства данных" - при общении с базовым ВСТ, и соответственно колизии байт данных с получаемыми командами сведены к минимуму. С текущей структурой только IAC требует удвоения, чтобы он воспринимался как данные, а другие 255 кодов могут быть отправлены как есть.

Установление соединения

TELNET TCP соединение устанавливается между пользовательским портом U и серверным портом L. Сервер слушает свой порт L для того, чтобы установить такие соединения. Так как соединение TCP - это полный дуплекс и идентифицируется парой портов, сервер может участвовать одновременно во многих соединениях вовлекающих его порт L и различные пользовательские порты U.

Назначение порта

Если протокол используется для удаленного доступа пользователя к сервисам хоста (т.е. удаленный терминальный доступ) то он назначается на порт 23 (27 в восьмеричной системе). Т.е. L=23.

Применения

Исторически Telnet служил для удалённого доступа к интерфейсу командной строки операционных систем . Впоследствии его стали использовать для прочих текстовых интерфейсов, вплоть до игр MUD и анимированного ASCII-art . Теоретически, даже обе стороны протокола могут являться программами, а не человеком.

Иногда клиенты telnet используются для доступа к другим протоколам на основе транспорта TCP, см. .

Протокол telnet используется в управляющем соединении

Безопасность

В протоколе не предусмотрено использование ни шифрования , ни проверки подлинности данных. Поэтому он уязвим для любого вида атак , к которым уязвим его транспорт, т.е. протокол TCP. Для функциональности удалённого доступа к системе в настоящее время применяется сетевой протокол виртуальных частных сетей). По причине ненадёжности от Telnet как средства управления операционными системами давно отказались.

Как вы уже могли убедиться, если читали мой пост о настройке Telnet в Windows, работать с этой службой достаточно легко. Можно запустить его без аргументов, указав в командной строке лишь адрес хост-системы. При определенных обстоятельствах еще нужно указать конкретный порт. Первое сообщение, которое видит пользователь, после выполнения команды “ telnet “, посылается самой программой, а после установления связи между клиентом и сервером выводятся сообщения, исходящие от управляемой системы. В связи с этим с удаленной операционной системой можно работать через Telnet таким же образом, как это происходит в случаях с другими специализированными программами дистанционного доступа к ОС. Теперь давайте присмотримся к данной службе поближе и разберем наиболее часто используемые команды Telnet .

Командная строка Telnet на клиенте с Windows может принимать следующие команды:

open узел порт – применяется для установки соединения с заданным узлом;

close – закрывает существующее соединение;

quit – выход из текущего сеанса Telnet;

display – позволяет просмотреть текущие параметры Telnet-клиента;

set – с ее помощью возможно задать Telnet-параметры текущей сессии , а конкретно:

• set ntlm включит NTLM (использование интегрированной в Telnet проверки подлинности NTLM во время подключения пользователя с удаленного компьютера позволяет обойтись без ввода логина и пароля при входе);
• set localecho включит режим локального вывода команд;
• set term vt100/vt52/vtnt/ansi задаст указанный тип терминала (например, VT100 применяют для выполнения обычных программ командной строки, а VTNT – для выполнения расширенных программ, типа “edit”);
• set escape символ задаст последовательность клавиш, переключающих режим сеанса в командный режим (к примеру, set escape , потом нажатие клавиш “Ctrl+P” и “Enter” установит Ctrl+P в качестве переключателя);
• set logfile имя_файла укажет на файл журнала текущей активности Telnet (этот файл должен находиться в файловой системе управляющего компьютера);
• set logging включит ведение журнала (файл журнала должен быть предварительно указан вышеприведенной командой, иначе возникнет сообщение с ошибкой);

unset – выполняет отключение различных параметров сессии Telnet (обратные операции по отношению к set), а именно:

• unset ntlm отключит встроенную проверку подлинности;
• unset localecho деактивирует режим локального вывода команд;

status – используется с целью проверки наличия подключения к Telnet-клиенту;

enter – применяется для перехода в существующий подключенный сеанс Telnet;

Или help – отображение справочной информации.

Закончив с делами на удаленной машине, вам нужно будет закрыть соединение с ней. При этом работа самого Telnet завершается не всегда. Чтобы выйти в командную строку Telnet, воспользуйтесь горячими клавишами “Ctrl+]” .

Данный сервис обеспечивает взаимодействие с удаленным компьютером. Он позволяет превратить компьютер пользователя в удаленный терминал другого компьютера. Поэтому данный сервис еще называют эмуляцией удаленного терминала . Терминал от обычного компьютера отличается тем, что не выполняет собственные вычисления. Все, что вводится на клавиатуре рабочей станции, передается удаленному компьютеру, а получаемые результаты передаются обратно и выводятся на монитор рабочей станции. В качестве удаленных компьютеров, в основном, используются машины, работающие под управлением операционной системы UNIX [Юникс]. Поэтому для работы в режиме удаленного терминала требуется знание основных команд данной операционной системы. С развитием графических операционных систем, таких, как Windows, командный режим работы стал менее популярен, и сервис Telnet в последнее время большинство пользователей не применяют. Многие информационные системы, ранее доступные исключительно с помощью Telnet , сегодня доступны из Всемирной паутины, о которой речь пойдет ниже.

Установив связь с помощью Telnet , пользователь получает возможность работать с удаленным компьютером, как со "своим", т.е. теоретически получить в свое распоряжение все ресурсы, если к ним разрешен доступ. Реально Telnet предоставляет открытый доступ, но организация взаимодействия полностью определяется удаленным компьютером. Два вида услуг Internet требуют подключения к серверам через Telnet : библиотечные каталоги и электронные доски объявлений (BBS).

Работа с удаленной системой может вестись в "прозрачном" режиме, когда программы на сервере и у клиента только обеспечивают протокол соединения, и в командном, когда клиент получает в свое распоряжение набор команд сервера. Следует заметить, что из соображений безопасности намечается тенденция сокращения числа узлов Internet, позволяющих использовать Telnet для подключения к ним.

Отложенное общение в Интернете Электронная почта - e-mail

Это наиболее старая и одна из самых массовых служб Сети. Ее назначение - поддержка обмена электронными письмами между пользователями. По своей сущности электронная почта - это система обмена электронными сообщениями в компьютерных сетях (в режиме отложенного общения -offline). Схема работы электронной почты отражена на Рис. 2. Почтовый сервер - это своеобразное почтовое отделение, куда поступает входящая и исходящая корреспонденция зарегистрированных на нем пользователей. Эта корреспонденция помещается в «почтовые ящики» пользователей - специально отведенные разделы на жестком диске. Каждый пользователь получает персональный почтовый адрес, по которому к нему будут поступать письма. Следует отметить, что адреса электронной почты несколько отличаются от других адресов Интернета, но очень похожи. Они состоят из двух частей, разделенных символом @. Справа от символа располагается Интернет-адрес компьютера, на котором располагается почтовое отделение абонента. Этот адрес формируется так же, как и любое другое доменное имя в Интернете. Слева от символа @ расположено имя абонента. Примером почтового адреса может служить: [email protected].

Рис. 2. Схема функционирования электронной почты

Для того, чтобы эта служба стала доступной пользователю, необходимо выполнить ряд процедур. Сначала пользователь должен зарегистрироваться на почтовом сервере. При этом фиксируется адрес клиента электронной почты и пароль – набор символов, позволяющий идентифицировать пользователя. Наличие пароля обеспечивает конфиденциальность данной услуги. Зарегистрированный пользователь имеет возможность написать текст письма, указав адрес получателя. Для этого в состав клиент-программы электронной почты включен редактор подготовки писем. Подготовленные письма помещаются в папку «Исходящие». Сервер, принимает все письма из папки «Исходящие» и, кроме того, передает поступившие письма, которые помещаются в папку «Входящие». Соединение пользователя с почтовым сервером необходимо только для передачи письма и доставки на компьютер пользователя писем из папки входящие. Почтовый сервер работает постоянно. Он периодически просматривает «почтовые ящики» и организует передачу по сети исходящих писем. Входящую корреспонденцию почтовый сервер раскладывает по «ящикам».

Клиент-программа электронной почты кроме функции приема-передачи писем во время сеанса связи, может выполнять еще множество сервисных функций:

· подготовка и редактирование писем,

· организация адресной книги,

· просмотр почтового архива,

· сортировка и удаление писем из почтового архива и пр.

Популярным клиентом E-mail является программа Outlook Express, входящая в стандартную поставку операционной системы MS Windows.

Cервер и клиент электронной почты работают по разным протоколам. Сервер программа POP3 (Post Office Protocol - протокол почтового отделения) кроме всего прочего выполняет функцию защиты информации. Во время сеанса связи она устанавливает личность пользователя, обеспечивает связь с его персональным ящиком. При работе клиент-программы никакого установления личности не требуется. Ее задача - передать на сервер исходящие письма и принять поступившие. Здесь используется более простой протокол SMTP (Simple Mail Transfer Protocol - простейший протокол передачи почты).