Как устроена компьютерная сеть: (сетевые технологии, локальная сеть, модель osi)

Как устроена компьютерная сеть: (сетевые технологии, локальная сеть, модель osi)

Основные темы в данной статье:

1. Что такое сетевая модель OSI и из чего она состоит?

2. IP адрес, Маска, ШЛЮЗ, DNS (подробно что зачем)

3. Мосты, коммутаторы, роутеры.

4. IPv6 в первом приближение.(под картинками.)

Я пропущу всю IPv4 часть (ничего интересного — обычный nat) и сконцентрируюсь на IPv6.

Полученные мною настройки от Tiera для IPv6:

1. Адрес 2a00:11d8:1201:0:962b:18:e716:fb97/128 мне выдан для компьютера/шлюза

2. Сеть 2a00:11d8:1201:32b0::/64 мне выдана для домашних устройств

У провайдера сеть 2a00:11d8:1201:32b0::/64 маршрутизируется через 2a00:11d8:1201:0:962b:18:e716:fb97 (то есть через мой компьютер). Заметим, это всё, что я получил. Никаких шлюзов и т.д. — тут начинается магия IPv6, и самое интересное. «Оно работает само».

Начнём с простого: настройка 2a00:11d8:1201:0:962b:18:e716:fb97 на eth3 для компьютера. Для удобства чтения все конфиги и имена файлов я оставлю на последнюю секцию.

Мы прописываем ipv6 адрес на интерфейсе eth2… И чудо, он начинает работать. Почему? Каким образом компьютер узнал, куда надо слать пакеты дальше? И почему /128 является валидной сетью для ipv6? Ведь /128 означает сеть размером в 1 ip-адрес и не более. Там не может быть шлюза!

Для того, чтобы понять, что происходит, нам надо взглянуть на конфигурацию сети (я вырежу всё лишнее, чтобы не пугать выводом):

# ip address show eth2 (обычно сокращают до ip a s eth2)

eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

(skip)

inet6 2a00:11d8:1201:0:962b:18:e716:fb97/128 scope global

valid_lft forever preferred_lft forever

inet6 fe80::218:e7ff:fe16:fb97/64 scope link

valid_lft forever preferred_lft forever

Упс. А почему у нас на интерфейсе два адреса? Мы же прописывали один? Наш адрес называется 'scope global', но есть ещё и 'scope link'…

Часть первая: scope

Тут нас встречает первая особенность IPv6 — в нём определено понятие 'scope' (область видимости) для адреса.
Есть следующие виды scope:

· global — «обычный» адрес, видимый всему Интернету

· local или link-local — адрес, видимый только в пределах сетевого сегмента. Ближайшим аналогом этого является configless IPv4 из диапазона 169.254.0.0/16, на который сваливается любая windows, которой сказали автоматически получить адрес, а DHCP-сервера вокруг нет. Эти адреса не могут быть маршрутизируемы (то есть тарфик с них не передаётся дальше своей сети). Подробнее про link-local address(wiki).

· host, он же interface — видимость в пределах хоста. Примерный аналог — loopback адреса для IPv4 (127.0.0.0/8)

· admin-local — в живую не видел, но какая-то промеждуточная стадия

· site-local — видимость в пределах офиса. Аналог серых 192.168.0.0/16, то есть адреса, которые не должны выходить за пределы локальной сети

· organization-local — адреса, которые не выходят за пределы организации.

В процессе проектирования IPv6 вопрос 'scope' много и тщательно обсуждался, потому что исходное деление IPv4, даже с последующими дополнениями, явно не соответствовало потребностям реальных конфигураций. Например, если у вас объединяются две организации, в каждой из которых используется сеть 10.0.0.0/8, то вас ждёт множество «приятных» сюрпризов. В IPv6 решили с самого начала сделать множество градаций видимости, что позволило бы более комфортно осуществлять дальнейшие манипуляции.

Из всего этого на практике я видел использование только host/interface, link/local и global. В свете /64 и пусть никто не уйдёт обиженным, специально возиться с site-local адресами будет только параноик.

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

Так как в отличие от IPv4 у IPv6 может быть несколько адресов на интефрейсе, то компьютеру не нужно выбирать «какой адрес взять». Он может брать несколько адресов. В случае IPv4 сваливание на link-local адрес происходило в режиме «последней надежды», то есть по большому таймауту.

А в IPv6 мы можем легко и просто с самого первого момента, как интерфейс поднялся, сделать ему link local (и уже после этого думать о том, какие там global адреса есть).

