Основи комп'ютерних мереж. Тема №2. Протоколи верхнього рівня

І знову всім привіт! Сьогодні мова піде про протоколи верхнього рівня. Розберемо, як вони працюють, із чого складаються і де застосовуються теоретично і на практиці.



Зміст1) Основні мережеві терміни, мережева модель OSI і стек протоколів TCP/IP.
2) Протоколи верхнього рівня.
3) Протоколи нижніх рівнів (транспортного, мережевого і канального).
4) Мережеві пристрої і види застосовуваних кабелів.
5) Поняття VLAN Trunk і протоколи VTP і DTP.
6) Протокол сполучного дерева: STP.
7) Протокол агрегування каналів: Etherchannel.
8) Поняття IP адресації, масок підмереж і їх розрахунок.
9) Маршрутизація: статична і динамічна на прикладі RIP, OSPF і EIGRP.
10) Трансляція мережевих адрес: NAT і PAT.
11) Протоколи резервування першого переходу: FHRP.
12) Безпека комп'ютерних мереж і віртуальні приватні мережі VPN.
13) Глобальні мережі і використовувані протоколи: PPP, HDLC, і Frame Relay.
14) Введення в IPv6, конфігурація і маршрутизація.
15) Мережеве управління і моніторинг мережі.

P. S. Можливо, з часом список доповниться.
Як ви пам'ятаєте з минулої статті (якщо не читали, то у змісті є посилання на неї), модель OSI в нинішній час служить в якості навчання ролям кожного рівня. Працюють же мережі по стеку протоколів TCP/IP. Хоч TCP/IP складається з 4 рівнів, він цілком реалізує всі функціональні можливості, реалізовані в моделі OSI. Нижче на малюнку наведено порівняння рівнів та їх ролей.


Починаємо розмову про протоколи верхнього рівня. Я не просто так назвав тему «Протоколи верхнього рівня», а не «Протоколи верхніх рівнів». Так як ми розбираємо цей рівень стека TCP/IP, то у нас він «один за трьох».

Взагалі з точки зору сетевика, нам все одно, що відбувається всередині прикладного рівня. Цим, як правило, займаються програмісти. Але важливо знати, як формуються дані і інкапсулюються в нижчестоящі рівні.
У нас на роботі, наприклад, є правило: ми забезпечуємо запуск програми та її безпомилкову передачу по мережі. Якщо проблема полягає у внутрішніх програмних збоях, то ми перемикаємо на розробників, і це стає їх турботою. Але бувають і проблеми, які йдуть по тонкій грані між нами, і ми вирішуємо їх разом.

Отже, протоколи прикладного рівня забезпечують взаємодію між людиною і мережею. Цих протоколів величезна кількість, і вони виконують абсолютно різні ролі. Я наведу приклади часто використовуваних протоколів в мережі і покажу, як вони працюють на практиці: HTTP, DNS, DHCP, SMTP і POP3, Telnet, SSH, FTP, TFTP.

I) Протокол HTTP (англ. HyperText Transport Protocol). Протокол передачі даних, що використовується зазвичай для отримання інформації з веб-сайтів. З кожним роком цей протокол стає все популярнішим, і можливостей для його застосування стає все більше. Використовує він «клієнт-серверну модель. Тобто існують клієнти, які формують і відправляють запит. І сервери, які слухають запити і, відповідно, на них відповідають.

В якості клієнтів виступають відомі багатьом веб-браузери: Internet Explorer, Mozilla Firefox, Google Chrome і т. д. А як серверного ПЗ використовують:Apache, IIS, nginx і т. д.

Для того, щоб глибше розібратися в протоколі HTTP, поглянемо на HTTP запит від клієнта до сервера.


Нас цікавлять тільки сама верхня і сама нижня рядки.

В першій сходинці використовується таке поняття, як GET. Це, по суті, ключ запиту. Так як після GET стоїть символ "/", то це означає, що запитується головна або коренева сторінка URL (англ. Uniform Resource Identifier) шляхи.

URL — це якийсь ідентифікатор будь-якого ресурсу в мережі.

Так само в цій сходинці присутній такий запис, як HTTP/1.1. Це версія протоколу. Досить популярна версія. Випустили її в 1999 році, і до цих пір вона служить вірою і правдою. Хоч нещодавно був анонс версії 2.0, версія 1.1 займає поки лідируюче положення.

Тепер про нижній сходинці. Тут вказується адреса сервера або ім'я, на якому розташовується потрібний ресурс. Давайте подивимося, як це працює на практиці. Я буду використовувати свою улюблену програму Cisco Packet Tracer 6.2 (надалі CPT). Вона проста в освоєнні і для демонстрації описаного ідеально підходить. Можу сказати з упевненістю, що для підготовки до CCNA R&S, її вистачає цілком. Але тільки для неї.

Відкриваємо програму і додамо туди комп'ютер з сервером (що знаходяться на вкладці «End Devices»), як на картинці нижче


З'єднуємо комп'ютер з сервером перехресним кабелем (англ. crossover cable). У CPT він знаходиться на вкладці «Connections», позначається пунктиром і називається «Copper Cross-Over».

Тепер займемося налаштуванням комп'ютера і веб-сервера.


