# <center>Протоколы верхнего уровня</center>

----

----

<div class="TOC" >
О чем сегодня будем говорить:
<p>

</p>
</div>

<style>
.TOC {
font-size: 26px;
font-weight: 550;
color: #270469;
text-align: left;
</style>

[TOC]

----

## **Модель TCP/IP**

## **Протоколы верхнего уровня**
Вообще с точки зрения сетевого инженера, нам все равно, что происходит внутри прикладного уровня. Этим, как правило, занимаются программисты и веб-разработчики.

**Так зачем мы их разбираем?**
Нам важно знать, как формируются данные и инкапсулируются в нижестоящие уровни.
Важно затронуть все возможные аспекты безопасности, т.к в протоколах верхних уровней достаточно интересующих нас уязвимостей.

Итак, протоколы прикладного уровня обеспечивают взаимодействие между человеком и сетью.
Этих протоколов огромное количество, и выполняют они совершенно различные задачи.

Мы разберем примеры часто используемых протоколов в сети и посмотрем, как они работают на практике: **HTTP**, **DNS**, **DHCP**, **SMTP**, **POP3**, **Telnet**, **SSH**, **FTP**, **TFTP**.

----

### **Протокол HTTP**
:::info
**HTTP протокол передачи данных**, используемый обычно для получения информации с веб-сайтов.
:::
Использует **модель «клиент-сервер»**, то есть существуют клиенты, которые формируют и отправляют запрос.
И серверы, которые слушают запросы и, соответственно, на них отвечают.

**В качестве клиентов выступают известные многим веб-браузеры:**
:::info
* [Internet Explorer](https://www.microsoft.com/ru-ru/download/internet-explorer.aspx)
* [Mozilla Firefox](https://www.mozilla.org/ru/firefox/new/)
* [Opera](https://www.opera.com/ru?utm_campaign=%2300%20-%20WW%20-%20Search%20-%20EN%20-%20Branded&gclid=Cj0KCQjw-4SLBhCVARIsACrhWLW1Skrstpj0qLoLLlaXFMiYPQA96O5lFI387Yd5i13xCoQKhs3d35kaApq2EALw_wcB)
* [Yandex](https://browser.yandex.ru/)
* [Google Chrome](https://www.google.com/intl/ru_ru/chrome/) и т.д.
:::

**А в качестве серверного ПО используют:**
:::info
* [Apache](https://httpd.apache.org/)
* [IIS](https://www.iis.net/)
* [lighttpd](https://www.lighttpd.net/)
* [nginx](https://nginx.org/ru/) и т.д.
:::

Для того, чтобы разобраться глубже в протоколе **HTTP**, взглянем на **HTTP** запрос **от клиента к серверу**. (см. Детали)

:::spoiler
Сразу предупреждаю, в новых версиях Cisco Packet Tracer HTTP запрос выглядет иначе, кодов ответа там нет, именно поэтому ниже я сперва делал в новой версии, потом обнаружил этот момент и перешел в старую версию 6.2
:::


Нас интересуют только **самая верхняя** и **самая нижняя** строчки.

В первой строчке используется такое понятие, как **GET** - это, по сути, ключ запроса.
Так как после **GET** стоит символ "/", то это означает, что запрашивается главная или корневая страница по **URL** (англ. Uniform Resource Locator) пути.

:::info
**[URL](https://ru.wikipedia.org/wiki/URL)** — это некий идентификатор какого-либо ресурса в сети.
:::

Так же в этой строчке присутствует такая запись, как **HTTP/1.1** - это версия протокола.
Довольно популярная версия, выпустили ее в 1999 году, и до сих пор она служит верой и правдой.
Хоть недавно был анонс версии 2.0, версия 1.1 занимает пока лидирующее положение.

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

----

#### **Демонстрация в CPT**
**Давайте посмотрим, как это работает на практике.**

Я буду использовать свою "любимую" программу Cisco Packet Tracer (в дальнейшем CPT).
Она проста в освоении и для демонстрации описанного идеально подходит.

Открываем программу и добавим туда компьютер с сервером (находятся они на вкладке **«End Devices»**), как на картинке ниже:


Соединяем компьютер с сервером **перекрестным кабелем** (англ. crossover cable).

В **CPT** он находится на вкладке «Connections», обозначается пунктиром и называется **«Copper Cross-Over»**.

Далее настроим нашего клиента и сервер!

1) Дважды кликаем по нашему **веб-клиенту** и **веб-серверу** в **CPT**, и перед нами открывается окно:
2) Отрываем вкладки **«Desktop»** на рабочем компьютере и сервере
3) Далее переходим в окно **«IP Configuration»**. Откроются окна - окна конфигурации узлов в сети.
4) Укажем **IP-адреса** в строке **"IPv4 Address"**. Как помним, IP-адреса нужны для идентификации узлов в сети. Сейчас главное понимать, для чего нужен IP-адрес, более подробно разберем это чуть позже.
Была специально выбрана сеть, начинающуюся с «192.168», так как она встречается чаще всего в домашних сетях.
6) В поля **"Subnet Mask"**, вводится маска подсети. Она нужна для того, чтобы узлу было понятно, в одной подсети он находится с другим узлом или нет. Но об этом позже.
Остальные значения оставим пустыми.

**Выглядит это как-то так:**

Теперь требуется включить сервис **192.168.1.1** на сервере.

1) Возвращаемся в окно **«Веб-сервер»**.
1) Переходим на вкладку **«Services»**.
2) Выбираем слева сервис **HTTP**.
3) Открывается окно настройки сервиса и файловый менеджер (если у кого есть навыки по работе c HTML, то можете здесь создать страницу, но у нас уже есть готовый шаблон, и мы им воспользуемся).
5) Не забываем включить службу **HTTP** и **HTTPS**.

**Настройка выглядит примерно так:**

Раз уже зашла речь о протоколе **HTTPS** (HyperText Transfer Protocol Secure), то скажу про него пару слов.

Это, по сути, **расширение протокола HTTP**, которое **поддерживает криптографические протоколы** и передает информацию **не в открытом виде**, а в **зашифрованном**.

*В CPT очень поверхностно показана его работа, но для понимания вполне достаточно.*

**Вспоминаем и запоминаем: HTTP использует 80 порт, а HTTPS 443 порт.
Вообще номеров портов очень много, и все запомнить тяжело, но часто встречающиеся лучше запомнить.**

**Теперь самое интересное.**
Нам надо перевести **CPT** из режима **«Realtime»** в режим **«Simulation»**.

Отличие их в том, что в режиме **«Realtime»** сеть ведет себя так, как она повела бы себя в реальной жизни и в реальном времени.
Режим **«Simulation»** позволяет нам наблюдать за поведением сети в разные временные интервалы, а также проследить за каждым пакетом, раскрыть его и посмотреть, что он в себе несет.

Переключаем среду, делается это тут (выделенно красным):

Здесь открывается **«Simulation Panel»**, в которой несколько опций:
- Есть фильтр, в котором можно указать протоколы, которые вы хотите отслеживать,
- Скорость перемещения пакета и навигационная панель, где можно наблюдать за сетью вручную, нажатием «Capture/Forward» или автоматически, при помощи кнопки «Auto Capture/Play».

Оставляем все, как есть, и открываем компьютер.
Переходим на вкладку **«Desktop»** и открываем **«WEB Browser»**.

Перед нами открывается окно веб-браузера. В строке **URL** пишем адрес нашего веб-сервера, нажимаем кнопку **«Go»**.

Видим следующее:

Появились первые посылаемые данные на схеме и в окне **«Simulation Panel»**.
Это сегменты **TCP**, которые создадут сессию между компьютером и сервером.

Сейчас нам это не интересно, и мы об этом поговорим чуть позже.

Поэтому я пропущу их до момента, когда будут созданы **HTTP**.

Делать я это буду при помощи кнопки «Capture/Forward (цифра 1 на скрине, цифра же 2 - **«Auto Capture/Play»**).

**Выглядит это так:**

И вот после установления соединения, компьютер формирует первые HTTP данные. В дальнейшем я буду называть их **PDU**, чтобы вы привыкали к данным терминам.

1) Смотрим на схему и видим, что появилось 2 конверта. Это и есть наши данные. Нас интересует фиолетовый конверт. Это и есть созданный PDU.
2) Теперь смотрим на «Simulation Panel» и видим, что в таблице появилась запись с типом HTTP. Эти данные нас интересуют. Также рядом с записью показан цвет, которым окрашены эти данные на схеме.
3) Кликаем по HTTP (фиолетовый конверт), и перед нами открывается окно данных. Тут кратко показаны все нужные сведения по каждому уровню модели OSI. Можно кликнуть по любому уровню и получить информацию о том, что происходит на нем.