Более того, в IPv6 есть специальная технология автоматической генерации link-local адреса, которая гарантирует отсутствие дублей. Она использует MAC-адрес компьютера для генерации второй (младшей) половинки адреса. Поскольку MAC-адреса уникальны хотя бы в пределах сегмента (иначе L2 сломан и всё прочее автоматически не работает), то использование MAC-адреса даёт нам 100% уверенность в том, что наш IPv6 адрес уникален.

В нашем случае это inet6 fe80::218:e7ff:fe16:fb97/64 scope link. Обратите внимание на префикс — fe80 — это link-local адреса.

Как он делается?

Принцип довольно простой:

MAC-адрес eth2 — это 00:18:e7:16:fb:97, а локальный адрес ipv6 — e80: 00 02 18:e7 ff:fe 16:fb97. Да-да, именно так, как выделено жирным. Зачем было в середину всобачивать ff:fe — не знаю. Сам алгоритм называется modified EUI-64. Сам этот алгоритм очень мотивирован и полон деталей. С позиции системного администратора — пофигу. Адрес есть и есть. Интересным может быть, наверное, обратный алгоритм — из link-local узнать MAC и не более.

Итак, у нас на интерфейсе два адреса. Мы даже знаем, как появились они оба (один автоматически при подъёме интерфейса, второй прописали мы). Мы даже знаем, как система поняла, что адрес глобальный — он из «global» диапазона.

Но каким образом система узнала про то, кто его шлюз по умолчанию? И как вообще может жить /128?

Часть вторая, промежуточная: мультикасту мультикаст мультикастно мультикастит

Посмотрим на таблицу маршрутизации:

ip -6 route show (обычно сокращают до ip -6 r s, или даже ip -6 r):

2a00:11d8:1201:0:962b:18:e716:fb97 dev eth2 proto kernel metric 256

fe80::/64 dev eth2 proto kernel metric 256

default via fe80::768e:f8ff:fe93:21f0 dev eth2 proto ra metric 1024 expires 1779sec

Что мы тут видим? Первое — говорит нам, что наш IPv6 адрес — это адрес нашего интерфейса eth2. Второе говорит, что у нас есть link-local сегмент в eth2. У обоих источник — это kernel.

А вот третье — это интрига. Это шлюз по умолчанию, который говорит, что весь трафик надо отправлять на fe80::768e:f8ff:fe93:21f0 на интерфейсе eth2, и источником информации о нём является некое «ra», а ещё сказано, что оно протухает через 1779 секунд.

Что? Где? Куда? Кто? За что? Почему? Зачем? Кто виноват?

Но перед ответом на эти вопросы нам придётся познакомиться с ещё одной важной вещью — multicast. В IPv4 muticast был этакой технологией «не от мира сего». Есть, но редко используется в строго ограниченных случаях. В IPv6 эта технология — центральная часть всего и вся. IPv6 не сможет работать без мультикаста. И без понимания этого многие вещи в IPv6 будут казаться странными или ломаться в неожиданных местах.

Кратко о типах трафика, возможно кто-то пропустил эту информацию, когда изучал IPv4:

· unicast — пакет адресуется конкретному получателю. Обычный трафик идёт юникастом.

· broadcast — пакет адресуется всем, кто его слышит. Например, в IPv4 так рассылается запрос о mac-адресе для данного IP-адреса.

· multicast — пакет адресуется некоторому множеству узлов, которые слушают специальный multicast-адрес. И если получают сообщение, то реагируют на него.

· anycast — пакет адресуется на адрес, общий для кучи узлов. Кто к запрашивающему ближе (и готов ответить) — тот и отвечает

Так вот, в IPv6 НЕТ БРОДКАСТОВ. Вообще. Вместо них есть мультикаст. И некоторые из мультикаст-адресов являются ключевыми для работы IPv6.

Вот примеры таких адресов (они все link-local, то есть имеют смысл только в контексте конкретного интерфейса):

· FF02::1 — все узлы сети. Считайте, старинный бродкаст канального уровня.

· FF02::2 — все маршрутизаторы сети

Полный список адресов, вместе с нюансами link-local, site-local, etc, можно посмотреть тут:www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

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

ping6 -I eth2 FF02::2

64 bytes from fe80::218:e7ff:fe16:fb97: icmp_seq=1 ttl=64 time=0.039 ms

64 bytes from fe80::768e:f8ff:fe93:21f0: icmp_seq=1 ttl=64 time=0.239 ms (DUP!)