1) Відриваємо вкладки «Desktop» на робочому комп'ютері і сервері, далі переходимо у вікно «IP Configuration». Відкриються вікна, як на малюнку вище. Це вікна конфігурації вузлів в мережі.

2) Вкажемо IP-адреси в строки, зазначені цифрою 2. Як пам'ятаємо з попередньої статті, IP-адреси потрібні для ідентифікації вузлів в мережі. Детальніше ми розглянемо цю тему пізніше. Зараз головне розуміти, для чого потрібен IP-адресу. Я спеціально вибрав мережа, що починається з «192.168», так як вона зустрічається найчастіше в домашніх мережах.

3) В поля, зазначені цифрою 3, вводиться маска підмережі. Вона потрібна для того, щоб сайту було зрозуміло, в одній підмережі він знаходиться з іншим вузлом чи ні. Але про це пізніше.
Інші значення залишимо порожніми.

Тепер потрібно включити сервіс HTTP на сервері.


1) Переходимо на вкладку «Services».
2) Вибираємо зліва сервіс HTTP.
3) Відкривається вікно налаштування сервісу і файловий менеджер. Якщо у кого є навички по роботі з HTML, то можете тут створити сторінку. Але у нас вже є готовий шаблон, і ми ним скористаємося. Не забуваємо включити службу 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».


І ось після встановлення з'єднання, комп'ютер формує перші HTTP дані. Надалі я буду називати їх PDU, щоб ви звикали до даних термінів.

1) Дивимося на схему і бачимо, що з'явилося 2 конверта. Це і є наші дані. Нас цікавить фіолетовий конверт. Це і є створений PDU.

2) Тепер дивимося на «Simulation Panel» і бачимо, що в таблиці з'явився запис з типом HTTP. Ці дані нас цікавлять. Також поруч із записом показаний колір, яким пофарбовані ці дані на схемі.

3) Клікаємо по HTTP (фіолетовий конверт), і перед нами відкривається вікно даних. Тут коротко показані всі потрібні відомості по кожному рівню моделі OSI. Можна клікнути по кожному рівню і отримати інформацію про те, що відбувається на ньому.

Якщо вам цікаво повністю розкрити дані і розглянути докладно, з яких полів вони складаються і що в них відбувається, є вкладка «Outbound PDU Details». Давайте перейдемо на неї і подивимося, як виглядають HTTP дані.


На цій вкладці виводитимуться дані на всіх рівнях. Нам поки що треба подивитися на HTTP. Вони знаходяться в самому низу, тому тягнемо бігунок вниз. Виглядають вони так само, як я і описував їх раніше.

Тепер нам цікавий етап, коли веб-сервер отримає запит і почне робити якісь дії. Давайте натиснемо на «Capture/Forward» і подивимося, чим веб-сервер відповість. І ось на малюнку нижче бачимо, що він відправив комп'ютера якісь дані. Давайте подивимося, як вони виглядають.


1) Я випадково перетиснув кнопку і він вже почав формувати TCP на закриття сесії. Нічого страшного. Знаходимо PDU, адресовані від веб-сервера до клієнта. Як бачимо, він одразу показує нам на схемі момент часу, в який я клікнув. Вибираємо потрібний конверт.

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


Ось так працює протокол HTTP. Давайте розглянемо його розширену версію HTTPS. Як ми пам'ятаємо, ця версія підтримує шифрування і не передає дані у відкритому вигляді. На самому початку, ми включили сервіс HTTP і HTTPS. Тому все готово, і можна запитувати сторінку. Відмінність запиту в тому, що перед адресою сторінки замість HTTP, пишемо HTTPS.


Бачимо напис, що дані захищені, і ми їх прочитати не можемо. В принципі, це всі відмінності, які може показати CPT, але для базового розуміння цього достатньо. Від себе додам, що коли ви переходите на сайт, що працює по HTTPS, в браузері він позначається у вигляді замку. Наприклад

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

Ми поговорили про HTTP, і тепер час розібрати протокол DNS. Даний протокол тісно пов'язаний з попереднім протоколом, і скоро ви зрозумієте чому.

II) DNS (Domain Name System). Система доменних імен. Якщо говорити в цілому, то вона зберігає інформацію про домени. Наприклад, яким 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. Найстаршим буде доменне ім'я «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 і показую, як це працює. Ця і наступні лабораторні роботи буду ґрунтуватися на попередній. Тому адресація буде такою ж.


Тут доданий ще один сервер, який буде виконувати роль DNS-сервера і комутатор. Коли в мережі з'являються 3 і більше пристроїв, то для їх з'єднання використовують комутатор.

Займемося налаштуванням DNS-сервера. Зайдемо в «IP Configuration» і пропишемо IP адреса з маскою.



Тепер зайдемо в сервіси і налаштуємо службу DNS.


1) У вікні «Name» запишемо ім'я, яке хочемо прив'язати до IP адресою. (я написав ім'я свого майбутнього сайту, над яким йде робота).
2) У вікні «Address», відповідно, IP-адресу, який буде працювати у зв'язці з вище написаним ім'ям. (тут зазначимо той же адреса, що і в лабораторній по HTTP — 192.168.1.2).
3) Натискаємо кнопку «Add», щоб додати цю запис.
4) Не забуваємо включити саму службу!