Если вам интересно полностью раскрыть данные и рассмотреть подробно, из каких полей они состоят и что в них происходит, есть вкладка **«Outbound PDU Details»**.

**Давайте перейдем на нее и посмотрим, как выглядят HTTP данные:**

На этой вкладке будут выводиться данные на всех уровнях.

Нам пока надо посмотреть на **HTTP**.

Они находятся в самом низу, поэтому тянем бегунок вниз. Выглядят они так же, как я и описывал их раньше (ниже приведен пример новой версии CPT, как видите тут отсутствует код ответа).

Теперь нам интересен этап, когда веб-сервер получит запрос и начнет предпринимать какие-то действия.

Давайте нажмем на **«Capture/Forward»** и посмотрим, чем веб-сервер ответит.
И вот, на рисунке ниже видим, что он отправил компьютеру какие-то данные.
Давайте посмотрим, как они выглядят.


1) Находим **PDU**, адресованные от веб-сервера к клиенту. Как видим, он сразу показывает нам на схеме момент времени, в который я кликнул. Выбираем нужный конверт.

2) Здесь уже видим другую картину. Сверху указывается версия **HTTP**, **код «200 OK»**, означающий, что отправляется запрашиваемая страница, а не сообщение об ошибке.
Далее указывается длина контента, тип файла, а также с какого сервера отправляется. И в самой нижней строке указывается, что передаются какие-то данные. После того, как данные дойдут до компьютера, можно наблюдать, что веб-браузер компьютера открыл страницу.

**Вот так работает протокол HTTP.**

----

#### **Совсем немного про HTTPS**
Давайте рассмотрим его расширенную версию **HTTPS**.
Как мы помним, эта версия поддерживает шифрование и не передает данные в открытом вид.
Жмякай ниже для более подробной информации! (*не помню с какого источника у меня эта информация, но написанно очень доходчиво и понятно*)
:::spoiler
Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL.

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

Перенесем механизм использования **HTTPS** на сайте в реальную жизнь.
Представьте, что хотите передать другу важное письмо.
Хоть вы и упаковали его в конверт, почтальон все равно может получить информацию, а потом заменить вскрытую упаковку на новую (передача данных по протоколу HTTP).
Но вы кладете письмо в ящик, на который вешаете замок. Друг получает посылку, но у него нет ключа — поэтому он вешает на ящик второй замок и отправляет его обратно.

Ящик «приходит» к вам, вы снимаете свой замок и отправляете посылку в путь третий раз. Теперь друг сможет открыть ее своим ключом, получив доступ к необходимой информации (передача данных по протоколу HTTPS)

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

**Когда необходим протокол HTTPS?**
Современные браузеры отмечают все ресурсы, использующие HTTP-протокол, как небезопасные. В Google считают, что перехват любых данных опасен, поэтому будущее интернета за безопасным подключением. HTTPS нужен, если вы:

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

**Как перевести сайт на HTTPS?**

Чтобы сайт начал работу по протоколу HTTPS, нужен SSL(TLS)-сертификат.

Шифрование данных, которые передаются от клиента к серверу, происходит, в свою очередь, в соответствии со своим, криптографическим протоколом. Сначала для этого использовался протокол под названием SSL (англ. Secure Sockets). У него было несколько версий, но все они в какой-то момент подвергались критике из-за наличия проблем с безопасностью. В итоге была выпущена та версия, которая используется сейчас — ее переименовали в TLS (англ. Transport Layer Security). Однако название SSL прижилось лучше, и новую версию протокола до сих пор часто называют так.

**Какие бывают SSL(TLS)-сертификаты?**
По типу проверки сертификаты бывают трех видов:

* **Domain Validation (DV)** – подтверждение домена. Самый простой сертификат, выпускается моментально и доступен всем.
* **Organization Validation (OV)** – подтверждение организации и домена. Содержит название организации – соответственно, для его получения необходимо подтверждение центром сертификации. Доступно только юридическим лицам.
* **Extendet Validation (EV)** – расширенное подтверждение организации и домена. Самый безопасный и сложный в получении сертификат. Выдавая его, центр сертификации максимально тщательно проверяет деятельность организации. Доступно только юридическим лицам.

Для корректной работы SSL-сертификат должен быть выпущен специальной организацией – Удостоверяющим центром. Мы работаем с удостоверяющими центрами: **Thawte**, **GeoTrust**, **DigiCert**, **GlobalSign** и **Comodo**.
:::
В самом начале, мы включили сервис **HTTP** и **HTTPS**. Поэтому все готово, и можно запрашивать страницу.
Отличие запроса в том, что перед адресом страницы вместо **HTTP**, пишем **HTTPS**.

Видим надпись, что данные защищены, и мы их прочитать не можем.

В принципе это все отличия, которые может показать **CPT**, но для базового понимания этого достаточно.

От себя добавлю, что когда вы переходите на сайт, работающем по **HTTPS**, в браузере он обозначается в виде замка.

Например:

Мы поговорили про **HTTP**, совсем немного про **HTTPS**, и теперь время разобрать протокол **DNS**.

Данный протокол тесно связан с предыдущим протоколом, и скоро вы поймете почему.

