vault backup: 2026-05-14 10:49:10
This commit is contained in:
Dmitry
@@ -0,0 +1,78 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- arp
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: ARP
|
||||
---
|
||||
|
||||
# ARP
|
||||
## Адресация
|
||||
|
||||
Адреса L2 используются для связи устройств, связанных напрямую в локальной сети. Адреса же L3 для связи устройств, подключенных косвенно в межсетевой среде.
|
||||
|
||||
Сети используют адресацию для идентификации и группировки устройств для успешной передачи данных. Протокол [[Ethernet]] использует MAC-адреса, привязанные к сетевой карте устройства.
|
||||
|
||||
Для общения устройств, находящихся в разных сетях, необходимо установить соответствие IP и MAC адресов. Для этого используются протоколы ARP:
|
||||
|
||||
1. ARP - Address Resolution Protocol
|
||||
2. Reverse ARP (RARP)
|
||||
3. Serial Line ARP (SLARP)
|
||||
4. Inverce ARP (InARP)
|
||||
|
||||
## Address Resolution Protocol
|
||||
|
||||
Для передачи данных на L3 ARP необходим для сопоставления IP с MAC для отправки IP-пакетов. Перед отправкой, устройство обратится к своему кешу ARP, где хранятся все сопоставления IP и MAC для того, чтобы узнать, есть ли там соответствие. Если же записи нет, то оно отправляет _широковещательный_ пакет каждому устройство в сети, чтобы узнать, кому принадлежит соответствующий IP адрес. Устройства сами сравнивают запрашиваемый IP со своим и, при совпадении, нужное устройство отправляет в ответ свой MAC-адрес. Исходное устройство добавляет эту информацию в свою таблицу ARP для дальнейшего использования.
|
||||
|
||||
|
||||
|
||||
Если устройство назначения находится в удаленной сети, то устройства L3 отправляют один за одним ARP-запрос для MAC-адреса шлюза по умолчанию (192.168.0.1, например).
|
||||
|
||||
> Шлюз - это устройство, куда направляется пакет, если для отправителя получатель неизвестен.
|
||||
|
||||
Далее шлюз смотрит по IP-адресу, ищет нужную сеть и отправляет на устройство L3 соответствующей сети.
|
||||
|
||||
## Кэширование ARP
|
||||
|
||||
Т.к. сопоставление IP и MAC адресов происходит на каждом "хопе" в сети для каждого пакета, производительность сети может быть снижена огромным количеством запросов. Для эффективного использования ресурсов сети, применяется кэширование протокола ARP.
|
||||
|
||||
Кэш ARP - это способ хранения таблицы соответствия IP и MAC адресов. Запиши кэша должны обновляться для поддержания актуальности. Каждое устройство обновляет свои таблицы по мере передачи адресов.
|
||||
|
||||
## Статические И Динамические Записи В Кэше ARP
|
||||
|
||||
Существуют записи статического и динамического ARP-кэша. Статические записи - это вручную проставленные записи соответствия, они сохраняются на постоянной основе. Динамические выставляются сами и могут обновляться по мере необходимости.
|
||||
|
||||
Для статической маршрутизации, администратор должен вручную вводить IP-адрес, маски подсети, шлюзы, соответствующий MAC-адрес. Статика обеспечивает больший контроль, но создает дополнительную работу при поддержании.
|
||||
|
||||
## Устройства, Не Использующие ARP
|
||||
|
||||
Когда сеть делится на два сегмента, устройство под названием _мост_ (bridge) соединяет сегменты и фильтрует трафик на каждый сегмент на основе MAC-адресов. Мост создает собственную таблицу, использующую только MAC, в отличие от маршрутизатора, который имеет кэш ARP, который содержит как IP-адреса, так и соответствующие MAC-адреса.
|
||||
|
||||
Пассивные хабы - это устройства L1, работа которых заключается в пересылке всех пакетов, полученных на один порт, на все основные порты. Нет необходимости в таблице адресов.
|
||||
|
||||
## Inverce ARP
|
||||
|
||||
Вместо использования адреса уровня 3 (IP-адреса) для поиска MAC-адреса, Inverse ARP использует MAC-адрес для поиска IP-адреса. Как следует из названия, InARP - это просто противоположность ARP. Обратный ARP был заменен более поздними версиями DHCP, но обратный ARP используется исключительно для настройки устройства. Обратный ARP включен по умолчанию в сетях ATM (Asynchronous Transfer Mode)
|
||||
|
||||
> ATM (Asynchronous Transfer Mode) — это сетевая технология передачи данных, которая используется для передачи информации в виде небольших фиксированных ячеек размером 53 байта.
|
||||
|
||||
## Reverse ARP
|
||||
|
||||
Reverse ARP (RARP) - работает так же, как и протокол ARP, но целью является запрос IP-адреса, исходя из MAC-адреса устройства. Используется бездисковыми устройства, не имеющим возможности хранить свой IP на постоянной основе.
|
||||
|
||||
## Proxy ARP
|
||||
|
||||
Если два устройства находятся в разных сегментах сети, например, подключены к разным коммутаторам, которые, в свою очередь, подключены к одному маршрутизатору, то получается ситуация, при которой они не могут друг друга увидеть, т.к. маршрутизатор не передает широковещательный запрос ARP (для поиска MAC по IP). В таком случае, маршрутизатор становится "соседом" для каждого устройства, передавая отправителю свой MAC, как ответ, а отправитель отправляет данные на маршрутизатор, а тот уже пересылает нужному устройству в другом сегменте.
|
||||
|
||||
Proxy ARP вызывается следующими условиями:
|
||||
|
||||
- IP-адрес назначения не находится в той же физической сети (LAN), на которой получен запрос.
|
||||
- Сетевое устройство имеет один или несколько маршрутов к IP-адресу назначения.
|
||||
- Все маршруты к IP-адресу назначения проходят через интерфейсы, отличные от тех, на которых получен запрос.
|
||||
|
||||
Когда proxy ARP отключен, устройство отвечает на запросы ARP, полученные на его интерфейсе, только если IP-адрес назначения совпадает с его IP-адресом или если целевой IP-адрес в ARP-запросе имеет статически настроенный псевдоним ARP.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- dhcp
|
||||
created: 2025-12-22
|
||||
updated: 2026-05-07
|
||||
title: DHCP-snooping
|
||||
---
|
||||
|
||||
# DHCP-snooping
|
||||
DHCP-snooping - функция коммутатора, предназначенная для защиты от атак с использованием протокола DHCP.
|
||||
|
||||
Например, атаки с подменой **DHCP**-сервера в сети или атаки **DHCP** starvation, которая заставляет **DHCP**-сервер выдать все существующие на сервере адреса злоумышленнику.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- dhcp
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: DHCP
|
||||
---
|
||||
|
||||
# DHCP
|
||||
DHCP - **Dynamic Host Configuration Protocol**
|
||||
|
||||
При простой конфигурации сети (устройств мало и они не изменяются), сетевой администратор может спокойно сам прописать всем устройствам статичный IP и это нормально.
|
||||
|
||||
Но если в сети есть мобильные клиенты или устройства постоянно то приходят, то уходят, то задача становится весьма трудоемкой. Для решения это проблемы существует протокол DHCP, позволяющий удобно управлять распределением адресов в сети.
|
||||
|
||||
Существует 3 механизма работы DHCP:
|
||||
|
||||
1. Manual Allocation (Ручное распределение) - администратор предварительно настраивает IPv4 адрес клиенту, а сервер его автоматически передает.
|
||||
2. Automatic Allocation (Автоматическое) - Администратор выделяет пул адресов серверу и тот сам распределяет их между клиентами, но нет понятия "аренды" после присвоения этот IP остается с клиентом навсегда.
|
||||
3. Dynamic Allocation (Динамическое распределение) - сервер динамически назначает IP-адреса из выделенного пула на ограниченный срок, после его истечения, устройство должно заново запросить IP. Сервер, как правило, просто продлевает аренду.
|
||||
|
||||
%% Begin Waypoint %%
|
||||
- [[Механизм работы - DHCP]]
|
||||
- [[Настройка DHCP - Cisco]]
|
||||
- [[Настройка DHCP Snooping и DAI]]
|
||||
- [[DHCP-snooping]]
|
||||
- [[Dynamic ARP Inspection]]
|
||||
|
||||
%% End Waypoint %%
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- dhcp
|
||||
- arp
|
||||
created: 2025-12-22
|
||||
updated: 2026-05-07
|
||||
title: Dynamic ARP Inspection
|
||||
---
|
||||
|
||||
# Dynamic ARP Inspection
|
||||
**Dynamic ARP Inspection** — функция коммутатора, предназначенная для защиты от атак с использованием протокола ARP.
|
||||
|
||||
Например, атаки ARP-spoofing, позволяющей перехватывать трафик между узлами, которые расположены в пределах одного широковещательного домена.
|
||||
Данная функция предотвращающая атаку типа **Man-in-The-Middle**. Это такой вид атаки, когда к вашей сети подключается устройство злоумышленника и, например, объявляет, что IP адрес, принадлежащий авторизованному серверу, принадлежит ему. После этого все данные, которые отправляются на сервер переходят через устройство злоумышленника.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- dhcp
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Механизм Работы - DHCP
|
||||
---
|
||||
|
||||
# Механизм Работы - DHCP
|
||||
Получение IP-адреса по механизму DORA (Discovery, Offer, Request, Ack)
|
||||
|
||||
1. dhcpDISCOVER
|
||||
Клиент, у которого нет IP-адреса, отправляет широковещательный запрос (broadcast) в сеть. В нем он сообщает свой MAC-адрес с адресом назначения `255.255.255.255`, и т.к. у клиента ещё нет IP, то отправитель - `0.0.0.0`
|
||||
2. dhcpOFFER
|
||||
После получения запроса, существующий в сети DHCP-сервер резервирует свободный адрес из пула и создает ARP запись (сопоставление MAC и IP) и отправляет на `0.0.0.0` "предложение" клиенту с этим IP.
|
||||
3. dhcpREQUEST
|
||||
Ответ клиента уже с полученным IP, если DHCP-серверов несколько, то ответ также широковещательный.
|
||||
Используется request также и для продления.
|
||||
4. dhcpACK
|
||||
Сервер отправляет "подтверждение принятия" клиентом адреса и окончательно фиксирует аренду.
|
||||
|
||||
|
||||
|
||||
При истечении аренды IP-адреса, клиент отправляет REQUEST-запрос серверу, который выдал ему адрес для продления, для получения ACK.
|
||||
|
||||
Если сервер не отвечает, то клиент отправляет broadcast-запрос ко всем серверам.
|
||||
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- dhcp
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: Настройка DHCP - Cisco
|
||||
---
|
||||
|
||||
# Настройка DHCP - Cisco
|
||||
|
||||
- **Исключение адресов из пула**
|
||||
|
||||
```text-plain
|
||||
Router(config)# ip dhcp excluded-address 192.168.1.254
|
||||
Router(config)# ip dhcp excluded-address 192.168.1.1 192.168.1.9
|
||||
```
|
||||
|
||||
- **Настройка DHCP-пула**
|
||||
|
||||
```bash
|
||||
Router(config)# ip dhcp pool POOL-1 - создание пула
|
||||
Router(dhcp-config)# network 192.168.1.0 255.255.255.0
|
||||
Router(dhcp-config)# default-router 192.168.1.1
|
||||
|
||||
Router(dhcp-config)# dns-server 192.168.1.2 - dns-сервер
|
||||
Router(dhcp-config)# domain-name merionet.ru - доменное имя
|
||||
Router(dhcp-config)# lease 2 - время аренды
|
||||
|
||||
Router(dhcp-config)# show ip dhcp binding - ARP-таблица
|
||||
```
|
||||
|
||||
- Ретрансляция DHCP (DHCP RELAY)
|
||||
|
||||
```bash
|
||||
Router_2(config)# interface g0/0
|
||||
Router_2(config-if)# ip helper-address 192.168.1.1
|
||||
```
|
||||
|
||||
- Настройка роутера как DHCP-клиента
|
||||
|
||||
```text-plain
|
||||
Router_3(config)# interface g0/0
|
||||
Router_3(config-if)# ip address dhcp
|
||||
```
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
status: seed
|
||||
type: lab
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- dhcp
|
||||
created: 2025-12-22
|
||||
updated: 2026-05-07
|
||||
title: Настройка DHCP Snooping И DAI
|
||||
---
|
||||
|
||||
# Настройка DHCP Snooping И DAI
|
||||
Чтобы включить DHCP Snooping и DAI нужно, для начала, задать доверенные и не доверенные порты. По умолчанию, все порты, к которым подключаются конечные пользователи считаются **не доверенными**.
|
||||
|
||||
```js
|
||||
AccSwitch# conf t
|
||||
AccSwitch(config)#
|
||||
AccSwitch(config)#int ra gi1/0/1-46
|
||||
AccSwitch(config-if-range)#ip dhcp snooping limit rate 15
|
||||
AccSwitch(config-if-range)#ip arp inspection limit rate 100
|
||||
```
|
||||
|
||||
Тут мы задаем количество пакетов, которые должны проходить через не доверенный интерфейс. Обычно такого числа пакетов хватает для получения и обновления IP адреса. Далее настраиваем доверенные интерфейсы:
|
||||
```js
|
||||
AccSwitch(config)#int ra gi1/0/47-48
|
||||
AccSwitch(config-if-range)#ip dhcp snooping trust
|
||||
AccSwitch(config-if-range)#ip arp inspection trust
|
||||
```
|
||||
|
||||
После этого глобально включаем DHCP Snooping, но НЕ ARP Inspection:
|
||||
```js
|
||||
AccSwitch(config)#ip dhcp snooping
|
||||
AccSwitch(config)#ip dhcp snooping vlan 200
|
||||
AccSwitch(config)#no ip dhcp snooping information option
|
||||
```
|
||||
|
||||
Последняя команда отключает опцию 82, которая используется коммутатором в DHCP пакетах, идущих от DHCP клиента через коммутатор к DHCP серверу. Опция 82 содержит информацию об устройстве (например, MAC адрес коммутатора) и информацию о номере порта с которого идет запрос для того, чтобы сервер, опираясь на полученную информацию, смог выдать IP адрес DHCP клиенту из нужной подсети.
|
||||
|
||||
Далее переходим к настройке DAI. Если у вас в сети есть устройства со статическим IP адресом, то нужно как-то сказать коммутатору, чтобы порты, к которым подключены такие устройства не проверялись. Для этого существуют ARP списки доступа. Важно, чтобы название access-list-а было именно DAI. По личному опыту знаю, что в противном случае нужно вводить дополнительные команды. А так все работает без лишних команд.
|
||||
|
||||
```js
|
||||
AccSwitch(config)#
|
||||
AccSwitch(config)# arp access-list DAI
|
||||
AccSwitch(config-arp-nacl)# permit ip host 192.168.200.25 mac host 0017.6111.a309
|
||||
```
|
||||
|
||||
В таком порядке добавляем IP адреса всех устройств со статическим IP. Дополнительно можно настроить Sorce Guard. Этим мы конкретное устройство к порту коммутатора, таким образом другое устройство подключенное к указанному порту не сможет выдать себя за привязанное:
|
||||
|
||||
```js
|
||||
AccSwitch(config)#ip source binding 0017.6111.a309 vlan 200 192.168.200.14 interface Gi1/0/5
|
||||
```
|
||||
|
||||
Также под не доверенными интерфейсами нужно ввести команду _ip verify source_, которые проверяет источник запросов.
|
||||
|
||||
Важно! После всех настроек, приведенных выше, ждем сутки-две чтобы DHCP Snooping таблица заполнилась. В противном случае DAI будет блокировать все запросы, и пользователи не смогут работать в сети. Когда таблица заполнена включаем arp inspection:
|
||||
|
||||
```js
|
||||
AccSwitch(config)#ip arp inspection vlan 200
|
||||
```
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- dns
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: DNS
|
||||
---
|
||||
|
||||
# DNS
|
||||
DNS - Domain Name System Аналог: контактная книга в телефоне (сопоставление ФИО номеру телефона).
|
||||
|
||||
При вводе названия сайта или его доменного имени в поисковую строку браузер обращается к кэшу, если вдруг уже заходили на этот сайт с этого браузера.
|
||||
|
||||
Далее идет обращение к локальному DNS серверу (для ПК это файл `hosts`).
|
||||
|
||||
Если ничего нет, то идет обращение к **resolver** (распознающий). Обычно, это сервер у хостинг-провайдера, но можно задать любой другой.
|
||||
|
||||
Тот ищет записи в своем кэше (если его пользователи часто ищут твой сайт) А если не находит, то идет к корневому **root** серверу, который отвечает за зону `.`.
|
||||
|
||||
Стоит отметить, что все доменные имена, на самом деле, имеют точку в конце адреса: youtube.com. vk.com. mephi.ru. За эту корневую точку и отвечают корневые сервера.
|
||||
|
||||
Тот не говорит IP-адрес, но говорит, кто может "подсказать".
|
||||
|
||||
Он нас пересылает на TLD (Top Level Domain) сервер, который отвечает за свою верхнеуровневую доменную зону. Те делятся на:
|
||||
|
||||
1. gTLD (Generic Top Level Domain) - доменные зоны, не привязанные к стране.
|
||||
- `.edu` - образование
|
||||
- `.com` - коммерческие
|
||||
- `.org` - организации и некомерческие
|
||||
2. ccTLD (Country Code Top Level Domain) - привязанные к стране:
|
||||
- `.ru` - Россия
|
||||
- `.ua` - Украина
|
||||
- `.by` - Беларусь
|
||||
- `.us` - США
|
||||
|
||||
Т.е. после корневого сервера, resolver пойдет к серверу верхнего уровня, но и тот не скажет ему, куда переходить, тот подскажет, к какому _авторитарному_ серверу обратиться.
|
||||
|
||||
Авторитарный сервер или сервер авторитативных имен (_Authoritative nameserver_) - это сервер, отвечающий за конкретный пул адресов, как правило, такими выступают хостинг-провайдеры, которые регистрируют домены. Вот они как раз говорят, какое нужен ip-адрес.
|
||||
|
||||
В терминологии DNS существует 3 вида запросов:
|
||||
|
||||
1. Recursive (рекурсивный) - запрос IP-адреса по домену.
|
||||
2. Iterative (итеративный) - запрос IP-адреса, либо авторитативного DNS сервера.
|
||||
3. Inverse (обратный) - запрос доменного имени по IP-адресу.
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- icmp
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: ICMP - Internet Control Message
|
||||
---
|
||||
|
||||
# ICMP - Internet Control Message
|
||||
ICMP - расшифровывается как Internet Control Message Protocol - протокол служебных сообщений на сетевом уровне. Используется на третьем уровне модели [[Модель OSI|OSI]]. ICMP позволяет определить, может ли достичь пакет адреса назначения в установленные временные рамки (TTL). ICMP используют маршрутизаторы и др. устройства третьего уровня.
|
||||
|
||||
Для демонстрации работы протокола, можно взять в пример утилиту `ping`, которая позволяет проверить сетевую связность между узлами.
|
||||
|
||||
С помощью TTL - time to live - можно понять, сколько переходов между маршрутизаторами (или "хопов") потребовалось пакету, если есть петля в настройках маршрутизаторов, то TTL быстро закончится и не будет зацикливания и траты ресурсов, а полное использование 128 хопов - явление редкое, поэтому с большой долей вероятности это означает петлю.
|
||||
|
||||
Вторым важным примером использования является утилита `traceroute`, которая позволяет просмотреть список "хопов" пакета от отправителя к получателю.
|
||||
|
||||
## Темная Сторона ICMP
|
||||
|
||||
С помощью этого протокола можно не только проверять "жив ли хост?", но и проводить полноценные атаки на сеть. Такие атаки, зачастую, связаны с атакой типа DOS (Denial-Of-Service - отказ в обслуживании). Например, огромное количество пинг-запросов на хоста с разных источников. В итоге, хост пытается ответить всем и перегружается.
|
||||
|
||||
Так же, раньше была популярна атака **Ping of Death**. Если кратко, ее суть заключалась в следующем: злоумышленник намеренно отправляет пакет больше максимального размера. Такой пакет фрагментируется на сети на несколько частей, прилетает в буфер устройства и попадает в очередь на сборка пакета "воедино". Переполнение этой очереди приводило к подвисанию хоста и полному отказу в работе.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: IP-адрес
|
||||
---
|
||||
|
||||
# IP-адрес
|
||||
**IP - Internet Protocol -** Сетевой адрес
|
||||
|
||||
IP-адрес - это просто набор из 32 нулей и единиц, который преобразовали в 10-ричную систему счисления и разбили на 4 части для удобства.
|
||||
|
||||
В стандарте IPv4 мы можем использовать только **4 294 967 296** адресов, что может не хватить. На замену ему потихоньку вводится [[IPv6]] - число из 128 единиц и нулей, переведенный в 16-чную С.С. и разбитый на 8 частей. Тут доступно уже сильно больше вариантов...
|
||||
|
||||
## Статическая И Динамическая Адресация
|
||||
|
||||
Статика - задается вручную и не меняется в ходе работы. Динамика - задается автоматически посредством DHCP-сервера из определенного ему пула IP.
|
||||
|
||||
Т.к. переход на IPv6 дорог, да и иметь всем конкретный IP не очень безопасно, придумали [[NAT]] (Network Address Translation) и его надстройку PAT (Port Address Translation). Суть в том, что много устройств могут выходить в сеть под "одним" белым (внешним) IP. Но есть нюанс, при маршрутизации трафика к белому IP добавляется порт, который уточняет, к какому именно устройству сети и с каким "внутренним" IP направить эти пакеты.
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
- ipv6
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: IPv6
|
||||
---
|
||||
|
||||
# IPv6
|
||||
При использовании IPv4 с 4 миллиардами адресов, в какой-то момент очевидно столкнулись с проблемой их нехватки. Даже создание PAT и использование локальной адресации не сильно спасло ситуацию.
|
||||
|
||||
Решением проблемы стало изобретение IP версии 6, где используется не 32 бита для кодирования адреса, а 128, при этом, увеличение количества бит на единицу, увеличивает кол-во доступных адресов ровно в два раза, следовательно, для 128 бит вакантных адресов примерно...
|
||||
|
||||
$$\large 340\ 282\ 366\ 920\ 938\ 463\ 463\ 374\ 607\ 431\ 768\ 211\ 456$$
|
||||
|
||||
Это много, даже очень.
|
||||
|
||||
IPv5 А что случилось с IPv5? Хороший вопрос ... IP-версия 5 была использована для экспериментального проекта под названием "Протокол интернет-потока". Он определен в RFC, если вас интересуют исторические причины: [http://www.faqs.org/rfcs/rfc1819.html](http://www.faqs.org/rfcs/rfc1819.html)
|
||||
|
||||
## Отличия IPv4 И IPv6
|
||||
|
||||
В чем же основная проблема перехода на IPv6? А в том, что нет совместимости протоколов для IPv4 и новых поколений.
|
||||
|
||||
- **OSPF** был обновлен с 2 (IPv4) до 3 (IPv6) версии.
|
||||
- **ICMP** был обновлен до ICMP 6.
|
||||
- **ARP** был заменен на _NDP_ (Neighborhood Discovery Protocol).
|
||||
|
||||
|
||||
|
||||
Вместо того чтобы уже добавлять все поля в заголовок, заголовок IPv6 использует "следующий заголовок", который ссылается на необязательные заголовки. Поскольку заголовок намного проще, маршрутизаторам придется выполнять меньше работы.
|
||||
|
||||
Маршрутизация тоже сильно поменялась при переходе на новую версию:
|
||||
|
||||
1. RIP -> RIPng (RIP Next Generation)
|
||||
2. BGP (Border Gateway Protocol) - протокол, объединяющий интернет вместе. MP-BGP - Multi-Protocol BGP, он может маршрутизировать IPv6. EIGRP также поддерживает IPv6.
|
||||
|
||||
Надо учитывать, что даже при условии поддержки OSPF и EIGRP адресации обоих версий, это два **разных протокола**. Из этого следует, что сначала надо поднять протокол для одной версии, а потом для другой. Использование двух версий IP называется **двойным стеком**.
|
||||
|
||||
> Поскольку эти два протокола несовместимы, в будущем будет происходить переход с IPv4 на IPv6. Это означает, что вы будете запускать оба протокола в своей сети и, возможно, однажды вы сможете отключить IPv4, так как весь интернет будет настроен на IPv6.
|
||||
|
||||
## Формат IPv6
|
||||
|
||||
```text
|
||||
2041:0000:140F:0000:0000:0000:875B:131B
|
||||
```
|
||||
|
||||
Он сильно длиннее, чем IPv4, состоит из 8 частей, каждая часть состоит из 4 шестнадцатиричных чисел.
|
||||
|
||||
|
||||
|
||||
Таблица перевода шестнадцатиричных чисел в двоичные
|
||||
|
||||
Существуют некоторые правила, позволяющие упростить работу с адресами:
|
||||
|
||||
1. Если есть несколько частей с нулями, то их можно убрать, заменив на `::` `2041:0000:140F:0000:0000:0000:875B:131B` -> `2041: 0000:140F:: 875B:131B`
|
||||
2. Если есть одиночный блок с нулями, то можно его заменить на один ноль `2041: 0000:140F:: 875B:131B` -> `2041:0:140F:: 875B:131B`
|
||||
3. При наличии в блоке значащих чисел и нулями перед ними, нули можно опустить `2001:0001:0002:0003:0004:0005:0006:0007` -> `2001:1:2:3:4:5:6:7`
|
||||
|
||||
При использовании IPv4 и нехватке адресов, люди начали адаптироваться, придумав частные сети и [[VLSM]] (сегментацию сети), использовали [[NAT]] и так далее. При переходе на IPv6 такой проблемы уже не будет, т.к. пула доступных адресов будет достаточно для снабжения адресами нескольких планет, таких, как Земля. Протокол IPv6 предлагает два варианта для одноадресной рассылки:
|
||||
|
||||
1. Global Unicast
|
||||
2. Unique Local
|
||||
|
||||
Ранее, как отголосок IPv4 существовал третий диапазон адресов "site local", который начинался с `FEC0::/10`. Он предназначался для использования во внутренних сетях (аналог `192.168.0.0/24`), но был удален из стандарта IPv6.
|
||||
|
||||
**Global Unicast** передачи похожи на публичные IPv4 адреса. Каждая компания, желающая подключится к интернету, получает пул адресов, которые они, на своё усмотрение, делят на более мелкие префиксы, чтобы все устройства сети поулчили IPv6 адрес, притом уникальный во всем мире. Зарезервированный блорк называется префиксом глобальной маршрутизации.
|
||||
|
||||
## Получение Префиксов
|
||||
|
||||
- **IANA** отвечает за распределение всех префиксов IPv6. Они будут назначать реестрам разные блоки, которыми будут управлять региональные компании.
|
||||
- **ISP**, попадлающие под реестр региональной компании, заправшивает блок IPv6. Они получают свой пул адресов, которые могут распределять между провайдерами. !
|
||||
|
||||
|
||||
|
||||
> Некоторые префиксы **FD**: Unique Local **FF**: Multicast **FE80**: Link-Local
|
||||
|
||||
## Local И Link-Local
|
||||
|
||||
После получения клиентом от провайдера префикса, например, `2001: 828:105:: / 48`, необходимо его разбить на подсети для различных VLAN и point-to-point соединений, которые могут быть. Поскольку адресное пространство настолько велико, все используют префикс `/64` для подсетей. Не имеет смысла брать меньшие подсети. Когда мы используем IPv4, мы вынуждены, для подсетей, дробить хостовую часть!
|
||||
|
||||
|
||||
|
||||
Тогда, у нас, в целом, будет меньше хостов на подсеть.
|
||||
|
||||
|
||||
|
||||
В IPv6 такой проблемы нет:
|
||||
|
||||
|
||||
|
||||
Префикс Global Routing был назначен провайдером. Последние 64 бита называются **идентификатором интерфейса**, это эквивалетно части хоста в IPv4.
|
||||
|
||||
Путем несложно математики, получается, что у нас 16 бит на подсети, а это около 65536 подсетей (как правило, этого _более чем_ достаточно). В этой же схеме, на хосты в каждой подсети отводится около **18 квинтиллионов** хостов.
|
||||
|
||||
Если клиент получил префикс `2001: 828: 105:: / 48`, то он может создать такие подсети:
|
||||
|
||||
|
||||
|
||||
```text
|
||||
- 2001:828:105:0000::/64;
|
||||
- 2001:828:105:0001::/64;
|
||||
- 2001:828:105:0002::/64;
|
||||
- 2001:828:105:0003::/64;
|
||||
- 2001:828:105:0004::/64;
|
||||
- 2001:828:105:0005::/64;
|
||||
- 2001:828:105:0006::/64;
|
||||
- 2001:828:105:0007::/64;
|
||||
- 2001:828:105:0008::/64;
|
||||
- 2001:828:105:0009::/64;
|
||||
- 2001:828:105:000A::/64;
|
||||
- 2001:828:105:000B::/64;
|
||||
- 2001:828:105:000C::/64;
|
||||
- 2001:828:105:000D::/64;
|
||||
- 2001:828:105:000E::/64;
|
||||
- 2001:828:105:000F::/64;
|
||||
- 2001:828:105:0010::/64;
|
||||
- 2001:828:105:0011::/64;
|
||||
- 2001:828:105:0012::/64;
|
||||
- 2001:828:105:0013::/64;
|
||||
- 2001:828:105:0014::/64;
|
||||
...
|
||||
```
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
tags:
|
||||
- network
|
||||
- networking
|
||||
- protocols
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-07
|
||||
title: TCP Vs UDP
|
||||
---
|
||||
|
||||
# TCP Vs UDP
|
||||
Основные протоколы транспортного уровня модели OSI (L4).
|
||||
|
||||
## **TCP**
|
||||
|
||||
- Transmission Control Protocol Перед передачей данных устанавливает соединение трехсторонним рукопожатием.
|
||||
|
||||
- SYN - отправка запроса на возможность передачи данных от отправителя.
|
||||
- SYNACK - подтверждение получающей стороной.
|
||||
- ACK - начало передачи данных.
|
||||
|
||||
После отправки части данных, получающая сторона отправляет подтверждение передачи.
|
||||
|
||||
Этот протокол надежный, но очень медленный.
|
||||
|
||||
TCP, как протокол, определен в **RFC (Request For Comments) 793**, выполняет функции, перечисленные в таблице ниже, через механизмы, предоставляемые конечными устройствами. Он полагается на IP для сквозной доставки данных, включая вопросы маршрутизации. Независимо от того, в каких условиях находятся ПК для передачи, TCP работает одинаково на своем уровне.
|
||||
|
||||
|
||||
|
||||
Функционал TCP
|
||||
|
||||
|
||||
|
||||
Поля заголовка TCP
|
||||
|
||||
## **UDP**
|
||||
|
||||
- User Datagram Protocol Просто бросается файлами в "сторону" получающей стороны. Может теряться часть данных, или их порядок. В случае с видео, звонками, мы можем позволить себе потерю данных.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user