Якщо всі виконали вірно, то картина повинна бути такою.


Тепер треба в налаштуваннях сервера і комп'ютера вказати адресу DNS-сервера.


Налаштування DNS-сервера і вузлів закінчена, і саме час перевірити, як це річ працює. Перемикаємо середу в режим симуляції і спробуємо з комп'ютера зайти на сайт по імені «cisadmin.ru».


І бачимо, що створюються 2 конверта. Перший — це DNS, а другий — ARP. Про ARP ми не говорили, так як це тема наступної статті. Але раз він показав себе, то коротко розповім, для чого він. Як ми пам'ятаємо, для обміну між вузлами недостатньо IP адреси, так як ще використовуються MAC-адреси, які працюють на канальному рівні. Ми вказали комп'ютера IP-адресу DNS-сервера. Але він не знає, який вузла з IP-адресою 192.168.1.3 MAC-адресу. Він формує ARP повідомлення і викидає його в мережу. Даний кадр (дані на канальному рівні називаються — кадри) є широкомовним, тобто його отримають всі учасники, що знаходяться в одній локальній мережі (правильно сказати всі учасники в одному широкомовному домені, але поки ми це не зачіпали, і я не буду вантажити вас цим терміном). І той, у кого ця адреса, відправить зворотне повідомлення і повідомить свій MAC-адресу. Всі інші учасники відкинуть цей кадр. Дивимося малюнки.


Ось кадр прийшов на комутатор, і тепер його завдання розіслати цей кадр на всі порти, крім того, звідки він прийшов.


Кадри були розіслані і спостерігаємо наступне. Кадр, який прийшов на веб-сервер був відкинутий, про що говорить перекреслений конверт. Отже, кадр відкидається. А DNS-сервер, навпаки, дізнався адресу і повинен сформувати відповідь.


І як бачимо, був створений ARP-відповідь. Давайте трохи розберемо його.

1) MAC-адреси. В Source MAC він записує свій MAC-адресу, а в Destination MAC (Target MAC) адреса комп'ютера.
2) Source IP свій IP адреса, а в Target IP адреса ПК.

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

Я натискаю на «Capture/Forward» і дивлюся, що буде далі відбуватися.


І бачу, що комп'ютер успішно отримав ARP від сервера. Тепер він знає MAC-адресу DNS-сервера, а значить, і як з ним зв'язатися. І відразу вирішує дізнатися у нього, хто такий «cisadmin.ru». Ми можемо відкрити ці дані і подивитися, що він там вирішив відправити. Відкриваємо «Outbound PDU Details» і спускаємося в самий низ. Бачимо, що у верхньому полі «NAME» він записав запитувана ім'я. Тиснемо кнопку «Capture/Forward» і дивимося.


DNS-сервер отримує DNS-запит. Він лізе в свою таблицю і бачить, що такий запис у нього є, і формує відповідь. Відкриваємо і бачимо, що змінилося полі LENGTH і дорівнює 4. Тобто 4 байти. Стільки займає IP адресу. І, відповідно, записує сам IP-адреса — 192.168.1.2. Це і є адреса веб-сервера. Рухаюся далі.


Бачимо, що комп'ютер отримав повідомлення від DNS-сервера, про що свідчить позначка на коричневому конверті. І тепер він знає IP-адресу веб-сервера. Відразу ж він намагається встановити TCP сесію, але виникає проблема. Він не знає MAC-адресу веб-сервера і запускає аналогічний ARP запит, щоб дізнатися. Дивимося.


І тут аналогічно попередньому. DNS-сервер зрозумів, що повідомлення не для нього, і відкидає. А веб-сервер дізнається свій IP адреса і формує ARP-відповідь.


Дійшов до комп'ютера ARP відповідь. Тепер він знає MAC-адресу веб-сервера і намагається встановити TCP сесію. Відправляє він TCP сегмент на 80-й порт. Раз вже протокол TCP знову дав про себе знати, і в наступних протоколах він теж буде фігурувати, то коротко поясню навіщо він потрібен. Як ви пам'ятаєте з першої статті, я говорив, що він встановлює з'єднання. Так от тепер кожен блок даних, який буде відправлений від сервера комп'ютера, буде промаркований. Це потрібно для того, щоб клієнт розумів, чи всі дані він отримав або які загубилися. І, якщо якісь дані загубилися, він зможе запросити їх повторно. Втрата блоку даних сайту може призвести до того, що сайт перекосить, і він з'явиться криво. Але зараз головне розуміти, що TCP розташовується на транспортному рівні і працює з портами. Я спеціально відкрив вікно, де це написано, щоб ви поступово звикали до цих полів.

Подивимося, чим відповість комп'ютера веб-сервер.


Веб-сервер надсилає відповідне повідомлення, і встановлюється сесія. І, коли все готово, комп'ютер формує HTTP і відсилає його веб-сервера. Давайте подивимося, що змінилося. А змінилася у нас остання строчка. Якщо раніше там був записаний IP адресу веб-сервера, то тепер там красується доменне ім'я «cisadmin.ru». Але не забувайте, що доменне ім'я тут записано тільки в даних прикладного рівня. IP-адреса нікуди не подівся. Він розташовується на мережному рівні. Тому давайте відразу покажу IP пакет, де представлені ці адреси.