64 bytes from fe80::211:2fff:fe23:5763: icmp_seq=1 ttl=64 time=1.38 ms (DUP!)

64 bytes from fe80::5a6d:8fff:fef5:6235: icmp_seq=1 ttl=64 time=5.68 ms (DUP!)

64 bytes from fe80::cad7:19ff:fed5:25b8: icmp_seq=1 ttl=64 time=7.20 ms (DUP!)

64 bytes from fe80::22aa:4bff:fe1e:9e88: icmp_seq=1 ttl=64 time=8.19 ms (DUP!)

64 bytes from fe80::5a6d:8fff:fe4a:c643: icmp_seq=1 ttl=64 time=8.69 ms (DUP!)

64 bytes from fe80::205:9aff:fe3c:7800: icmp_seq=1 ttl=64 time=11.1 ms (DUP!)

64 bytes from fe80::20c:42ff:fef9:807a: icmp_seq=1 ttl=64 time=16.0 ms (DUP!)

Сколько маршрутизаторов вокруг меня… Первым откликнулся мой компьютер. Это потому, что он тоже роутер. Но вопрос маршрутизации мы рассмотрим чуть позже. Пока что важно, что мы видим все роутеры и только роутеры (а, например, ping6 -I eth2 FF002::1 показывает порядка 60 соседей).

Мультикаст-групп (группой называют все узлы, которые слушают данный мультикаст-адрес) много. Среди них — специальная группа FF02::6A с названием «All-Snoopers». Именно этой группе и рассылаются routing advertisements. Когда мы хотим их получать — мы вступаем в соответствующую группу. Точнее не мы, а наш компьютер.

Часть третья: routing advertisements

В IPv6 придумали такую замечательную вещь — когда маршрутизатор рассылает всем желающим информацию о том, что он маршрутизатор. Рассылает периодически.

В отношении этого вопроса есть целый (всего один, что удивительно) RFC: tools.ietf.org/html/rfc4286, но нас интересует из всего этого простая вещь: маршрутизатор рассылает информацию о том, что он маршрутизатор. И, может быть, чуть-чуть ещё информации о том, что в сети происходит.

Вот откуда наш компьютер узнал маршрут. Некий маршрутизатор сказал ему «я маршрутизатор». И мы ему поверили. Почему мы выбрали именно его среди всех окружающих маршруштизаторов (см ответ на пинг на FF02::2 выше) мы обсудим чуть дальше. Пока что скажем, что этот «настоящий» маршрутизатор правильно себя анонсировал.

Таким образом, происходит следующая вещь:

У нас адрес 2a00:11d8:1201:0:962b:18:e716:fb97/128, и ещё есть link-local. Мы слышим мультикаст от роутера, верим ему, и добавляем в таблицу маршрутизации нужный нам адрес как default. С этого момента мы точно знаем, что адрес в сети. Таким образом, отправка трафика в интернет больше не проблема. Мы генерируем пакет с src=2a00:11d8:1201:0:962b:18:e716:fb97 и отправляем его на шлюз по умолчанию, который в нашем случае — fe80::768e:f8ff:fe93:21f0. Другими словами, мы отправляем трафик не своему «шлюзу» в сети, а совсем другому узлу совсем по другому маршруту. Вполне нормальная вещь как для IPv6, так и для IPv4, правда, для IPv4 это некая супер-крутая конфигурация, а для IPv6 — часть бытовой повседневности.

Но как трафик приходит обратно? Очень просто. Когда маршрутизатор провайдера получает пакет, адресованный 2a00:11d8:1201:0:962b:18:e716:fb97, то у него на одном из интерфейсов написано, что он там 2a00:11d8:1201::/64 via (я не знаю, как там называется интерфейс, но пусть) GE1/44/12. Маршрутизатор спрашивает всех соседей (neighbor discovery) об их адресах, и внезапно видит, что адрес такой-то в сети. Что может быть проще — мак есть, адрес есть, отправляем в интерфейс. Ура, наш компьютер видит трафик. Двусторонняя связь установлена.

Въедливый читатель может спросить несколько вопросов: что значит «написано на интерфейсе»? И что значит «neighbor discovery»?

Вопросы справедливые. Для начала попробуем выяснить, какие узлы у нас есть в сети из подсети 2a00:11d8:1201::/64

Для того, чтобы посмотреть router advertisement на интерфейсе нам поднадобится программа radvdump из пакета radvd. Она позволяет печатать анонсы, проходящие на интерфейсах, в человеческом виде. Заметим, сам пакет radvd нам ещё пригодится (так как его демон — radvd позволяет настроить анонсирование со своих интерфейсах).

