Сетевой уровень: адресация и маршрутизация (IPv6)
Задачи
- Глобальная идентификация (адресация)
- Структура адреса
Механизм раздачи идентификаторов
- Алгоритм доставки (маршрутизация)
- Известный маршрут и маршрут по умолчанию внутри крупной сети
- Связность крупных сетей (карта достижимости / стоимость)
IPv6
Структура адреса
Адрес: адрес сети + адрес абонента
Адрес: 128 бит, префикс + интерфейсный идентификатор
- Назначается на интерфейс
- Может быть несколько на одном интерфейсе
- Unicast / Anycast / Multicast
- Anycast-адреса неотличимы от unicast, отличается лишь тип доставки
Multicast: первый октет 1111 1111, он же 0xff
- Нет широковещания, оно — частный случай multicast
- Префикс подсети
сетевая маска "длина префикса": N старших бит
интерфейсный идентификатор, Interface ID, IID: младшие биты
- например, MAC или его хэш
- Область действия (Scope) юникастного адреса
- Global Unicast
Link-local (первые 10 бит — 1111 1110 10)
Запись: 2001:0db8:85a3:0000:0000:0370:008e:7334 == 2001:db8:85a3::370:8e:7334
Для LL-адресов: fe80::8a2e:370:7334%eth1, после % идёт scope identifier
В Linux можно после % писать имя интерфейса, а можно его уникальный ifindex в netns.
Адреса интерфейсов в Linux: ip a (add, del и т. п.)
LLA
- Адреса для служебных целей, которые "просто работают"
- уникальны только в рамках одного сегмента связи
- не требуют IPv6-маршрутизаторов
- не подлежат маршрутизации
- всегда доступны в локальной среде напрямую
что не всегда верно для адресов других обл. действия, даже если назначен адрес в том же префиксе!
- Могут использоваться и для прикладного трафика, если это удобно
На каждом интерфейсе, на котором включен IP, автоматически генерируется link-local адрес:
узел генерирует интерфейсный идентификатор, Interface ID, IID: например, ::1c80:9aa4:528e:bb85
назначает себе адрес(-а) в префиксе fe80::/64 с младшими битами, равными IID: например, fe80::1c80:9aa4:528e:bb85
Можно, конечно, назначить и вручную.
Свойства
- Фрагментация на стороне отправителя
- или, вместо неё, PMTUD: рекомендовать максимальный размер пакета уровням выше
- Противодействие зацикливанию: hop limit, он же TTL
- Принятие решения о маршрутизации
- Таблица маршрутизации в соответствии с адресом получателя
Linux: ip -6 route (по умолчанию подразумевает IPv4 :[)
- Нетабличная маршрутизация по отправителю/next-header/ULP
(не влезет) Routing Headers: мета-маршрутизация по расширенному заголовку.
- Таблица маршрутизации в соответствии с адресом получателя
- Заполнение маршрутных таблиц:
Специальные адреса и сети
Address Block
Name
RFC
Allocation Date
Termination Date
Source
Destination
Forwardable
Globally Reachable
Reserved-by-Protocol
::1/128
Loopback Address
2006-02
N/A
False
False
False
False
True
::/128
Unspecified Address
2006-02
N/A
True
False
False
False
True
::ffff:0:0/96
IPv4-mapped Address
2006-02
N/A
False
False
False
False
True
64:ff9b::/96
IPv4-IPv6 Translat.
2010-10
N/A
True
True
True
True
False
64:ff9b:1::/48
IPv4-IPv6 Translat.
2017-06
N/A
True
True
True
False
False
100::/64
Discard-Only Address Block
2012-06
N/A
True
True
True
False
False
2001::/23
IETF Protocol Assignments
2000-09
N/A
False [1]
False [1]
False [1]
False [1]
False
2001::/32
TEREDO
2006-01
N/A
True
True
True
N/A [2]
False
2001:1::1/128
Port Control Protocol Anycast
2015-10
N/A
True
True
True
True
False
2001:1::2/128
Traversal Using Relays around NAT Anycast
2017-02
N/A
True
True
True
True
False
2001:2::/48
Benchmarking
2008-04
N/A
True
True
True
False
False
2001:3::/32
AMT
2014-12
N/A
True
True
True
True
False
2001:4:112::/48
AS112-v6
2014-12
N/A
True
True
True
True
False
2001:10::/28
Deprecated (previously ORCHID)
2007-03
2014-03
2001:20::/28
ORCHIDv2
2014-07
N/A
True
True
True
True
False
2001:30::/28
Drone Remote ID Protocol Entity Tags (DETs) Prefix
2022-12
N/A
True
True
True
True
False
2001:db8::/32
Documentation
2004-07
N/A
False
False
False
False
False
2002::/16 [3]
6to4
2001-02
N/A
True
True
True
N/A [3]
False
2620:4f:8000::/48
Direct Delegation AS112 Service
2011-05
N/A
True
True
True
True
False
fc00::/7
Unique-Local
2005-10
N/A
True
True
True
False [4]
False
fe80::/10
Link-Local Unicast
2006-02
N/A
True
True
False
False
True
Протоколы сетевого уровня
- определяются полем Next Header в заголовке
ICMP (rfc4443)
множество types и codes
работа traceroute: отсылка пакетов с увеличивающимся TTL и регистрация ICMP-ответов в стиле «пакет не дожил»
Path MTU Discovery (rfc4821 / Maximum_transmission_unit)
NDP (rfc4861): Мы знаем IP адресата, и определили, что он находится в локальной сети за интерфейсом, скажем, eth1. Надо инкапсулировать IP-пакет в фрейм и отослать по MAC-адресу… какому?
- Тоже ICMP, а не сетево-интерфейсного уровня
- Neighbour Solicitation
- Neighbour Advertisement
- Duplicate Address Detection (DAD): перед назначением адреса шлём NS
ip neigh: посмотреть таблицу соответствия MAC → IP
- Алсо, ND Proxy: притворяемся, что это наш MAC, а сами втихую пересылаем
- Router Discovery (вскользь; подробнее в следующей лекции)
- конечные узлы шлют Router Solicitation, RS
- маршрутизаторы шлют Router Advertisement, RA
- опция PIO, флаги A и L
опция RDNSS
- IPSec, OSPF…
Протоколы сетевого/интерфейсного уровня
Нужен ли вообще подраздел? На ум приходит только network boot.
Настройка IP в Linux и табличная маршрутизация
Destination-based принцип табличной маршрутизации: «адрес получателя ⇒ сеть получателя ⇒ маршрут».
Три скринкаста к проводимым ниже настройкам: router, client, clone.
Настройка подсети
Сетевая маска: количество старших разрядов в двоичном представлении адреса, соответствующих «адресу сети». Оставшиеся младшие биты — IID в этой сети:
Часто записывается в виде числа после символа слеша (/48), реже — как последовательность 1 в двоичном виде
# sipcalc 2001:db8:ab::3:4:56a/64 -[ipv6 : 2001:db8:ab::3:4:56a/64] - 0 [IPV6 INFO] Expanded Address - 2001:0db8:00ab:0000:0000:0003:0004:056a Compressed address - 2001:db8:ab::3:4:56a Subnet prefix (masked) - 2001:db8:ab:0:0:0:0:0/64 Address ID (masked) - 0:0:0:0:0:3:4:56a/64 Prefix address - ffff:ffff:ffff:ffff:0:0:0:0 Prefix length - 64 Address type - Aggregatable Global Unicast Addresses Network range - 2001:0db8:00ab:0000:0000:0000:0000:0000 - 2001:0db8:00ab:0000:ffff:ffff:ffff:ffff
При ручной настройке IP на сетевом интерфейсе Linux указывается размер префикса. При этом Linux по умолчанию вносит в таблицу маршрутизации запись вида: «такая-то IP-подсеть находится непосредственно за этим сетевым интерфейсом», предполагая, что адреса в этом префиксе доступны напрямую по локальной среде.
1 srv:~# ip link set dev eth1 up 2 srv:~# ip addr add dev eth1 2001:db8:0:a::56a/64 3 srv:~# ip -6 r 4 2001:db8:0:a::/64 dev eth1 proto kernel metric 256 pref medium 5 srv:~# ping 2001:db8:0:a::56b 6 PING 2001:db8:0:a::56b (2001:db8:0:a::56b) 56 data bytes 7 ^C 8 1 packets transmitted, 0 received, 100% packet loss, time 0ms 9 srv:~# ip -6 n 10 2001:db8:0:a::56b dev eth1 INCOMPLETE 11 srv:~# ping 2001:db8:0:b::400 12 ping: connect: Network is unreachable 13
При автоматической настройке IP на интерфейсе по объявлению от маршрутизатора (RAdv) такая запись может не вноситься (передаётся опция-флаг noprefixroute)
На второй машине (она будет называться router, потому что в дальнейшем послужит маршрутизатором) — практически то же самое, но назначим внутрисегментный адрес:
1 router:~# ip link set dev eth1 up 2 router:~# ip addr add dev eth1 fe80::2/64 3 router:~# ping -c 1 2001:db8:0:a::56a 4 PING 2001:db8:0:a::56a(2001:db8:0:a::56a) 56 data bytes 5 64 bytes from 2001:db8:0:a::56a: icmp_seq=1 ttl=64 time=1.84 ms 6 router:~# ip -6 n # записи протухают за считанные секунды! 7 2001:db8:0:a::56a dev eth1 lladdr 08:00:27:f5:75:0c DELAY 8
Адрес сети интерфейса eth1 — 2001:db8:0:a::/64 совпадает с абонентским (2001:db8:0:a::56a), если применить ту же сетевую маску /64.
Неявное правило из таблицы маршрутизации гласит, что с абонентом мы связаны единой средой передачи данных, и сетевая подсистема вправе ожидать появления MAC-адреса этого 2001:db8:0:a::56b в ARP-таблице таблице соседей (ip neighbour)
При применении той же сетевой маски к 2001:db8:0:b::400/64 мы получаем адрес 2001:db8:0:b::/64, он ни с чем не совпадает, а других записей в таблице маршрутизации у нас нет — как следствие, сообщение о недостижимости.
Как работает Neighbour Discovery
TODO: вместо примера из жизни вставить пример из лабораторного окружения на наших виртуалках.
- Зачистим таблицу соседей на клиенте:
Запустим tcpdump -xx -n icmp6 на клиенте (но лучше на роутере);
Запустим ping -6 -c2 cmc.msu.net на клиенте:
1 [root@teacher ~]# ping -6c2 cmc.msu.net && ip -6 n 2 PING cmc.msu.net(cmc.msu.net (2a00:f480::3)) 56 data bytes 3 64 bytes from cmc.msu.net (2a00:f480::3): icmp_seq=1 ttl=64 time=0.621 ms 4 64 bytes from cmc.msu.net (2a00:f480::3): icmp_seq=2 ttl=64 time=0.510 ms 5 6 --- cmc.msu.net ping statistics --- 7 2 packets transmitted, 2 received, 0% packet loss, time 1001ms 8 rtt min/avg/max/mdev = 0.510/0.565/0.621/0.055 ms 9 fe80::1 dev eno1 lladdr 00:15:c7:60:ac:00 router REACHABLE 10
Вывод tcpdump:
1 19:54:05.245970 IP6 fe80::53c9:da12:2212:f624 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32 2 0x0000: 3333 ff00 0001 6400 6a58 b94f 86dd 6000 3 : ^^^^ ^^^^ ^^^^ ^ 4 : ethernet multicast group Ver 5 0x0010: 0000 0020 3a 6 : ^^^^ ^^ 7 : len Next Header (ICMPv6) 8 0x0010: ff fe80 0000 0000 0000 53c9 9 : ^^ 10 : Hop Limit 11 0x0020: da12 2212 f624 ff02 0000 0000 0000 0000 12 0x0030: 0001 ff00 0001 87 13 : ^^ 14 : type 15 0x0030: 00 aedf 0000 0000 fe80 16 : ^^ ^^^^ 17 : code csum 18 0x0040: 0000 0000 0000 0000 0000 0000 0001 0101 19 0x0050: 6400 6a58 b94f 20 19:54:05.246190 IP6 2a00:f480:8:300:e2bb:557d:95e7:21ea > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32 21 0x0000: 3333 ff00 0001 6400 6a58 b94f 86dd 6000 22 0x0010: 0000 0020 3aff 2a00 f480 0008 0300 e2bb 23 0x0020: 557d 95e7 21ea ff02 0000 0000 0000 0000 24 0x0030: 0001 ff00 0001 8700 e1df 0000 0000 fe80 25 0x0040: 0000 0000 0000 0000 0000 0000 0001 0101 26 0x0050: 6400 6a58 b94f 27 19:54:05.248718 IP6 fe80::1 > fe80::53c9:da12:2212:f624: ICMP6, neighbor advertisement, tgt is fe80::1, length 32 28 0x0000: 6400 6a58 b94f 0015 c760 ac00 86dd 6e00 29 0x0010: 0000 0020 3aff fe80 0000 0000 0000 0000 30 0x0020: 0000 0000 0001 fe80 0000 0000 0000 53c9 31 0x0030: da12 2212 f624 8800 e094 e000 0000 fe80 32 0x0040: 0000 0000 0000 0000 0000 0000 0001 0201 33 : ^^^^ 34 : option type and length 35 0x0050: 0015 c760 ac00 36 : ^^^^ ^^^^ ^^^^ 37 : option 2: dest link address 38 19:54:05.248718 IP6 fe80::1 > 2a00:f480:8:300:e2bb:557d:95e7:21ea: ICMP6, neighbor advertisement, tgt is fe80::1, length 32 39 0x0000: 6400 6a58 b94f 0015 c760 ac00 86dd 6e00 40 0x0010: 0000 0020 3aff fe80 0000 0000 0000 0000 41 0x0020: 0000 0000 0001 2a00 f480 0008 0300 e2bb 42 0x0030: 557d 95e7 21ea 8800 1395 e000 0000 fe80 43 0x0040: 0000 0000 0000 0000 0000 0000 0001 0201 44 0x0050: 0015 c760 ac00 45 19:54:05.248732 IP6 2a00:f480:8:300:e2bb:557d:95e7:21ea > 2a00:f480::3: ICMP6, echo request, seq 1, length 64 46 0x0000: 0015 c760 ac00 6400 6a58 b94f 86dd 6008 47 0x0010: 6eec 0040 3a40 2a00 f480 0008 0300 e2bb 48 0x0020: 557d 95e7 21ea 2a00 f480 0000 0000 0000 49 0x0030: 0000 0000 0003 8000 b18d 0005 0001 2de1 50 0x0040: 1964 0000 0000 94c1 0300 0000 0000 1011 51 0x0050: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 52 0x0060: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 53 0x0070: 3233 3435 3637 54 19:54:05.249091 IP6 2a00:f480::3 > 2a00:f480:8:300:e2bb:557d:95e7:21ea: ICMP6, echo reply, seq 1, length 64 55 0x0000: 6400 6a58 b94f 0015 c760 ac00 86dd 6008 56 0x0010: 6eec 0040 3a40 2a00 f480 0000 0000 0000 57 0x0020: 0000 0000 0003 2a00 f480 0008 0300 e2bb 58 0x0030: 557d 95e7 21ea 8100 b08d 0005 0001 2de1 59 0x0040: 1964 0000 0000 94c1 0300 0000 0000 1011 60 0x0050: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 61 0x0060: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 62 0x0070: 3233 3435 3637 63
- Запрос "who-has" отправлен на мультикаст-группу (solicited-node multicast address)
От разрешаемого адреса fe80::1 берутся младшие 24 бита -> 0x00 0x00 0x01
Старшие 104 бита — ff02::1:ff00:0000, в сумме: ff02::1:ff00:1
Ethernet multicast — младшие 32 бита + префикс: ff02::1:ff00:1 -> 33:33:ff:00:00:01
- Ответ содержит опцию "интерфейсный адрес назначения"
- Получатель ND-сообщений проверяет, что TTL=255, т. е. ни разу не был уменьшен маршрутизатором.
NDP поддерживается ядром Linux.
Маршрутизация между двумя сетями
Подключим ко второму интерфейсу маршрутизатора ещё одну машину.
- маршрутизатор:
удалённая машина сlient:
1 client:~# ip link set dev eth1 up 2 client:~# ip addr add dev eth1 2001:db8:0:b::400/64 3 client:~# ping -c1 fe80::2%eth1 4 PING fe80::2%eth1(fe80::2%eth1) 56 data bytes. 5 64 bytes from fe80::2%eth1: icmp_seq=1 ttl=64 time=0.864 ms 6 client:~# ping 2001:db8:0:a::56a 7 ping: connect: Network is unreachable 8 client:~# ip -6 route add default via fe80::2%eth1 9 client:~# ip -6 r 10 default via fe80::2 dev eth1 11 fe80::/64 dev eth1 proto kernel metric 256 pref medium 12
default — это такая сеть с нулевой сетевой маской ::/0 — т. е. весь Интернет. Такой записи соответствует вообще любой пакет.
Если адрес получателя в пакете отвечает сразу нескольким записям в таблице маршрутизации, выбирается запись с наибольшей сетевой маской (т. е. «самая определённая»)
Надо сделать ещё два действия:
Чтобы linux-машина router начала работать маршрутизатором, надо включить в ядре поддержку пересылки IP-пакетов
1 router:~# sysctl net.ipv6.conf.all.forwarding=1
- или, что то же самое:
1 router:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
Настроить маршрут на машине srv. Не будем добавлять default, а укажем более точный диапазон:
srv:~# ip -6 route add 2001:db8:0:b::/64 via fe80::2%eth1 srv:~# ip -6 r 2001:db8:0:a::/64 dev eth1 proto kernel metric 256 pref medium 2001:db8:0:b::/64 via fe80::2 dev eth1 metric 1024 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium srv:~# ping -c1 2001:db8:0:a::56a PING 2001:db8:0:a::56a (2001:db8:0:a::56a) 56(84) bytes of data. 64 bytes from 2001:db8:0:a::56a: icmp_seq=1 ttl=64 time=0.041 ms
Вторая запись в таблице означает: нам известно, что для посылки пакетов в сеть 2001:db8:0:b::/64 их надо направлять на интерфейс eth1 к fe80::2 (это маршрутизатор, он разберётся)
Простая табличная маршрутизация:
- Получаем пакет
- Просматриваем все записи в таблице, из них выбираем те, для которых адрес сети совпадает с адресом сети получателя пакета (если к нему применить соответствующую маску)
- Если настроен маршрут по умолчанию (с сетевой маской длины 0), он всегда подходит
- Среди подходящих записей выбирается та, что имеет самую длинную сетевую маску (т. е. в которой меньше абонентов)
- Если это запись вида «сеть dev интерфейс», обращаемся за адресом к ND-таблице соседей, если «сеть via адрес» — используем этот адрес
- Пересылаем пакет на найденный адрес
Целевая маршрутизация
Ранее мы работали с destination-based принцип табличной маршрутизации: «сеть получателя ⇒ маршрут».
Задача source-based маршрутизации: «свойства пакета отправителя ⇒ маршрут».
Linux: просто заведём несколько таблиц маршрутизации (разных), и будем обрабатывать пакет по правилам одной из них сообразно его свойствам:
- Адрес отправителя
- Порт получателя (или отправителя)
- Интерфейс, протокол и т. п. …
Команда ip -6 rule (немного документации)
Заготовка:
Два компьютера с выходом в интернет у каждого
- Маршрутизатор, подключённый к этим двум машинам по отдельным интерфейсам и третьей сетью для внутренних клиентов
Пример 1: подключаем два клиента ко внутренней сети, настраиваем source routing: с одного адреса пакеты в одну сторону, с другого — в другую
[router] # ip -6 route add default второй_сервер table какой-то-номер [router] # ip -6 rule add from «IP_B» table какой-то-номер
Пример 2: подключаем один клиент, перекидываем трафик по 80/443 портам в другую сторону
# ip -6 route add default второй_сервер table какой-то-номер # ip -6 rule add dport 80 table какой-то-номер
Получаем такую настройку:
1 [root@router ~]# ip -6 rule list
2 0: from all lookup local
3 32765: from all dport 80 lookup какой-то-номер
4 32766: from all lookup main
5 [root@router ~]# ip -6 route list
6 default via Сервер1 dev eth1
7 …
8 [root@router ~]# ip -6 route list table какой-то-номер
9 default via Сервер2 dev eth2
10
Правила в ip rule
- Просматриваются в порядке увеличения номера (приоритет 0 — наивысший)
Правило lookup приводит к поиску в соответствующей таблице
- Если этот поиск удачен, происходит маршрутизация
Например, правило с наивысшим приоритетом «0: from all lookup local» приводит к поиску в таблице local (посмотрите на неё), отражающей подключённые локальные сети. Если адрес не из локальной сети, lookup local ничего не находит,
Если правило lookup не нашло маршрута, поиск продолжается дальше
Приоритет правила можно задавать вручную, добавив в конце priority номер
Основная таблица — main, именно её показывает ip route (т. е. ip route list table main)
Разумеется, в обоих примерах на серверах надо дополнительно настраивать маршрут в клиентскую сеть через центральный маршрутизатор.
Д/З (потребует адаптации)
Изменения в образе: добавлен traceroute и ipcalc
ВНИМАНИЕ: адрес пересылки отчётов изменился на uneexlectures@cs.msu.ru
Задание 4
- Суть: объединить четыре компьютера тремя сетями по простой линейной схеме:
clone ←сеть3→ router2 ←сеть2→ router1 ←сеть1→ base
На машинах clone и base — по одному интерфейсу
На машинах router2 и router1 — два, там настроить маршрутизацию
Обеспечить доступность между clone и base
- Отчёт (выполнятся с нуля на ненастроенных машинах):
report 4 clone
- Настройка/поднятие интерфейса
- Дополнительные настройки маршрутизации (если нужны)
tcpdump -c4 (должен показать пинги) IPv6 note: как лучше избегать захвата лишних пакетов? ввести фильтр (icmp6 and 'ip6[40] = X')?
report 4 router2
- Настройка/поднятие двух интерфейсов
- Дополнительные настройки маршрутизации (если нужны)
report 4 router1
- Настройка/поднятие двух интерфейсов
- Дополнительные настройки маршрутизации (если нужны)
report 4 base (выполняется последним)
- Настройка/поднятие интерфейса
- Дополнительные настройки маршрутизации (если нужны)
ping -c4 адрес_clone (должен проходить)
Четыре отчёта (названия сохранить(должно быть: report.04.base, report.04.clone, report.04.router1, report.04.router2)) переслать одним письмом в качестве приложений на uneexlectures@cs.msu.ru