І як бачите, IP адреси на місці.

Далі процес аналогічний лабораторної по HTTP. Тому наведу фінальний етап, де по імені «cisadmin.ru» відкриється сторінка, що знаходиться на сервері з IP адресою 192.168.1.2.



Відповідно бачимо, що все прекрасно працює, і сайт відкривається по доменному імені.
І наостанок згадаю про одну дуже важливу утиліту під назвою 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, наведу посилання на скачування даної лаби.

А ми рухаємося далі і розбираємо протокол DHCP.

III) DHCP (Dynamic Host Configuration Protocol). Протокол динамічної настройки вузла. Він дозволяє вузлів динамічно одержувати IP-адресу й інші параметри для коректної роботи в мережі (основний шлюз, маску підмережі, адреси DNS-серверів). Від себе скажу, що цей протокол рятує життя багатьом сисадмінам по всьому світу. Погодьтеся, що ходити і вручну прописувати IP параметри кожного вузла, не найприємніше заняття.

За допомогою DHCP можна забезпечити повний контроль над IP адресами: створювати окремі басейни для кожної підмережі, видавати адреси в оренду, резервувати адреси і багато іншого.

Робота дуже важка для нинішнього розуміння. Занадто багато пакетів даних і кадрів має передатися, перш ніж запитану адресу буде присвоєно комп'ютеру.

Давайте подивимося, як він працює на практиці.


І бачимо, що додався новий сервер. Звичайно можна було всі ролі віддати одного сервера, але, щоб ви розуміли, як ходять дані, нехай для кожної ролі буде окремий сервер.

Налаштуємо сервер.


Присвоюємо вільний адресу і маску. Перейдемо до ролі DHCP.


1) Вибираємо службу DHCP, і тут вже створено стандартний пул. Його не можна видалити. Тільки змінити. Можете самі створити кілька пулів і витворяти з ними, що завгодно, аж до видалення. Але стандартний завжди залишиться. Нам додаткові пули не потрібні, тому будемо переробляти під себе стандартний.

2) Тут можна додати адресу шлюзу, адресу DNS-сервера. Ми поки не торкалися питання шлюзу, тому поки не будемо його чіпати. DNS-сервер у нас є, і його можна вказати. Ну і старт адрес залишимо, як є.

3) Не забуваємо включити сервер!

Перемикаємо середу в режим симуляції і подивимося, як комп'ютер отримає адресу.


Відповідно переходимо в налаштування конфігурації і перемикаємо на 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-адресами. І тут можуть початися дикі чудеса. Сучасні системи вже навчилися правильно реагувати на це, але все ж не варто цього допускати і важливо стежити за цим. Я пропущу в CPT всі ці дані, інакше вийде діафільм з одноманітних картинок. Я прикреплю цю лабу нижче, і ви зможете самі в цьому переконатися. Наведу тільки кінцевий підсумок, який сформує DHCP-сервер.


І бачимо, що в полі "«YOUR» CLIENT ADDRESS" додався адреса 192.168.1.5. Це адреса, яка DHCP-сервер пропонує комп'ютера. У полі «SERVER ADDRESS» DHCP-сервер додає свою адресу, щоб комп'ютер знав, хто пропонує йому адресу. У полі «CLIENT HARDWARE ADDRESS» додається MAC-адресу комп'ютера (тобто того, хто запросив). І в самому низу представлена опція «DHCP Domain Name Server Option». Сюди записується адреса DNS-сервера, який ми вказали в налаштуваннях сервісу DHCP.

Подивимося, як комп'ютер отримає адресу.


І спостерігаємо повідомлення «DHCP Request Successful». Що означає, що отримані дані успішно, про що свідчать заповнені поля нижче.

Ось так працює протокол DHCP. Як обіцяв, посилання для скачування.

Переходимо далі, і дійшла черга до протоколів POP3 і SMTP. Я спеціально згадав ці протоколи разом і зараз поясню, чому.

IV) POP3 (англ. Post Office Protocol Version 3). Протокол поштового відділення версії 3. Протокол, який клієнти використовують для отримання поштових листів з сервера. Версії 1-ша та 2-га застаріли і в нинішній час не використовуються. Працює він за принципом «завантаж і видали». Що це означає? Це означає, що клієнт заходить на сервер і дивиться, чи є для нього лист. І якщо воно присутнє, він завантажує його до себе і ставить відмітку про видалення на сервері. Добре це чи погано, питання спірне. Хтось стверджує, що це добре, так як сервер не буває перевантажений непотрібними листами. Я вважаю інакше. По-перше сучасна інфраструктура дозволяє зберігати великий обсяг листів, а по-друге часто трапляється, що користувач видаляє або втрачає важливе лист, і знайти його потім стає важко. Хоча, варто згадати, що деякі клієнти можна налаштувати так, щоб вони не видаляли листи з сервера. Однак при стандартних налаштуваннях вони видаляють листи з сервера. Тому будьте уважнішими. Порт, який він прослуховує — 110. Досить відомий номер порту, тому візьміть собі на замітку. Так само як і у протоколу HTTP, у нього є розширена версія — POP3S. За допомогою додаткового криптографічного протоколу, як SSL, шифрується вміст, і листи передаються в захищеному вигляді. POP3S використовує 995 порт. Ми обов'язково розглянемо протокол POP3 на практиці, після того, як дізнаємося про протокол SMTP.

