Как работают компьютерные сети

Оглавление: Компьютерные сети

1. Как работают компьютерные сети

1.1 Понятно о компьютерных сетях

1.2 Зачем нужен DNS

1.3 HTTP протокол

1.4 Зачем нужен TCP

1.5 Канальный уровень (data link) – передача данных с устройства на устройство

1.6 IP протокол

1.7 NAT

1.8 TCP/IP или OSI

1.9 Заключение

2. IP адрес

3. IPv6 адрес

4. HTTP протокол

5. Транспортные протоколы TCP и UDP

6. Канальный уровень передачи данных

7. Маршрутизация данных

8. Служебный протокол ICMP

9. DNS

10. Настройка сетевых подключений в командной строке Linux

11. Определение проблем работы сети

12. Туннелизация

Понятно о компьютерных сетях

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

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

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

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

Зачем нужен DNS

Допустим, мы ввели в адресною строку браузера «hackware.ru» и нажали ENTER. Через долю секунды увидели страницу. Вроде бы, всё просто. Но начнём с того, что браузер ничего не знает о сайте hackware.ru. Он даже не знает IP адрес сайта. Итак, веб-браузер начинает с того, что делает DNS запрос к серверу имён. Этот сервер знает IP адреса всех сайтов. Но чтобы отправить запрос, нужен транспортный протокол. В качестве такого протокола используется UDP. Особенностью этого протокола является то, что передаваемые пакеты не проверяются на ошибки, которые могли возникнуть во время передачи. То есть если пакет испортился в пути, то он просто теряется. Получается, это ненадёжный протокол, зато быстрый. Это подходит для ситуации, когда нужно послать один единственный запрос и быстро получить по нему ответ.

HTTP протокол

Итак, веб-браузер получил ответ на свой DNS запрос, теперь он знает IP адрес сервера, где расположен сайт. Можно делать запрос. В дело вступает протокол HTTP (сознательно пропустим HTTPS и HSTS, чтобы не загромождать обзорный пример). HTTP – это самый простой для понимания протокол, веб браузер отправляет примерно следующие строки:

> GET / HTTP/2
> Host: hackware.ru
> user-agent: curl/7.88.1
> accept: */*

Обратите внимание, что в заголовке «Host:» передаётся имя сайта. Дело в том, что знание IP недостаточно. На одном сервере может быть множество сайтов. Поэтому когда браузер обращается к веб-серверу, с просьбой показать сайт, то он должен указать, какой именно сайт ему нужен. В этих строках GET показывает используемый метод HTTP протокола (также может быть POST или HEAD). HTTP/2 — это номер версии протокола. А «/» — это запрашиваемая страница, здесь может быть, допустим /?p=21, если бы я запросил страницу hackware.ru/?p=21. В строках выше запрашивается корневая папка, то есть будет показана индексная страница по умолчанию. Таким образом, отправленный запрос hackware.ru/ будет обработан как hackware.ru/index.php

Сервер отвечает примерно так:

< HTTP/2 200 
< server: nginx
< content-type: text/html;charset=utf-8
< vary: Accept-Encoding
< x-powered-by: PHP/7.2.34
< date: Thu, 09 Mar 2023 03:32:14 GMT
< x-page-speed: 1.13.35.2-0
< cache-control: max-age=0, no-cache, s-maxage=300

А затем идёт исходный код запрашиваемой страницы.

Зачем нужен TCP

Показанные строки HTTP протокола не могут быть просто так доставлены на сервер. Нужен «носитель». В качестве аналогии приведём пример с бумажным письмом: вы хотите написать письмо со словами: «Мама, у меня всё хорошо. Люблю тебя. Вышли ещё денег». В этом примере слова – это как бы протокол HTTP – так и веб-браузер говорит, «покажи мне страницу сайта hackware.ru». Но чтобы можно было бы отправить слова в письме к маме, они должны быть записаны на бумагу. Так и для протокола HTTP роль «бумаги» выполняет транспортный протокол TCP. Мы уже знакомы с транспортным протоколом UDP – это быстрый, но ненадёжный протокол. Тем не менее, он годится, когда вся передаваемая информация помещается в одном пакете. Но для больших данных, которые разбиваются на большое количество пакетов, это не подходит. TCP не только передаёт информацию, но и следит, чтобы пакеты не потерялись или не испортились. Если произошла потеря пакета, то взамен него отправляется ещё один точно такой же. Это надёжно, но за эту надёжность приходится «платить» тем, что для обеспечения этой надёжности пересылается много данных, которые нужны только для «обслуживания», то есть они не несут полезной ценности.

Итак, наш веб-сервер знает куда отправлять (узнал IP с помощью DNS запроса), знает что отправлять и уже даже запаковал HTTP запрос в TCP пакеты. TCP пакет состоит из передаваемых данных и заголовков. В этих заголовках разнообразная информация, в том числе, там содержится IP адрес пункта назначения и IP откуда этот пакет отправляется. Теперь веб-браузер просит операционную систему отправить для него эти TCP пакеты.

Канальный уровень (data link) – передача данных с устройства на устройство

Операционная система не имеет ничего против. Но есть одна загвоздка: TCP пакеты нельзя просто передать по сети. Как если бы вы своё письмо маме написали на бумаге и пришли на почту отправлять – первое, что вас попросят, это запечатать ваше письмо в конверт. Таким конвертом для TCP пакетов в локальной сети являются Ethernet кадры. Вот уже Ethernet можно передавать на сетевой интерфейс.

Но тут же мы сталкиваемся со следующей загвоздкой: Ethernet кадры в качестве адреса получателя и отправителя используют MAC-адреса. Имя сайта мы знаем, IP адрес знаем, даже знаем страницу, которую запросил пользователь, а вот MAC-адреса у нас нет…

И дело здесь не в какой-то прихоти. Мы подходим к моменту, когда данные будут переданы с устройства на другое устройство. Чтобы это сделать, нужно знать физический адрес этого другого устройства – тот самый MAC-адрес.

Допустим, нужно отправить TCP пакеты на IP адрес 192.168.0.175. Операционная система начинает с того, что определяет, принадлежит ли запрашиваемый IP к локальной сети или нет. Если принадлежит к локальной сети, то она смотрит в ARP таблицу, есть ли там информация об 192.168.0.175:

Если есть, то она смотрит MAC адрес устройства, у которого IP 192.168.0.175. Пакет TCP заворачивается в Ethernet кадр, в этом кадре есть область с теми самыми данными, которые нужно передать, а также есть заголовок, в этом заголовке сказано для какого MAC-адреса предназначается пакет и какой MAC-адрес у отправителя. Ethernet кадр отправляется на сетевой интерфейс. Пока не будем следовать за ним, а рассмотрим другие варианты.

Если нужный IP не найден в ARP таблице, то по локальной сети делается широковещательный запрос «у кого IP 192.168.0.175?». В ответ устройство с IP 192.168.0.175 присылает свой MAC-адрес. Когда приходит ответ, полученный MAC добавляется в ARP таблицу (а вдруг ещё пригодится) и делается уже знакомый нам Ethernet кадр, который отправляется на сетевой интерфейс.

Если же IP, куда нужно отправить TCP пакет, не в локальной сети, то операционная система смотрит адрес шлюза по умолчанию. На этот шлюз отправляются все пакеты, которые не принадлежат к локальной сети и для которых не прописаны специальные маршруты. Так вот, операционная система смотрит IP шлюза по умолчанию, затем ищет этот IP в ARP таблице – получает MAC-адрес шлюза по умолчанию. После этого TCP пакет заворачивается в Ethernet кадр.

Напомню, мы ещё только пытаемся отправить первый TCP пакет нашего запроса к веб-серверу…

Итак, наконец-то Ethernet кадр попал в локальную сеть. Если его встречает свитч (устройство, которое вообще не понимает IP адреса, да и которому это не нужно) – оно смотрит на MAC-получателя и перенаправляет Ethernet кадр в сторону получателя. Допустим, что веб-сервер не в нашей локальной сети, тогда наш путешественник Ethernet кадр в конечном счёте попадает на роутер. Первое, что делает роутер, это разворачивает Ethernet кадр, то есть достаёт из него TCP пакет.

IP протокол

Роутер смотрит на IP адрес получателя. У роутера есть своя таблица маршрутизации, а также свой маршрут по умолчанию. Если этот TCP пакет не предназначен ни для кого в локальной сети, то роутер просто отправляет его по маршруту по умолчанию, то есть по проводу, который идёт к Интернет-провайдеру.

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

Итак, наш TCP пакет дошёл до Интернет-провайдера. Казалось бы – уже столько всего с ним приключилось, но путь TCP пакета только начался. Теперь он пропутешествует по нескольким сетям и всё-таки доберётся до веб-сервера. Каждая сеть подключена к нескольким другим сетям. И может быть множество путей для достижения конечной точки. Например, я отправил TCP пакет из Владимирской области и пунктом его назначения является, сервер в Санкт-Петербурге. Пакет может пройти кратчайшим путём по смежным сетям, а может сначала отправится в Северную Америку, затем в Южную Америку, затем в Австралию и затем к серверу в Санкт-Петербурге. Чтобы второй вариант не происходил, разработаны для составления кратчайших маршрутов сразу несколько протоколов – это отдельная тема, которую мы не будем затрагивать.

NAT

Наши TCP пакеты успешно дошли до получателя. Получатель развернул их и достал оттуда HTTP запрос – а в запросе сказано, что нужно показать веб-страницу сайта hackware.ru. Веб-сервер формирует ответ: составляет заголовок HTTP протокола и веб-страницу и также разбивает эти данные по TCP пакетам. В TCP пакете пишутся IP адреса отправителя и получателя. Веб-сервер формирует ответ в виде заголовков HTTP протокола или данных, «пишет» их в TCP пакеты, у которых в качестве IP адреса отправителя указан адрес сервера, а в качестве IP адреса получателя тот IP, откуда пришли пакеты.

У моего компьютера IP адрес 192.168.0.49. Это локальный адрес, и к нему можно отправлять данные только в пределах моей домашней сети. Если бы на веб-сервер пришёл TCP пакет с таким IP, то веб-сервер не смог бы передать на него данные. Наш домашний роутер об этом знает и позаботился о проблеме заранее – для этого он использует NAT, то есть Network Address Translation — «преобразование сетевых адресов».

Схема работы NAT следующая: роутеру приходит сетевой пакет, допустим, от компьютера с IP 192.168.0.49. Сетевой пакет содержит разные данные, в том числе IP пункта назначения (куда пакет отправляется) и IP куда нужно вернуть ответ, то есть в нашем примере это 192.168.0.49. Но проблема в том, что 192.168.0.49 – это локальный IP. Тогда роутер заменяет адрес, куда нужно вернуть пакет: вместо 192.168.0.49 записывает свой внешний IP, допустим 109.126.241.24. Также роутер рассчитывает новую контрольную сумму пакета (с помощью неё проверяется, что пакет не был повреждён при передаче) и в таком виде отправляет его в Интернет. При этом соединение открыто и роутер ждёт ответ – всё это время роутер держит в уме, что конкретно данное соединение для 192.168.0.49. Когда приходит ответ, в котором в качестве пункта назначения указан IP адрес роутера, роутер знает, что этот пакет предназначен не ему, поэтому он меняет в нём адрес назначения на 192.168.0.49 и сразу отправляет адресату.

На самом деле всё чуть сложнее — у роутера не всегда белый IP, который доступен из Интернета. Роутер может быть подключён к локальной сети Интернет-провайдера. Если это так, то вновь используется NAT. То есть один пакет может пройти через несколько NAT (через несколько локальных сетей).

TCP/IP или OSI

На уровне передачи данных от устройства к устройству (он называется канальный (data link)) используются разные протоколы, к примеру, PPP, IEEE 802.22, Ethernet, DSL, ARP. На транспортном уровне тоже много протоколов, мы коснулись TCP, UDP – но их намного больше. Имеется множество сетевых протоколов, для их систематизации разработана система уровней. Причём таких систем много, две доминирующие: TCP/IP и Сетевая модель OSI. У них есть общие уровни, но TCP/IP выделяет 4 уровня, а OSI – 7.

На практике стандарты, введенные для OSI и TCP/IP, не столько конкурируют, сколько дополняют друг друга. В результате получила распространение пятислойная гибридная архитектура.

Будем основываться на Гибридной модели, поскольку она в большей степени соответствует практике:

• Уровень приложения: обрабатывает связи между приложениями (например, веб-браузер и веб-серверные программы, почтовые клиентские и серверные программы).
• Транспортный уровень: выполняет соединение от точки к точке (или от хоста к хосту) и поддерживает его надежность.
• Межсетевой уровень. Проводит межсетевые подключения в подсетях.
• Уровень канала передачи данных: обеспечивает внутрисетевое взаимодействие внутри подсети.
• Физический уровень: физически передает данные/сообщения между сетевыми узлами.

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

Заключение

Итак, как вы увидели, компьютерные сети – это очень тонко настроенный механизм, в котором всё продумано и всё учтено. Это очень интересная тема!

Даже в описанном процессе пропущены некоторые протоколы, который задействуются при самом обычном Интернет-сёрфинге.

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