Вот вам **[проект](https://vk.com/doc157722137_613699910?hash=1c9db76107d64c49d9&dl=f7d701bd472822f77d)** если нужен!

----

### **Протокол DNS (Domain Name System)**
**DNS** - cистема доменных имен.
Если говорить в целом, то она хранит информацию о доменах.

Например, какому **IP адресу** соответствует **определенное имя**.

Приведу пример: когда вы открываете свой любимый сайт, то обращаетесь к нему по имени.
Но в поля **Source Address** и **Destination Address**, которые работают на **сетевом уровне** (это разберем дальше, но я немного забегу вперед), нельзя вставить имя, там обязательно должен присутствовать именно **IP адрес**.

Вот **DNS** как раз этим и занимается, она сообщает, какой **IP адрес** у запрошенного имени.

Вы, к примеру, обращаетесь на **google.ru**.

Ваш компьютер понятия не имеет, кто и что это, что он делает?
Он спрашивает у DNS-сервера: **Кто такой google.ru?**
И сервер отвечает, что **google.ru — это 74.125.232.239** (это один из его адресов).

И уже после этого, компьютер отправляет запрос на **74.125.232.239**.
Для пользователя все останется по-прежнему, и в адресной строке он также будет видеть **google.ru**.

На картиночке это можно изобразить так:

Думаю, что выше описанное понятно, и двигаемся дальше.

Служба эта иерархичная.
И часто **DNS-сервер** (на котором запущена эта служба) работает в связке с другими **DNS-серверами**.

**Давайте разберем, что это значит.**
Иерархичность его заключается в том, что он работает с доменами уровня.
**Работает он от младшего уровня к старшему, слева направо.**

Например имя: ru.wikipedia.org.
Cамым старшим будет доменное имя **«org»**, а младшим — **«ru»**.

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

Предположим, мы набрали в браузере адрес **ru.wikipedia.org**.
Браузер спрашивает у сервера DNS: **«какой IP-адрес у ru.wikipedia.org»**?

Однако **сервер DNS** может ничего не знать не только о запрошенном имени, но даже обо всём домене **wikipedia.org**.
В этом случае сервер обращается к корневому серверу — например, **198.41.0.4**.
Этот сервер сообщает — **«У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.»**

Тогда **сервер DNS** направляет свой запрос к **204.74.112.1**, но тот отвечает **«У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.»**

Наконец, тот же запрос отправляется к **третьему DNS-серверу** и получает ответ — **IP-адрес**, который и передаётся **клиенту — браузеру**.

----

#### **Демонстрация в CPT**
Перейдет к демонстрации в CPT, этот и следующие примеры будут основываться на предыдущих -> адресация будет такой же.

**Собираем вот такую схему:**

Здесь добавлен еще один сервер, который будет выполнять роль **DNS-сервера** и **коммутатор (он же switch)**.

:::info
Когда в сети появляются **3 и более устройств**, то для их соединения используют **коммутатор**.
:::

**Займемся настройкой DNS-сервера**.

Зайдем в **«IP Configuration»** и пропишем **IP адрес** с маской.

Теперь:
1) Зайдем в **"Services"(цифра 1)**
2) Далее в **DNS (цифра 2)** и настроим DNS службу.
3) В окне **«Name»** запишем имя, которое хотим привязать к **IP адресу**.
4) В окне **«Address»**, соответственно, **IP-адрес**, который будет работать в связке с выше написанным именем. (здесь укажем тот же адрес, что на **HTTP** — **192.168.1.2**).
5) Не забываем включить саму службу!
6) Нажимаем кнопку **«Add»**, чтобы добавить эту запись.

Собственно запись добавлена:


Теперь надо в настройках сервера и компьютера указать **адрес DNS-сервера**.

Настройка **DNS-сервера и узлов закончена**, и самое время проверить, как это дело работает.

Переключаем среду в режим симуляции (как это делали ранее) и попробуем с компьютера зайти на сайт по имени «cisadmin.ru».

И видим, что создаются **2 конверта**.
* Первый — это **DNS**
* Второй — **ARP**

:::info
О **ARP** мы толком не говорили, так как это тема будет в будущем.
Но раз он показал себя, то вкратце расскажу, для чего он.
:::

:::spoiler
Как мы помним, для обмена между узлами недостаточно **IP адреса**, так как еще используются **MAC-адреса**, работающие на **канальном уровне**.
Мы указали компьютеру **IP адрес DNS-сервера**.

Но он не знает, какой у узла с IP-адресом 192.168.1.3 **MAC-адрес**, что в таком случае делать?

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

И тот, у кого этот адрес, отправит обратное сообщение и сообщит свой **MAC-адрес**.
**Все остальные участники отбросят этот кадр.**
:::

**Что происходит дальше:**
1. Вот кадр пришел на коммутатор, и теперь его задача разослать этот кадр на все порты, кроме того, откуда он пришел.
2. Кадры были разосланы и наблюдаем следующее, кадр, который пришел на веб-сервер был отброшен, о чем говорит перечеркнутый конверт -> кадр отбрасывается. А DNS-сервер, наоборот, узнал свой адрес и должен сформировать ответ.
3. И как видим, **был создан ARP-ответ**.
Давайте немного разберем его.
1) **MAC-адреса**
* В Source MAC он записывает свой MAC-адрес.
* В Destination MAC (Target MAC) адрес компьютера.
2) **IP-адреса**
* В Source IP свой IP адрес.
* В Target IP адрес ПК.

4. Далее вижу, что компьютер успешно получил ARP от сервера, теперь он знает MAC-адрес DNS-сервера, а значит, и как с ним связаться. И сразу решает узнать у него, кто такой «cisadmin.ru».
6. Мы можем открыть эти данные и посмотреть, что он там решил отправить.
Открываем «Outbound PDU Details» и спускаемся в самый низ.
Видим, что в верхнем поле «NAME» он записал запрашиваемое имя.
Идем дальше!
5. DNS-сервер получает DNS-запрос.
Он лезет в свою таблицу и видит, что такая запись у него присутствует, и формирует ответ.
7. Открываем и видим, что изменилось поле **LENGTH** и равняется **4**.
То есть **4 байта**.
Столько занимает **IP адрес**, и, соответственно, записывает сам **IP-адрес** — **192.168.1.2** - это и есть адрес веб-сервера.
8. Видим, что компьютер получил сообщение от DNS-сервера, о чем свидетельствует галочка на коричневом конверте, теперь он знает IP адрес веб-сервера.
Сразу же он пытается установить TCP сессию, но возникает проблема.
Он не знает MAC-адрес веб-сервера и запускает аналогичный ARP запрос, чтобы узнать.

9. И тут аналогично предыдущему.
DNS-сервер понял, что сообщение не для него, и отбрасывает. А веб-сервер узнает свой IP адрес и формирует ARP ответ.
10. До компьютера дошел ARP ответ.
Теперь он знает MAC-адрес веб-сервера и пытается установить TCP сессию.
Он отправляет TCP сегмент на 80-й порт.
:::info
Раз уж протокол TCP снова дал о себе знать, и в следующих протоколах он тоже будет фигурировать, то вкратце объясню зачем он нужен.
:::
::: spoiler
Как вы помните из первой части лекций, я говорил, что он устанавливает соединение. Так вот теперь каждый блок данных, который будет отправлен от сервера компьютеру, будет промаркирован. Это нужно для того, чтобы клиент понимал, все ли данные он получил или какие-то потерялись. И, если какие-то данные потерялись, он сможет запросить их повторно. Потеря блока данных сайта может привести к тому, что сайт перекосит, и он отобразится криво. Но сейчас главное понимать, что TCP располагается на транспортном уровне и работает с портами. Я специально открыл окно, где это написано, чтобы вы постепенно привыкали к этим полям.