Варто згадати про аналог POP3. Це протокол IMAP (англ. Internet Message Access Protocol). Протокол доступу до електронної пошти. Він більш розумний і складніше, ніж POP3. Але головне їх відмінність у тому, що клієнт, заходячи на сервер, не видаляє пошту, а копіює її. Таким чином, у клієнта з'являється копія поштової скриньки, який зберігається на сервері. І якщо клієнт у себе видаляє будь-який лист, то воно віддаляється тільки у нього. На сервері оригінал залишається цілим. Слухає він 143 порт. Розглянути IMAP докладно в CPT не вийде, так як повноцінно він там не реалізований.

V) SMTP (англ. Simple Mail Transfer Protocol). Простий протокол передачі пошти. Використовується він, як ви зрозуміли, для передачі пошти на поштовий сервер. Ось чому ми вивчаємо POP3 і SMTP паралельно. Використовує він 25 порт. Це теж важливо пам'ятати.

Також важливо пам'ятати, що всі поштові протоколи працюють з TCP-з'єднання. Тобто з встановленням з'єднання. Тут важливо отримати кожен пакет в цілості й схоронності.

Думаю, з теоретичної точки зору все зрозуміло. Давайте перейдемо до практики і подивимося, як це працює.

Відкрию я минулої лабораторну роботу по DHCP і злегка її модернизирую.


Прибрав я HTTP-сервер і замість нього додав комп'ютер робочого, і назвав WORKER-PC. Присвою йому IP-адресу, який був у HTTP-сервера. Тобто 192.168.1.2. Старий комп'ютер перейменував у DIRECTOR-PC. DNS-сервер я залишив. Він нам у цій лабі ще знадобиться. Сервер DHCP перейменував в Mail-Server. І давайте його налаштуємо.


Адресу я не міняв, і він залишився від минулого лаби. Нехай таким і залишається. Переходимо до служби і знаходимо «EMAIL».


1) В полі «Domain Name» треба записати ім'я домену. Це те, що буде писатися після знака "@". Обов'язкова вимога. Будь-яка пошта записується в такому форматі — логін@домен. І натискаємо кнопку «Set». Я її вже натиснув, тому вона не активна, але якщо внести зміни в поле вводу доменного імені, то вона знову стане активною.

2) І створимо користувачів. В поле «User» запишемо першого користувача. Це буде «Director». І задамо пароль «123». І натискаємо на знак "+", щоб додати його в базу. Аналогічно створимо другого користувача. Це буде «Worker» з таким же паролем «123».

Створення користувачів закінчено, і спостерігаємо наступну картину.


1) Бачимо в базі список створених користувачів. Їх можна видаляти, додавати і змінювати паролі за допомогою кнопок праворуч.
2) Не забуваємо включити служби POP3 і SMTP. Вони за замовчуванням включені, але перевірка зайвою не буде.

На цьому налаштування на стороні сервера закінчується, і тепер перейдемо до налаштування на стороні клієнтів. Почнемо з комп'ютера директора. Відкриваємо вкладку «Desktop» і вибираємо Email.


Після цього відразу відкриється вікно налаштування.


1) В полі «Your Name» пишемо будь-яке ім'я. Я напишу Director.
2) В полі «Email Address» пишемо поштову скриньку. Для директора — це director@cisadmin.ru.
3) У поля «Incoming Mail Server» і «Outgoing Mail Server» записуємо адресу поштового сервера (192.168.1.4)
4) У поле «User Name» пишемо сам логін. Тобто Director і відповідно пароль 123.
Натискаємо кнопку «Save», і перед нами відкривається поштовий клієнт. CPT назвав його поштовим браузером.



Аналогічна установка на комп'ютері робітника. Наводжу скрін.



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

Відкриваємо поштовий клієнт на комп'ютері директора і створимо лист.


Тиснемо на кнопку «Compose», і перед нами відкривається звичне вікно.


Тут все як зазвичай. Пишемо кому відправляємо, тему листа, сам текст листа і натискаємо кнопку «Send».


Бачимо наступне повідомлення про те, що відправка завершена успішно. Чудово! Тепер подивимося, як лист буде доставлено робітникові.

Відкриваємо поштовий клієнт на комп'ютері робітника.


І бачимо, що листа немає. А все тому, що клієнт в CPT не підтримує автоматичне оновлення і доводиться це робити вручну. Натискаємо кнопку «Receive».


Бачимо з'явилося лист і повідомлення про успішне отримання. Відкриємо лист і подивимося, не побилося.


І так, лист, дійсно, дійшло цілим і неушкодженим. Відповімо на цей лист і заодно перевіримо, що листи ходять в обидві сторони. Я натискаю кнопку «Reply» і пишу відповідь.