Итак, посмотрим, что аносирует нам Tiera:

radvdump eth2 (и подождать прилично, ибо анонсы не очень часто рассылаются)

#

# radvd configuration generated by radvdump 1.9.1

# based on Router Advertisement from fe80::768e:f8ff:fe93:21f0

# received by interface eth2

#

interface eth2

{

AdvSendAdvert on;

# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump

AdvManagedFlag on;

AdvOtherConfigFlag on;

AdvReachableTime 0;

AdvRetransTimer 0;

AdvCurHopLimit 64;

AdvDefaultLifetime 1800;

AdvHomeAgentFlag off;

AdvDefaultPreference medium;

AdvSourceLLAddress on;

AdvLinkMTU 9216;

prefix 2a00:11d8:1201::/64

{

AdvValidLifetime 2592000;

AdvPreferredLifetime 604800;

AdvOnLink on;

AdvAutonomous on;

AdvRouterAddr off;

}; # End of prefix definition

}; # End of interface definition

Из всего этого важным является:

· Адрес, с которого получен анонс (в нашем случае fe80::768e:f8ff:fe93:21f0) — это и есть адрес шлюза.

· Указание на сетевой сегмент, в котором можно автоконфигурировать себе адреса

· Флаг AdvAutonomous on, указывающий, что этот анонс имеет смысл. Если бы флаг был off, то его бы можно было смело игнорировать.

Таким образом всё просто — адрес мы указали, маршрутизатор нам «себя» прислал, ядро маршрут обновило. Вуаля, у нас IPv6 на компьютере заработал.

Белый IPv6-адрес для каждого в домашней сети

Получить IPv6 адрес для компьютера — этого маловато будет. Хочется так, чтобы каждое мобильное устройство сидело не за позорным NAT'ом, а голой задницей с белым адресом в Интернете. Желательно ещё при этом так, чтобы злые NSA/google не могли по хвостику моего адреса (в котором закодирован MAC) отслеживать мои перемещения между разными IPv6-сетями (хотя в условиях установленного play services эта параноидальность выглядит наивной и беззащитной).

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

Tiera, выдавая мне ipv6, настроила у себя маршрут: 2a00:11d8:1201:32b0::/64 via 2a00:11d8:1201:0:962b:18:e716:fb97.

Так как fb97 уже является адресом моего компьютера, настройка машрутизации плёвое дело:

sysctl net.ipv6.conf.all.forwarding=1

… и у нас через пол-часика полностью отваливается IPv6 на компьютере? Почему? Кто виноват?

Оказывается, линукс не слушает routing advertisement, если сам является маршрутизатором. Что, в общем случае, правильно, потому что если два маршрутизатора будут объявлять себя маршрутизаторами и слушать маршруты друг друга, то мы быстро получим простейшую петлю из двух зацикленных друг на друга железных болванов.

Однако, в нашем случае мы всё-таки хотим слушать RA. Для этого нам надо включить RA силком.

Это делается так:

sysctl net.ipv6.conf.eth2.accept_ra=2

Заметим, важно, что мы слушаем RA не всюду, а только на одном интерфейсе, с которого ожидаем анонсы.

Теперь маршрутизация работает, маршрут получается автоматически, и можно на каждом мобильном устройстве вручную прописать IPv6 адрес и вручную указать IPv6 шлюз, и вручную прописать IPv6 DNS, и вручную… э… слишком много вручную.

Если мне выдали настройки автоматом, то я так же хочу раздавать их дальше автоматом. Благо, dhcpd отлично справляется с аналогичной задачей для IPv4.

Прелесть IPv6 в том, что мы можем решить эту задачу (раздачу сетевых настроек) без каких-либо специальных сервисов и в так называемом stateless режиме. Главная особенность stateless режима состоит в том, что никто не должен напрягаться и что-то сохранять, помнить и т.д. Проблемы с DHCP в IPv4 чаще всего вызывались тем, что один и тот же адрес выдавали двум разным устройствам. А происходило это из-за того, что злой админ стирал/забывал базу данных уже выданных аренд. А ещё, если железок много и они забывают «отдать аренду», то адреса заканчиваются. Другими словами, stateful — это дополнительные требования и проблемы.

Для решения тривиальной задачи «раздать адреса» в IPv6 придумали stateless режим, который основывается на routing advertisement. Клиентскую часть мы уже видели, теперь осталось реализовать серверную, дабы накормить IPv6 планшетик.

Дата добавления: 2015-08-28