:::
11. Посмотрим, чем ответит компьютеру веб-сервер.
Веб-сервер отправляет компьютеру ответное сообщение, и устанавливается сессия.
И, когда все готово, компьютер формирует HTTP и отсылает его веб-серверу.
Давайте посмотрим, что изменилось, а изменилась у нас самая последняя строчка.
Если раньше там был записан IP адрес веб-сервера, то теперь там красуется доменное имя «cisadmin.ru».
Но не забывайте, что доменное имя тут записано только в данных прикладного уровня. IP-адрес никуда не делся, он располагается на сетевом уровне, поэтому давайте сразу покажу IP пакет, где представлены эти адреса.
12. И как видите, IP адреса на месте.
13. Далее процесс аналогичен действиям по HTTP.
Поэтому приведу финальный этап, где по имени «cisadmin.ru» откроется страница, находящаяся на сервере с IP адресом 192.168.1.2.

Соответственно видим, что все прекрасно работает, и сайт открывается по доменному имени.

----

### **Утилита - nslookup**
И напоследок упомяну об одной очень важной утилите под названием **nslookup**.

Она позволяет обратиться к **DNS-серверу** и узнать у него информацию о имени или **IP-адресе**.

В CPT эта команда присутствует, и я предлагаю взглянуть на нее.

Кликаем по компьютеру на схеме и на вкладке **«Desktop»** выбираем **«Command Prompt»** -- это имитация командной строки.

Открывается у нас окошко, подобное **cmd** в **Windows**.

Можно ввести знак `"?"` и нажать **ENTER**, она покажет список всех доступных команд:

Из всего этого списка нам нужна команда **nslookup**.

Введем ее и нажмем **ENTER**:

Открывается сама утилита, о чем свидетельствует знак птички слева.
Показывается нам адрес **DNS-сервера** и его **имя**.

Так как имени нету, то он дублирует туда строку с **IP-адресом**.

Ну и самое время вписать туда **доменное имя** и узнать, что он выдаст в ответ.

Выдает он **имя** и **адрес**, как и предполагалось.
В принципе, когда вы обращаетесь на веб-сайт, он сам выполняет эту процедуру.

Есть еще один файл в каждой ОС, который тесно связан с **DNS**.
Название у него **«hosts»**.
Стандартное расположение его в Windows системах `«windows\system32\drivers\etc\hosts»`.
А в *nix подобных системах: `"/etc/hosts"`.

Делает он то же самое, что и **DNS-сервера**.
И контролируется этот файл администратором компьютера.

И самое важное: он имеет приоритет перед **DNS-сервером**, и, если у вас в файле написано, что сайту **habrahabr.ru** соответствует **IP адрес**, который на самом деле соответствует **google.ru**, то, соответственно, открывать он будет **google**, а не **habrahabr**.

**Этим часто пользуются злоумышленники, когда вносят исправления в этот файл.**

Приведу скрин этого файла со своего компьютера.
Вот так он выглядит. Можете открыть его у себя и поймете, что он точно такой же.

Вот такая интересная служба и протокол.
Также как и с **HTTP**, приведу ссылку на скачивание данного [**проекта**](https://vk.com/doc157722137_613699565?hash=105ea67430ec7c9f5a&dl=3b713979de54be83a6).

А мы двигаемся дальше и разбираем **протокол DHCP**.

----

### **Протокол DHCP (Dynamic Host Configuration Protocol)**
:::info
**DHCP протокол** динамической настройки узла - он позволяет узлам динамически получать IP адреса и другие параметры для корректной работы в сети (основной шлюз, маску подсети, адреса DNS-серверов).
:::
От себя скажу, что этот протокол спасает жизнь многим сисадминам по всему миру. Согласитесь, что ходить и вручную прописывать IP параметры каждому узлу, не самое приятное занятие.

При помощи **DHCP** можно обеспечить полный контроль над IP адресами:
* создавать отдельные пулы для каждой подсети
* выдавать адреса в аренду
* резервировать адреса и многое другое.

Работа его очень тяжела для нынешнего понимания.

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

Давайте посмотрим, как он работает на практике.

----

#### **Демонстрация в CPT**
Соберем такую схему:


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

Переходим в настройку DHCP - сервера, `Desktop -> IP Configuration`:

Присваиваем свободный адрес и маску. Перейдем к роли DHCP.


1) Выбираем службу DHCP, и тут уже создан стандартный пул, его удалить нельзя, только изменить.
Можете сами создать несколько пулов и вытворять с ними, что угодно, вплоть до удаления. **Но стандартный всегда останется**. Нам дополнительные пулы не нужны, поэтому переделаем под себя стандартный.
2) Здесь можно добавить адрес шлюза, адрес DNS-сервера. Мы пока не касались вопроса шлюза, поэтому пока не будем его трогать. DNS-сервер у нас есть, и его можно указать. Ну и старт адресов оставим, как есть.
3) Не забываем включить сервер!
4) Меняем стартовый IP - адрес
5) Под айпишник меняем его маску
6) Сохраняем
7) Если мы все сделали правильно, то в конце должны получить такую строчку

Переключаем среду в режим симуляции и посмотрим, как компьютер получит адрес.
Соответственно переходим в настройки конфигурации и переключаем на DHCP.

Видим, что создался DHCP-запрос.
Давайте пройдемся по каждому его уровню и поверхностно посмотрим, что внутри.


1) **Протокол канального уровня (Ethernet).**
* В **«Source MAC»** записывается адрес компьютера.
* В **«Destination MAC»** записан широковещательный адрес (то есть всем).

2) **Протокол сетевого уровня (IP).**
* В **«Source IP»** записывается адрес «0.0.0.0». Этот адрес вставляется, когда у запрашиваемого нет адреса.
* В **«Destination IP»** вставляется широковещательный адрес «255.255.255.255».

Идем дальше дальше.

**Посмотрим на поле UDP.**
Здесь используются порты **67** и **68** - это UDP порты, зарезервированные для DHCP.

**Теперь смотрим на поле DHCP.**
Здесь все по нулям, и только в поле «CLIENT HARDWARE ADDRESS» записан MAC-адрес компьютера.


Мы знаем, как работает широковещательная рассылка, и посмотрим, как будут реагировать на нее участники сети.

И видим, что все кроме **DHCP-сервера** отбросили данные.

Дальше работу протокола расскажу на словах, потому что очень много пакетов и кадров будет сформировано, перед тем как **DHCP-сервер** выдаст адрес.

Как только он получит запрос, он начинает искать свободный адрес в базе.
Как только адрес найден, начинается следующий этап — это проверка адреса.
Ведь, как мы помним, адрес можно назначить и вручную, в обход **DHCP-сервера**.

Такое часто происходит, и даже в корпоративной среде находятся умники, которые вручную вписывают адрес.
Для этого **DHCP-сервер** перед выдачей этого адреса, отправляет **ICMP** сообщение или **ping**.

Стёпа уже говорил с вами об этом, я лишь повторюсь, что утилита **ping** позволяет проверить доступность узла по **IP-адресу**.
И, если на **ping** **DHCP-серверу** кто-то ответит, то значит адрес занят и всю процедуру он будет повторять, но с другим **IP-адресом**.

**Но это тоже не самое толковое решение**.
Сами понимаете, что если компьютер со статически назначенным адресом будет выключен, то он не ответит на **ping** **DHCP-сервера**, и, соответственно, **DHCP** решит, что адрес не занят и присвоит его какому-то узлу.
Но, как только компьютер включится, появится **2 компьютера с одинаковыми IP-адресами**.