Відправляю лист і переходжу до комп'ютера директора. І, відповідно, тисну кнопку «Reply», щоб оновити пошту.


З'явився лист, а нижче і повідомлення про успішне отримання.

Відкриваємо лист, щоб до кінця упевнитися.


Лист дійшов, а значить все працює.

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


Як я говорив раніше, все поштові протоколи працюють з TCP. А це значить, що перед тим, як почне працювати поштовий протокол, а в даному випадку протокол SMTP, має встановитися попереднє з'єднання між комп'ютером і сервером. Це ми зараз і спостерігаємо.

Зараз процес встановлення з'єднання нас мало цікавить. Ми зараз говоримо про поштові протоколи, і тому я пропущу цей процес і буду чекати появи SMTP.


1) З'явився довгоочікуваний SMTP, про що свідчить запис в панелі симуляції, і відкриємо їх. Звернемо увагу на TCP-порти, щоб упевнитися, що це він. І бачимо, що в «Destination Port» коштує 25 номер. А в «Source Port» записаний динамічно придуманий порт, щоб сервер міг ідентифікувати клієнта. Все правильно.

2) Дивимося нижче на дані SMTP, і тут немає нічого цікавого. CPT показує нам його, як звичайний блок даних.

Далі він передає ці дані серверу. Подивимося, що буде відбуватися далі.


Сервер, отримавши дані від комп'ютера, формує відповідне повідомлення. Зверніть увагу на зміни. Номери, які були раніше, помінялися місцями, а саме «Source Port» і «Destination Port». Тепер джерелом є сервер, а призначенням — комп'ютер. Це повідомлення про доставку листа сервера.

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


Тепер коли лист відправлено, і ми знаємо, що воно лежить на сервері, спробуємо отримати цей лист. Відкриваємо комп'ютер робочого і тиснемо кнопку «Receive».


Як і з SMTP, POP3 теж створюється TCP-сесія. Подивимося на номери портів. У «Destination Port» коштує 110 номер порту. Це і є стандартний номер порту для протоколу POP3. У «Source Port» варто порт 1028.

Далі дивимося і чекаємо виходу POP3.


От він з'явився і спостерігаємо, що в полі POP3 така ж картина, що і в SMTP, тобто все те, що і так було зрозуміло.

Далі він відправляє запит на сервер і сервер повинен відповісти листом, якщо воно там є.


Ми знаємо, що воно там є і спостерігаємо, як сервер формує відповідне повідомлення. І також як з SMTP, він міняє місцями порти відправлення і призначення. На прикладному рівні запаковані якісь POP3 дані. Це і є сам лист.

Як тільки дані потраплять на комп'ютер, вони одразу повинні висвітитися в поштовому клієнті.


І як тільки дані отримані, про що тут свідчить галочка на фіолетовому пакеті, лист відразу ж висвічується в клієнті. Далі, як і в SMTP, буде закриття TCP-сесії.

Наводжу посилання на скачування цієї лаби.

І ще, що я хотів би показати на додаток до поштових протоколів — це роль 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-сервера в мережі.

Розібрали ми поштові протоколи. І переходимо до розгляду наступного протоколу.

VI) Telnet (від англ. terminal network). Якщо перекладати дослівно, то це мережевий термінал. Основи цього протоколу були закладені давним давно, і до цих пір він не втрачає своєї актуальності. Застосовується він для відображення текстового інтерфейсу, а також для управління ОС. Дуже корисний протокол, і кожен мережевий інженер зобов'язаний вміти працювати з ним. Поясню чому. Кожен мережевий пристрій, інтерфейс якого представляє собою командний рядок, налаштовується або за допомогою спеціального консольного кабелю, або через віртуальні термінали, в який і входить протокол Telnet. І, якщо консольний кабель вимагає знаходження спеціаліста поруч з налаштованим обладнанням, то настройка за допомогою віртуальних терміналів, а в даному випадку Telnet, не обмежує фахівця у відстані. Можна знаходитися в іншій кімнаті, будівлі, місті і все одно мати можливість доступу до обладнання. Я вважаю це величезним плюсом. З мінусів даного протоколу зазначу, що він фактично не захищений і все передається у відкритому вигляді. Використовує він 23 порт. А найбільш популярні дистрибутиви, які працюють з цим протоколом — це Putty, Kitty, XShell і т. д. Я думаю закріпимо його роботу на практиці.

Використовувати Telnet ми будемо для доступу до комутатора Cisco 2960. Він, як і всі Cisco пристрою, що використовує розроблену компанією Cisco операційну систему IOS. А інтерфейс командного рядка називається CLI (Command Line Interface). Давайте для початку налаштуємо комутатор. Повісимо на нього IP-адресу, так як без нього ми не зможемо потрапити на комутатор і розв'яжемо доступ Telnet. Я не буду приводити скріншоти, так як там немає графіки. Просто дам список введених команд і поясню для чого вони.

Switch>enable — перехід в привілейований режим. Звідси доступно більшість команд.

Switch#configure terminal перехід в режим глобальної конфігурації. У цьому режимі можливе введення
команд, що дозволяють конфігурувати загальні характеристики системи. З режиму глобальної конфігурації можна перейти в безліч режимів конфігурації, специфічних для
конкретного протоколу або функції.


Switch(config)#username admin secret cisco створюємо користувача з ім'ям admin і паролем cisco.

Switch(config)#interface vlan 1 переходимо у віртуальний інтерфейс і повісимо на нього IP-адресу. Тут принадність полягає в тому, що не важливо, на якому саме з 24-х портів він буде висіти. Нам головне, щоб просто з будь-якого порту був доступ до нього.

Switch(config-if)#ip address 192.168.1.254 255.255.255.0 — присвоюємо останній адреса 192.168.1.254 з маскою 255.255.255.0

Switch(config-if)#no shutdown — за замовчуванням інтерфейс вимкнений, тому включаємо його. У IOS 90% команд скасовуються або вимикаються шляхом приписування перед командою «no».

Switch(config)#line vty 0 15 переходимо в налаштування віртуальних ліній, де живе Telnet. Від 0 до 15 означає, що застосовуємо це для всіх ліній. Всього можна встановити на ньому до 16 одночасних з'єднань.

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

Switch(config-line)#login local вказуємо, що обліковий запис локальна, і він буде перевіряти її з тією, що ми створили.

Switch#copy running-config startup-config — обов'язково зберігаємо конфігурацію. Інакше після перезавантаження комутатора всі скинеться.

Отже комутатор налаштований. Давайте підключимося до нього з робочого комп'ютера. Відкриваємо " командний рядок. Ми її відкривали, коли розглядали nslookup. І пишемо наступне.


Тобто команда telnet і адресу, куди під'єднатися.

Якщо все вірно, то відкривається наступне вікно із запитом логіна і пароля.


Відповідно пишемо логін:admin пароль:cisco (ми створювали його на комутаторі).

І він відразу пускає нас на комутатор. Для перевірки перевіримо доступність комп'ютера директора, за допомогою команди ping.


Ping успішний. Сподіваюся, зрозуміло, що перевірка доступності здійснюється не з робочого комп'ютера, а з комутатора. Комп'ютер тут є керуючим пристроєм і все. Розглядати його в режимі симуляції я не буду. Він працює точно так само, як і поштові протоколи, тобто створюється TCP-сесія, і, після встановлення з'єднання, починає працювати Telnet. Як тільки він відпрацьовує, він починає розривати з'єднання. Тут все просто. Наводжу посилання на скачування.

Тепер Давайте розберемо протокол SSH.

VII) SSH (англ. Secure Shell). В перекладі з англійської — безпечна оболонка. Як і Telnet дозволяє управляти ОС. Відмінність його в тому, що він шифрує весь трафік і передаються паролі. Шифрується за допомогою алгоритму Диффи-Хеллмана. Кому цікаво почитайте. Практично всі сучасні ОС системи вміють працювати з цим протоколом. Якщо у вас стоїть вибір, який протокол застосовувати, то використовуйте SSH. Спочатку трохи помучаетесь в налаштуванні, і багато чого буде незрозуміло, але з часом в голові вляжеться. Головне запам'ятайте, що найголовніше відміну SSH від Telnet — це те, що SSH шифрує трафік, а Telnet немає. Я думаю пора перейти до практики і подивитися, як це працює. Підключатися і ми будемо управляти тим же комутатором. Давайте спробуємо підключитися по SSH з комп'ютера директора до комутатора.


Тут синтаксис команди трохи інший, ніж при підключенні за Telnet. Пишемо ssh з ключем l, після набираємо логін (у нас це admin) і адресу, куди підключаємося (192.168.1.254). Завершуємо цю справу клавішею ENTER. Видається повідомлення, що з'єднання було закрито зовнішнім хостом. Тобто комутатор закрив з'єднання. Все тому, що не були створені ключі, які працюють з шифруванням. Зайду на комутатор і настрою його для коректної роботи по SSH.

Switch(config)#hostname SW1 — міняємо ім'я комутатора. З цим стандартним ім'ям не можна прописати домен, який потрібен для генерації ключів.

SW1(config)#ip domain-name cisadmin.ru — прописуємо домен.

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 і перевірю доступність робочого комп'ютера.


І переконався, що все чудово працює. Наводжу посилання, щоб переконалися і ви.

А я переходжу до наступного протоколу.

VIII) FTP (англ. File Transfer Protocol). Протокол передачі файлів. Думаю з назви протоколу ясно, що він передає файли. Дуже древній протокол, який вийшов на початку 70-х років. З'явився він ще до HTTP і стека TCP/IP. Як працював раніше, так і зараз працює з «клієнт-сервер» моделі. Тобто, є ініціатор з'єднання і той, хто його слухає. Є кілька модифікацій, які підтримують шифрування, тунелювання і так далі. Раніше з цим протоколом працювали різні консольні утиліти, у яких не було графіки і працювали вони, за допомогою введення певних команд. В нинішній час присутні та графічні програми. Самою популярною і простий є Filezilla. У CPT реалізований тільки консольний метод.

Переходимо до практики. За основу я візьму попередню лабораторку і поштовий сервер заміню FTP-сервером.


В принципі схема аналогічна попередній.