**И тут могут начаться дикие чудеса.**
Современные системы уже научились правильно реагировать на это, но все же не стоит этого допускать и важно следить за этим.
Пропущу рассмотрение передвижения всех пакетов...т.к это займет много времени, проект я прикреплю и вы сами сможете там потыкаться.
Приведу только конечный итог, который сформирует **DHCP-сервер**.

Но если кому интересно...то выглядит это примерно так:

Далее, нас интересует именно этот пакет:

Видим, что в поле **"«YOUR» CLIENT ADDRESS"** добавился адрес **192.168.1.1** - это адрес, который **DHCP-сервер** предлагает компьютеру.
В поле **«SERVER ADDRESS» DHCP-сервер** добавляет свой адрес, чтобы компьютер знал, кто предлагает ему адрес.
В поле **«CLIENT HARDWARE ADDRESS»** добавляется **MAC-адрес** компьютера (то есть того, кто запросил).
И в самом низу представлена опция **«DHCP Domain Name Server Option»** - cюда записывается адрес DNS-сервера, который мы указали в настройках **сервиса DHCP**.

Посмотрим, как компьютер получит адрес.

И наблюдаем сообщение **«DHCP Request Successful»** - это означает, что данные успешно получены, о чем свидетельствуют заполненные поля ниже.

Вот так работает протокол DHCP.
Вот [**ссылочка**](https://vk.com/doc157722137_613849534?hash=d14ed212fa05753e41&dl=4998b7119c2630db36) на проект.

Переходим дальше, и дошла очередь до протоколов **POP3** и **SMTP**.
Я специально упомянул эти протоколы вместе и сейчас объясню, почему.

----

### **Протокол POP3 (англ. Post Office Protocol Version 3)**
:::info
**POP3 - протокол почтового отделения версии 3.**
Протокол, который используют клиенты для получения почтовых писем с сервера.
:::
Версии 1-ая и 2-ая устарели и в нынешнее время не используются.
Работает он по принципу «загрузи и удали».

**Что это значит?**
Это значит, что клиент заходит на сервер и смотрит, есть ли для него письмо. И если оно присутствует, он загружает его к себе и ставит отметку об удалении на сервере.

**Хорошо это или плохо, вопрос спорный.**
Кто-то утверждает, что это хорошо, так как сервер не бывает перегружен ненужными письмами.

Но есть и другая сторона.
* Во-первых современная инфраструктура позволяет хранить большой объем писем.
* Во-вторых часто случается, что пользователь удаляет или теряет важное письмо, и найти его потом становится трудно.

Хотя, стоит упомянуть, что некоторые клиенты можно настроить так, чтобы они не удаляли письма с сервера. Однако при стандартных настройках они удаляют письма с сервера -> будьте внимательнее.
:::warning
Порт, который он прослушивает — **110**.
:::
Довольно известный номер порта, поэтому возьмите себе на заметку.
Так же как и у протокола HTTP, у него есть **расширенная версия — POP3S**.
При помощи дополнительного криптографического протокола, как SSL, шифруется содержимое, и письма передаются в защищенном виде.
:::warning
**POP3S** использует **995 порт**.
:::
Мы обязательно рассмотрим протокол **POP3** на практике, после того, как узнаем про протокол **SMTP**.

Стоит упомянуть про аналог **POP3**.

----

#### **Аналог - протокол IMAP**
:::info
**Это протокол IMAP (англ. Internet Message Access Protocol).**
Протокол доступа к электронной почте. Он более умный и посложнее, чем **POP3**.
:::
Но главное их различие в том, что клиент, заходя на сервер, не удаляет почту, а копирует ее.
Таким образом, у клиента отображается копия почтового ящика, который хранится на почтовом сервере.
И если клиент у себя удаляет какое-либо письмо, то оно удаляется только у него.
На сервере оригинал остается целым.
:::warning
Слушает он **143 порт.**
:::
**Рассмотреть IMAP подробно в CPT не получится, так как полноценно он там не реализован.**

----

### **Протокол SMTP (англ. Simple Mail Transfer Protocol)**
:::info
Простой протокол передачи почты. Используется он, как вы поняли, для передачи почты на почтовый сервер. Вот почему мы изучаем **POP3** и **SMTP** параллельно.
:::

:::warning
Использует он **25 порт** - это тоже важно помнить.
:::

Также важно помнить, что все почтовые протоколы работают по **TCP-соединению**.
То есть с установлением соединения, здесь важно получить каждый пакет в целости и сохранности.

Думаю, с теоретической точки зрения все понятно.
Давайте перейдем к практике и посмотрим, как это работает.

----

#### **Демонстрация в CPT**

Открою я прошлый проект по DHCP и слегка его модернизирую.

Убрал я HTTP-сервер и вместо него добавил компьютер рабочего, и назвал **"ПК - сотрудника"**.
Присвою ему **IP-адрес**, который был у **HTTP-сервера**, то есть **192.168.1.2.**

Старый компьютер переименовал в **"ПК - директора"**.

DNS-сервер я оставил, он нам в этом проекте еще понадобится.

Сервер DHCP переименовал в **Mail-Server**.

И давайте его настроим.

Адрес я не менял, и он остался от прошлого проекта. Пускай таким и остается.

Далее:
1) Переходим в **"Services"**
2) Находим **"EMAIL"**
3) В поле **«Domain Name»** надо записать имя домена. Это то, что будет писаться после знака **"@"**. Обязательное требование. Любая почта записывается в таком формате — `логин@домен`. И нажимаем кнопку **«Set»**.
4) И создадим пользователей. В поле **«User»** запишем первого пользователя. Это будет **«Director»**.
5) Зададим пароль для этого пользователя **«123»**.
6) Нажимаем на знак **"+"**, чтобы добавить его в базу.

Аналогично создадим второго пользователя.
Это будет **«Worker»** с таким же паролем **«123»**.


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

1) Видим в базе список созданных пользователей. Их можно удалять, добавлять и менять пароли при помощи кнопок справа.
2) Не забываем включить службы POP3 и SMTP. Они по умолчанию включены, но проверка лишней не будет.

На этом настройка на стороне сервера заканчивается, и теперь перейдем к настройке на стороне клиентов.

**Начнем с компьютера директора.**

Открываем вкладку **«Desktop»** и выбираем **«Email»**.

После этого сразу откроется окно настройки.

1) В поле **«Your Name»** пишем любое имя.
2) В поле **«Email Address»** пишем почтовый ящик.
Для директора — это [e-mail].
4) В поля **«Incoming Mail Server»** и **«Outgoing Mail Server»** записываем адрес почтового сервера (**192.168.1.4**)
5) В поле **«User Name»** пишем сам логин.
То есть Director и соответственно пароль 123.

Нажимаем кнопку **«Save»**, и перед нами открывается почтовый клиент.
**CPT назвал его почтовым обозревателем.**

Аналогичная настройка будет на компьютере рабочего.

**Теперь самое время посмотреть, как работает почта.**

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

Открываем почтовый клиент на компьютере директора и создадим письмо.
Жмем на кнопу **«Compose»**, и перед нами открывается привычное окно.

Здесь все как обычно. Пишем кому отправляем, тему письма, сам текст письма и нажимаем кнопку «Send».

Видим следующее сообщение о том, что отправка завершена успешно.
Замечательно! Теперь посмотрим, как письмо будет доставлено рабочему.

Открываем почтовый клиент на компьютере рабочего.

1)И видим, что письма нету. А все потому, что клиент в CPT не поддерживает автоматическое обновление и приходится это делать вручную. Нажимаем кнопку «Receive».
2)Видим появившееся письмо и сообщение об успешном получении.
3)Откроем письмо и посмотрим, не побилось ли.

Открыть мы можем в двух вариантах:
Дважды кликнув по письму:

Или кликнув единожды:

И да, письмо, действительно, дошло целым и невредимым.

Ответим на это письмо и заодно проверим, что письма ходят в обе стороны.
Нажимаю я кнопку **«Reply»** и пишу ответ.


Отправляю письмо и перехожу к компьютеру директора.

И, соответственно, жму кнопку **«Receive»**, чтобы обновить почту.
Появилось письмо, а ниже и сообщение об успешном получении.

Открываем письмо, чтобы до конца удостовериться.

Письмо дошло, а значит все работает.

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


Как я говорил ранее, все почтовые протоколы работают с **TCP**.
А это значит, что перед тем, как начнет работать почтовый протокол, а в данном случае протокол **SMTP**, должно установиться предварительное соединение между компьютером и сервером. Это мы сейчас и наблюдаем.

Сейчас процесс установления соединения нас мало интересует. Мы сейчас говорим про почтовые протоколы, и поэтому я пропущу этот процесс и буду ждать появления **SMTP**.



1) Появился долгожданный SMTP, о чем свидетельствует запись в панели симуляции, откроем их.
2) Обратим внимания на TCP-порты, чтобы удостовериться, что это он. И видим, что в «Destination Port» стоит 25 номер.
А в «Source Port» записан динамически придуманный порт, чтобы сервер мог идентифицировать клиента. Все правильно.

Дальше он передает эти данные серверу. Посмотрим, что будет происходить дальше.

Сервер, получив данные от компьютера, формирует ответное сообщение.
Обратите внимание на изменения.
Номера, которые присутствовали ранее, поменялись местами, а именно **«Source Port»** и **«Destination Port»**.

Теперь источником является **сервер**, а назначением — **компьютер**.
Это сообщение о доставке письма серверу.

После этого работа протокола SMTP закончена, и компьютер может начать закрывать TCP-сессию. Чем он и займется.

Теперь когда письмо отправлено, и мы знаем, что оно лежит на сервере, попробуем получить это письмо.
Открываем **компьютер рабочего** и жмем кнопку **«Receive»**.

Как и с **SMTP**, в **POP3** тоже создается TCP-сессия.

Посмотрим на сам пакет повнимательней(1), а точнее на номера портов(2).
* В **«Destination Port»** стоит **110** номер порта - это и есть стандартный номер порта для протокола **POP3**.
* В **«Source Port»** стоит порт **1028**.

Смотрим дальше и ждем выхода POP3.

Вот он появился и наблюдаем, что в поле POP3 такая же картина, что и в SMTP, т.е. все то, что и так было понятно.

Дальше он отправляет этот запрос на сервер, и сервер должен ответить письмом, если оно там есть.

Мы знаем, что оно там есть и наблюдаем, как сервер формирует ответное сообщение.
И также как с SMTP, он меняет местами порты отправления и назначения.
На прикладном уровне запакованы какие-то POP3 данные.
Это и есть само письмо.

Как только данные попадут на компьютер, они сразу должны высветиться в почтовом клиенте(в примере на гифке, я забыл, что отправил 2 сообщения -> пакетов в 2 раза больше, не пугайтесь, принцип работы точно такой же).

И как только данные получены, о чем здесь свидетельствует галочка на фиолетовом пакете, письмо сразу же высвечивается в клиенте.

Дальше, как и в SMTP, будет закрытие TCP-сессии.