Відкриємо FTP-сервер і перейдемо в сервіс FTP.


За замовчуванням служба включена, але краще перевірити.

1) Цифрою 1 я зазначив учетку, яка за замовчуванням була тут створена. Це стандартна обліковий запис з логіном «cisco» і таким же паролем. В правій колонці бачимо «Permission» — це права доступу. І бачимо, що дана учетка має всі права. В середовищі нам якраз це і треба, але, працюючи в компанії, завжди стежте за правами кожної закладки.

2) Цифрою 2 зазначено сховище FTP. Тут в основному прошивки для цисковских пристроїв.

Сервіс налаштований і раз все так прекрасно, спробуємо з ним попрацювати. Але для початку створю текстовий файл на комп'ютері директора, який потім выкачаю на FTP-сервер.

Відкриваю комп'ютер директора і вибираю «Text Editor». Це аналог блокнота Windows.


Напишу туди текст і збережу його.



Тепер спробуємо залити файл на FTP-сервер. Відкриваємо " командний рядок і пишемо


Тобто, як пам'ятаємо, на початку пишеться використовуваний протокол, а потім слід адресу. Далі, після з'єднання, питається логін (вводимо cisco) і пароль (теж cisco). І після аутентифікації потрапляємо на сам FTP-сервер. Список доступних команд можна перевірити командою "?".

Щоб щось залити, використовується команда «put», а скачати команда «get». Заливаємо наш файл.


Ввів я команду «put» і назву файлу, яке хочу скопіювати. І він показує нам повідомлення, що все скопійовано. Файл важить 20 байтів, а швидкість передачі 487 байт в секунду. Далі ввів команду dir, щоб перевірити вміст сервера. І засвітився на ньому файл message.txt під 17 номером.

Залишилася справа за малим. Це завантажити файл на комп'ютер робітника. Відкриваю я WORKER-PC і заходжу в командний рядок.


Виконую я практично ті ж дії, що і раніше. За винятком команди «get», а не «put». Бачимо, що файл скачав. Ще я ввів команду «dir», щоб показати, що при скачуванні файлу, оригінал не видаляється. Скачується його копія.

І раз він завантажив файл, то він повинен з'явитися на комп'ютері. Відкриваю «Text Editor» і натискаю File->Open.



Бачу, що файл дійсно присутній і пробую його відкрити.


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

Не буду повторно засмічувати вам голову, як це працює. Тому що працює вона точно так само, як і поштові протоколи, Telnet, SSH і так далі. Тобто створюється TCP-сесія, і починається передача/скачування файлу. Наведу тільки його структуру.


В TCP звертаємо увагу на номер порту. Це 21 порт (стандартний порт FTP). І в полі даних FTP позначено, що це якісь двійкові дані.

Ось так в принципі працює всесвітньо відомий протокол. Більш розширені версії тут не підтримуються, але працюють вони практично так само. Ось посилання на лабораторку.

І останній протокол, який залишився — це TFTP.

IX) TFTP (англ. Trivial File Transfer Protocol). Простий протокол передачі файлів. Придумали його в 80-х роках. Хоч FTP був досить популярним, не всі його функції були потрібні для вирішення простих завдань. І був придуманий його простий аналог. Він працює по UDP, тобто не вимагає встановлення з'єднання. Також він не вимагає автентифікації та авторизації. Достатньо знати його IP-адресу і самому його мати. Це звичайно не безпечно, так як адресу можна підробити. Але коли потрібен простий протокол і не потрібна авторизація, вибір падає на нього. Дуже щільно з ним працює цисковское обладнання, для копіювання образу або скачування на flash-пам'ять.

Ніщо не вчить краще, ніж практика. Тому переходимо до неї. Дивним чином я виявив, що комп'ютери в CPT не вміють працювати з TFTP. Добре, що з цисковского обладнання не випиляли цю функцію. Тому будемо вчитися на нашому улюбленому комутаторі. Схема залишається такою ж. Просто на FTP-сервері я включу сервіс TFTP.


Ось так він виглядає. В базі купа різних прошивок для багатьох пристроїв.

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

SW1#dir — команда виведення вмісту файлової системи
Directory of flash/

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

64016384 total bytes (59600295 bytes free)

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

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)

І в заключному повідомленні він показує, що всі успішно скопировалось. Перейдемо на TFTP-сервер і перевіримо.


І бачу, що дійсно він там присутній. Значить комутатор мене не обдурив.

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

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)

Видав він мені повідомлення, що завантаження пройшла успішно. Перевірю я наявність прошивки командою «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 total bytes (54929840 bytes free)

Бачу, що дійсно все на місці. І до того ж він мені повідомляє про обсяг пам'яті і наявності вільного місця.

Закінчили ми розглядати протоколи верхнього рівня. Не думав я, що вийде настільки довга стаття. Напевно винні картинки. Але постарався максимально коротко і по справі. Протоколів ми розглянули багато, і всі вони не замінні. Часто виручають життя сисадмінам і улюбленим нами користувачам. Спасибі, що дочитали. Якщо щось незрозуміло, залишайте коментарі або відразу пишіть в лічку. А я пішов ставити чайник і пити смачний чай з тістечками!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.