Приведу ссылку на скачивание данного [проекта](https://vk.com/doc157722137_614316427?hash=338b59cc6522af9534&dl=7e544141840069f64b).

#### **Роль DNS-сервера для почтовых протоколов**

И еще, что я хотел бы показать в дополнение к почтовым протоколам — это роль DNS-сервера.
Вы видели, что при совершении какого-либо действия в почтовом клиенте, он внизу нам писал IP-адрес сервера.
Но есть возможность указывать не IP-адрес, а доменное имя.
Давайте посмотрим, как это сделать.

Ну и самое логичное, что приходит в голову — это то, что у нас есть почтовый сервер с адресом 192.168.1.4.
И с этим адресом у нас будет работать доменное имя.
Соответственно заходим на DNS-сервер и сопоставим этому адресу имя.


Настройка на стороне DNS-сервера закончена, и осталось изменить 2 строчки в почтовых клиентах компьютеров. Открываем клиент на компьютере директора.

И нажимаем на кнопку **«Configure Mail»**.

Открывается окно, которое мы видели на этапе начальной конфигурации клиента.

Здесь надо поменять строки «Incoming Mail Server» и «Outgoing Mail Server». Вместо IP-адреса записываем доменное имя и нажимаем кнопку «Save».

То же самое проделываем и на компьютере рабочего.
Не буду давать лишних подробностей, просто приведу скрин.

Сразу попробуем написать письмо директору и отправить.

И после нажатия кнопки «Send», наблюдаем следующее. Внизу появляется сообщение о том, что он спросил у DNS-сервера адрес, и тот ему выдал IP-адрес почтового сервера. Отправка прошла успешно.

Теперь зайдем на компьютер директора и нажмем на кнопку **«Receive»**.

Получаем письмо, а надпись ниже свидетельствует об успешной доставке. Вот еще один пример использования DNS-сервера в сети.

Разобрали мы почтовые протоколы. И переходим к разбору следующего протокола.

---

### **Протоколо Telnet (от англ. terminal network)**
:::info
**Если Telnet переводить дословно** - то это сетевой терминал.
Применяется данный протокол для отображения текстового интерфейса, а также для управления ОС.
:::

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

**Сейчас постараюсь объяснить почему.**
Каждое сетевое устройство, интерфейс которого представляет собой командную строку, настраивается либо при помощи специального консольного кабеля, либо через виртуальные терминалы, в который и входит протокол Telnet.
И, если консольный кабель требует нахождения специалиста рядом с настраиваемым оборудованием, то настройка при помощи виртуальных терминалов, а в данном случае Telnet, не ограничивает специалиста в расстоянии. Можно находиться в другой комнате, здании, городе и все равно иметь возможность доступа к оборудованию.
Из минусов данного протокола отмечу, что он фактически не защищенный и все передается в открытом виде.
:::warning
Данный протокол использует **23 порт**.
:::

А самые популярные дистрибутивы, которые работают с этим протоколом — это **Putty**, **Kitty**, **XShell** и т.д.

----

#### **Демонстрация в CPT**
Использовать Telnet мы будем для доступа к коммутатору **Cisco 2960**.
Он, как и все Cisco устройства, использует разработанную компанией **Cisco** операционную систему **IOS**.
А интерфейс командной строки называется **CLI (Command Line Interface)**.

##### **Настройка коммутатора (свича)**
Давайте для начала настроим коммутатор.
Повесим на него IP-адрес, так как без него мы не сможем попасть на коммутатор и разрешим доступ по Telnet.

1. Дважды нажимаем на наш коммутатор

2. Переходим во вкладку **"CLI"**

3. И прописывем:
`Switch>enable` — переход в привилегированный режим. Отсюда доступно большинство команд.

4. 
`Switch#configure terminal` — переход в режим глобальной конфигурации.
В этом режиме возможен ввод команд, позволяющих конфигурировать общие характеристики системы. Из режима глобальной конфигурации можно перейти во множество режимов конфигурации, специфических для конкретного протокола или функции.

5. 
`Switch(config)#username admin secret cisco` — создаем пользователя с именем admin и паролем cisco.

6. 
`Switch(config)#interface vlan 1` — переходим в виртуальный интерфейс и повесим на него IP-адрес. Здесь прелесть заключается в том, что не важно, на каком именно из 24-х портов он будет висеть. Нам главное, чтобы просто с какого-либо порта был доступ до него.

7. 
`Switch(config-if)#ip address 192.168.1.254 255.255.255.0` — присваиваем последний адрес 192.168.1.254 с маской 255.255.255.0

8. 
`Switch(config-if)#no shutdown` — по умолчанию интерфейс выключен, поэтому включаем его. В IOS 90% команд отменяются или выключаются путем приписывания перед командой «no».

Возвращаемся в config, можно это сделать комбинацией клавиш **ctrl + z** и по новой прописать команду `configure terminal`

9. 
**Switch(config)#line vty 0 15** — переходим в настройки виртуальных линий, где как раз живет Telnet. От 0 до 15 означает, что применяем это для всех линий. Всего можно установить на нем до 16 одновременных соединений.

10. 
`Switch(config-line)#transport input all` — и разрешаем соединение для всех протоколов. Я специально настроил для всех протоколов, так как чуть позже будет рассматриваться другой протокол и лезть сюда ради одной команды не считаю разумным.

11. 
`Switch(config-line)#login local` — указываем, что учетная запись локальная, и он будет проверять ее с той, что мы создали.

12. Возвращаемся в привилегированный режим комбинацией клавиш **ctrl + z**

13. 
`Switch#copy running-config startup-config` — обязательно сохраняем конфигурацию. Иначе после перезагрузки коммутатора все сбрпосится.

14. 
**Итак коммутатор настроен.**

Давайте подключимся к нему c рабочего компьютера. Открываем командную строку. Мы ее открывали, когда рассматривали **nslookup**.
И пишем следующее.

То есть команда telnet и адрес, куда подсоединиться.

Если все верно, то открывается следующее окно с запросом логина и пароля.

Соответственно пишем **логин**:admin и **пароль**:cisco (мы создавали его на коммутаторе).

И он сразу пускает нас на коммутатор. Для проверки проверим доступность компьютера директора, при помощи команды ping.

Ping успешен. Надеюсь, понятно, что проверка доступности осуществляется не с компьютера рабочего, а с коммутатора. Компьютер здесь является управляющим устройством и все. Рассматривать его в режиме симуляции я не буду. Он работает точно так же, как и почтовые протоколы, то есть создается TCP-сессия, и, после установления соединения, начинает работать Telnet. Как только он отрабатывает, он начинает разрывать соединение.
А вот и сам проект -> [ссылка](https://vk.com/doc157722137_614537053?hash=68e21eaf5efc4bd386&dl=4f3d12e28f3ca7e941)

----

### **Протокол SSH (англ. Secure Shell)**
:::info
В переводе с английского — безопасная оболочка. Как и Telnet позволяет управлять ОС.
Отличие его в том, что он шифрует весь трафик и передаваемые пароли.
Шифруется при помощи алгоритма [Диффи-Хеллмана](https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%94%D0%B8%D1%84%D1%84%D0%B8_%E2%80%94_%D0%A5%D0%B5%D0%BB%D0%BB%D0%BC%D0%B0%D0%BD%D0%B0).
:::
Кому интересно почитайте.
:::warning
Использует порт 22
:::
Практически все современные ОС системы умеют работать с этим протоколом. Если у вас стоит выбор, какой протокол применять, то используйте SSH.

----
#### **Демонстрация в CPT**
Сначала немного помучаетесь в настройке, и многое будет непонятно, но со временем в голове уляжется. Главное запомните сейчас, что самое главное отличие SSH от Telnet — **это то, что SSH шифрует трафик, а Telnet нет**.
Я думаю пора перейти к практике и посмотреть, как это работает. Подключаться и управлять мы будем тем же коммутатором.

Давайте попробуем подключиться по SSH с компьютера директора к коммутатору.

Что произошло?
Здесь синтаксис команды немного другой, нежели при подключении по Telnet.
`ssh -l admin 192.168.1.254`

Разберем команду:
Пишем ssh с ключом l, после набираем логин (у нас это admin) и адрес, куда подключаемся (192.168.1.254). Завершаем это дело клавишей ENTER. Выдается сообщение, что соединение было закрыто внешним хостом. То есть коммутатор закрыл соединение. Все потому, что не были созданы ключи, которые работают с шифрованием. Зайду на коммутатор и настрою его для корректной работы по SSH.

1. `Switch>enable` — переход в привилегированный режим. Отсюда доступно большинство команд.

2. `Switch#configure terminal` — переход в режим глобальной конфигурации. В этом режиме возможен ввод команд, позволяющих конфигурировать общие характеристики системы. Из режима глобальной конфигурации можно перейти во множество режимов конфигурации, специфических для конкретного протокола или функции.

3. `Switch(config)#hostname SW1` — меняем имя коммутатора. С этим стандартным именем нельзя прописать домен, который нужен для генерации ключей.

4. `SW1(config)#ip domain-name cisadmin.ru` — прописываем домен.

5. `SW1(config)#crypto key generate rsa` — генерируем RSA ключи.

    The name for the keys will be: SW1.cisadmin.ru
    Choose the size of the key modulus in the range of 360 to 2048 for your
    General Purpose Keys. Choosing a key modulus greater than 512 may take
    a few minutes.

`How many bits in the modulus [512]:` 1024 — Указываем размер ключа.
По умолчанию предлагается 512, но я введу 1024.

`% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]`
Выходит сообщение о удачной генерации ключей.

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


И уже выдается другое сообщение, с запросом на ввод пароля.
Вводим пароль **«cisco»** и оказываемся на коммутаторе.

Осталось проверить работу. Я воспользуюсь командой ping и проверю доступность рабочего компьютера.

И убедился, что все прекрасно работает.

Вот ссылочка на [проект](https://vk.com/doc157722137_614537325?hash=f552831ae5e5b446bb&dl=a673d93175e2a2d921)

----

### **Протокол FTP (англ. File Transfer Protocol)**
:::info
Протокол передачи файлов,думаю из названия протокола ясно, что он передает файлы.
:::

:::warning
Обычно находится на портах: 21,20,49152-65534
:::

Очень древний протокол, вышедший в начале 70-х годов. Появился он еще до HTTP и стека TCP/IP. Как работал раньше, так и сейчас работает по **«клиент-сервер»** модели.
То есть, присутствует инициатор соединения и тот, кто его слушает. Есть несколько модификаций, которые поддерживают шифрование, туннелирование и так далее.
Раньше с этим протоколом работали разные консольные утилиты, у которых не было графики и работали они, при помощи ввода определенных команд.
В нынешнее время присутствуют и графические программы.
Самой популярной и простой является **Filezilla**.
В CPT реализован только консольный метод :(

----

#### **Демонстрация в CPT**

Переходим к практике.

За основу я возьму предыдущий проект и почтовый сервер заменю FTP-сервером.

Проделываем следующие вещи:

1. Откроем FTP-сервер и перейдем во вкладку **"Services"**.
2. Далее идем в сервис **"FTP"**.
3. Учетка, которая по умолчанию была здесь создана. Это стандартная учетная запись с логином **«cisco»** и таким же паролем. В правой колонке видим **«Permission»** — это права доступа. И видим, что данная учетка имеет все права. В тестовой среде нам как раз это и надо, но, работая в компании, всегда следите за правами каждой учетки.
4. Хранилище FTP - здесь в основном прошивки для цисковских устройств.
**По умолчанию служба включена, но лучше проверить.**

Сервис настроен и раз все так прекрасно, попробуем с ним поработать. Но для начала создам текстовый файл на компьютере директора, который потом выкачаю на FTP-сервер.

**Как это сделать?**
Открываю компьютер директора и выбираю **«Text Editor»** - это аналог блокнота в ОС Windows.

Напишу туда текст и сохраню его.

Теперь попробуем залить этот файл на FTP-сервер. Открываем командную строку и пишем: `ftp 192.168.1.4`
**Логин**: cisco
**Пароль**: cisco

То есть, как помним ранее, в начале пишется используемый протокол, а потом следует адрес. Далее, после соединения, спрашивается логин и пароль.
И после аутентификации попадаем на сам FTP-сервер.

Список доступных команд можно проверить командой **"?"**.

Чтобы что-то залить, используется команда **«put»**, а скачать команда **«get»**.
Заливаем наш файл.

Ввел я команду **«put»** и название файла, которое хочу скопировать. И показывает он нам сообщение, что все скопировано. Файл весит 137 байтов, а скорость передачи 3044 байтов в секунду.
Далее ввел команду **«dir»**, чтобы проверить содержимое сервера. И засветился на нем файл COOOLMES.txt под 0 номером.

Осталось дело за малым. Это скачать файл на компьютер рабочего. Открываю я ПК - сотрудника и захожу в командную строку.

Выполняю я практически те же действия, что и ранее. За исключением команды **«get»**, а не **«put»**.
Видим, что файл скачен.

Еще я ввел команду **«dir»**, чтобы показать, что при скачивании файла, оригинал не удаляется, **скачивается его копия**.

И раз он скачал файл, то он должен появиться на компьютере.
Открываю **«Text Editor»** и нажимаю **File->Open**.

Вижу, что файл действительно присутствует и пробую его открыть.

Файл пришел целым. Весь текст присутствует.

Не буду повторно засорять вам голову, как это работает. Потому что работает оно точно так же, как и почтовые протоколы, Telnet, SSH и так далее.
То есть создается TCP-сессия, и начинается передача/скачивание файла.

Приведу только структуру его.

В TCP обращаем внимание на номер порта. Это **21 порт** (один из стандартных портов FTP).
И в поле данных FTP обозначено, что это какие-то двоичные данные.

Вот так в принципе работает всемирно известный протокол.
**Более расширенные версии здесь не поддерживаются, но работают они практически так же.**

А вот и сама ссылочка на [проект](https://vk.com/doc157722137_614539213?hash=9a14028f7fb2251289&dl=c4a124360f7b1ee13e)

И последний протокол, который остался — это TFTP.

----

### **Протокол TFTP (англ. Trivial File Transfer Protocol)**
:::info
Простой протокол передачи файлов. Придумали его в 80-х годах. Хоть FTP был достаточно популярным, не все его функции были нужны для решения простых задач. И был придуман его простой аналог. Он работает по UDP, то есть не требует установления соединения. Также он не требует аутентификации и авторизации. Достаточно знать его IP-адрес и самому его иметь. Это конечно не безопасно, так как адрес можно подделать. Но когда нужен простой протокол и не требуется авторизация, выбор падает на него.
:::

:::warning
TFTP использует порт 69
:::

Очень плотно с ним работает цисковское оборудование, для копирования образа или скачивания на flash-память.

----

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

Поэтому будем учиться на нашем любимом коммутаторе.
Схема остается такой же.

Просто на FTP-сервере я включу сервис TFTP.

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

**Перейдем к коммутатору.**

1. `Switch>enable` — переход в привилегированный режим. Отсюда доступно большинство команд.

2. `SW1#dir` — команда вывода содержимого файловой системы

    Directory of flash:/

    1 -rw- 4414921 c2960-lanbase-mz.122-25.FX.bin
    9 -rw- 1168 config.text

    64016384 bytes total (59600295 bytes free)


**У нас есть файл config.text. Попробуем его залить на TFTP — сервер.**

3. `SW1#copy flash: tftp:` — то есть указываем откуда, а потом куда. Здесь это с flash-памяти на tftp-сервер

`Source filename []? config.text` — здесь он спрашивает имя файла, которое надо скопировать.

`Address or name of remote host []? 192.168.1.4` — указываем куда скопировать.

`Destination filename [config.text]?` — и тут надо указать, под каким именем сохранить его на сервере. По умолчанию он предлагает сохранить его с тем же названием.И, если нажать клавишу ENTER, он выберет имя по умолчанию. Меня это устраивает, и я оставлю его таким же.

    Writing config.text....!!!
    [OK — 1168 bytes]

    1168 bytes copied in 3.048 secs (383 bytes/sec)


И в заключительном сообщении он показывает, что все успешно скопировалось.

4. Перейдем на TFTP-сервер и проверим.

И вижу, что действительно он там присутствует. Значит коммутатор меня не обманул.

**Теперь попробуем что-нибудь скачать с сервера на коммутатор.**

1. `SW1#copy tftp: flash:` — здесь пишем наоборот. Сначала tftp, а потом flash

`Address or name of remote host []? 192.168.1.4` — адрес TFTP-сервера

Далее он спросит, что скопировать. Я не помню точное название прошивки и открою TFTP, чтобы посмотреть.

Записываю название
`Source filename []? c2960-lanbasek9-mz.150-2.SE4.bin`

`Destination filename [c2960-lanbasek9-mz.150-2.SE4.bin]?` — здесь он спрашивает, как назвать его на самом коммутаторе. Я нажму ENTER и оставлю имя по умолчанию.

    Accessing tftp://192.168.1.4/c2960-lanbasek9-mz.150-2.SE4.bin…
    Loading c2960-lanbasek9-mz.150-2.SE4.bin from 192.168.1.4:!!!
    [OK — 4670455 bytes]

    4670455 bytes copied in 0.057 secs (6587503 bytes/sec)


Выдал он мне сообщение, что загрузка прошла успешно.

2. Проверю я наличие прошивки командой **«dir»**.

    SW1#dir
    Directory of flash:/

    1 -rw- 4414921 c2960-lanbase-mz.122-25.FX.bin
    10 -rw- 4670455 c2960-lanbasek9-mz.150-2.SE4.bin
    9 -rw- 1168 config.text

    64016384 bytes total (54929893 bytes free)


Вижу, что действительно все на месте. И вдобавок он мне сообщает об объеме памяти и наличии свободного места.

Закончили мы рассматривать протоколы верхнего уровня.
И теперь переходим к протоколам нижних уровней!

----

# Что нас ждет дальше?

* Модель OSI (протоколы нижних уровней)

----
# Домашка (по желанию)

1. Повторить всю практику.

----

# СПАСИБО ВАМ ЗА ВНИМАНИЕ, надеюсь было понятно и полезно! (не забывайте практиковаться)