⇤ ← Версия 1 от 2014-05-17 13:26:42
4587
Комментарий:
|
10275
|
Удаления помечены так. | Добавления помечены так. |
Строка 83: | Строка 83: |
=== IPSec === Базовая статья: [[http://www.unixwiz.net/techtips/iguide-ipsec.html|An Illustrated Guide to IPsec]], смотреть на картинки обязательно. * Происхождение: IPv6. * Назначение: «прозрачный» IP с аутентификацией и шифрованием * ⇒ универсальность * ⇒ задача: аутентификация * ⇒ задача: шифрование * ⇒ свойство: сохранение (по возможности) исходных IP-полей * Использование различных алгоритмов шифрования (как стороны договорятся) * Протокол обмена ключами с множеством вариантов использования Четыре вида (2×2): 1. Сокрытие трафика: * ('''нет'''): Authentication Header (AH) * ('''да'''): Encapsulating Security Payload (ESP) 1. Какой уровень протоколов защищаем: * ('''транспортный'''): Transport Mode * ('''сетевой'''): Tunnel Mode ==== Authentication Header (AH) ==== Только аутентификация (контрольные суммы), все IP-поля, по возможности, сохраняются ===== AH + Transport ===== Структура IPSec-пакета (на примере TCP-контента): 1. Поля IP-пакета остаются неизменными, кроме: * `proto=TCP` → `proto=AH` (51) * `pkt_len=size` → `pkt_len=size+AH_size` 1. Между заголовком и контентом IP-пакета добавляется сам AH (с полем `next=TCP`) 1. В целях аутентификации вычисляется контрольная сумма ''всех'' полей, кроме тех, что меняются по дороге, а также контента (TCP-пакета) * ⇒ вычисляется контрольная сумма полей `src_IP` и `dst_IP` ## Будет время, нарисую упрощённую картинку ===== AH + Tunnel ===== Структура IPSec-пакета (на примере TCP-контента): 1. Поля IP-пакета остаются неизменными, кроме: * `proto=TCP` → `proto=AH` (51) * `pkt_len=size` → `pkt_len=size+AH_size+IP_header_size`` 1. Между заголовком и исходным IP-пакетом в неизменном виде вставляется сам AH (с полем `next=IP`) 1. В целях аутентификации вычисляется контрольная сумма ''всех'' полей, кроме тех, что меняются по дороге, а также контента (IP-пакета) * ⇒ вычисляется контрольная сумма полей `src_IP` и `dst_IP` как IPSec-пакета, так и туннелируемого IP-пакета ## Будет время, нарисую упрощённую картинку ==== Encapsulating Security Payload (ESP) ==== Шифрование и ([[http://link.springer.com/chapter/10.1007%2F11761679_2|по необходимости]]) аутентификация. ===== ESP + Transport ===== Структура IPSec-пакета (на примере TCP-контента): 1. Поля IP-пакета остаются неизменными, кроме: * `proto=TCP` → `proto=ESP` (50) * `pkt_len=size` → `pkt_len=new_size` 1. Далее следует ESP-секция, содержащая заголовок ESP, исходный TCP-пакет и метаданные TCP-пакета, в которой шифруется всё, кроме заголовка * ⇒ шифруются также метаданные, например поле `next=TCP` 1. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма ''всей'' ESP-секции. ===== ESP + Tunnel ===== Структура IPSec-пакета (на примере TCP-контента): 1. Поля IP-пакета никого не интересуют, потому что они есть внутри туннелируемого контента; поле `proto=ESP` (50) 1. Далее следует ESP-секция, содержащая заголовок ESP, исходный IP-пакет и метаданные IP-пакета, в которой шифруется всё, кроме заголовка * ⇒ шифруются также метаданные, например поле `next=IP` 1. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма ''всей'' ESP-секции. ==== «And the winner is… oops… er… never mind» ==== Вывод: в жизни можно использовать только ESP и лучше в туннельном виде: * AH не совместим с NAT вида «много→один» * ESP+Transport требует настройки IPSec на всех абонентах сети Ну, и чем это лучше других туннелей? === Виды VPN (первый заход) === * «Old Windows style»: PPP+GRE * «New Windows style»: ipsec+l2tp * OpenVPN * … |
Туннелирование и IPSec
«Определение»: инкапсуляция трафика внутрь специального сетевого протокола
Задачи:
- Организация общего адресного пространства
- Аутентификация и шифрование трафика целиком
Простейшее решение: использовать прикладной уровень:
- Подключение и авторизация
Клиент Сервер VPN-клиент ---> eth0: 5.6.7.8 ---> (Интернет) ---> eth0: 1.2.3.4 ---> VPN-сервер
- Создание виртуальных сетевых tun или tap интерфейсов и настройка их как обычных сетевых карт:
Клиент Сервер VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер | | tun0: 192.168.10.2 tun0: 192.168.10.1
- Обмен данными через туннель:
VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер | | tun0: 192.168.10.2 <-- (Пакет для 102.168.10.1) … <-- tun0: 192.168.10.1
На всем протяжении пути от 5.6.7.8 до 1.2.3.4 пакет не меняется.- TCP over TCP ⇒ использование UDP
- Паразитная нагрузка (поля транспортного и прикладного уровней)
Использовать сетевой уровень ( «IP over IP») :
- Параметры виртуального сетевого интерфейса: собственный IP-адрес и IP-адреса концов туннеля
Всякий попавший в tun0 пакет инкапсулируется в IP-пакет (например, протокола GRE) с адресами конца туннеля, а этот пакет маршрутизируется
- Проблемы с NAT вида «много в один»
- Шифрование и аутентификация отсутствуют
Пример: настройка GRE-тоннеля
- На одной стороне:
# ip a show dev enp0s8 2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 08:00:27:4c:12:2a brd ff:ff:ff:ff:ff:ff inet 10.30.50.3/24 brd 10.30.50.255 scope global enp0s8 inet6 fe80::a00:27ff:fe4c:122a/64 scope link valid_lft forever preferred_lft forever # ip tunnel add tun mode gre remote 10.50.70.3 local 10.30.50.3 # ip a a 192.168.0.30/24 dev tun # ip l set up dev tun [root@uneexclient ~]# ip a show dev tun 5: tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN link/gre 10.30.50.3 peer 10.50.70.3 inet 192.168.0.30/24 scope global tun inet6 fe80::5efe:a1e:3203/64 scope link valid_lft forever preferred_lft forever
На другой строне:# ip a show dev enp0s8 2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 08:00:27:d8:46:fd brd ff:ff:ff:ff:ff:ff inet 10.50.70.3/24 brd 10.50.70.255 scope global enp0s8 inet6 fe80::a00:27ff:fed8:46fd/64 scope link valid_lft forever preferred_lft forever # ip tunnel add tun mode gre remote 10.30.50.3 local 10.50.70.3 # ip a a 192.168.0.50/24 dev tun # ip a show dev tun 5: tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN link/gre 10.50.70.3 peer 10.30.50.3 inet 192.168.0.50/24 scope global tun inet6 fe80::5efe:a32:4603/64 scope link valid_lft forever preferred_lft forever # ping 192.168.0.30 PING 192.168.0.30 (192.168.0.30) 56(84) bytes of data. 64 bytes from 192.168.0.30: icmp_req=1 ttl=64 time=1.54 ms … # traceroute -n 192.168.0.30 traceroute to 192.168.0.30 (192.168.0.30), 30 hops max, 60 byte packets 1 192.168.0.30 1.145 ms 1.145 ms 1.195 ms
IPSec
Базовая статья: An Illustrated Guide to IPsec, смотреть на картинки обязательно.
- Происхождение: IPv6.
- Назначение: «прозрачный» IP с аутентификацией и шифрованием
- ⇒ универсальность
- ⇒ задача: аутентификация
- ⇒ задача: шифрование
- ⇒ свойство: сохранение (по возможности) исходных IP-полей
- Использование различных алгоритмов шифрования (как стороны договорятся)
- Протокол обмена ключами с множеством вариантов использования
Четыре вида (2×2):
- Сокрытие трафика:
(нет): Authentication Header (AH)
(да): Encapsulating Security Payload (ESP)
- Какой уровень протоколов защищаем:
(транспортный): Transport Mode
(сетевой): Tunnel Mode
Authentication Header (AH)
Только аутентификация (контрольные суммы), все IP-поля, по возможности, сохраняются
AH + Transport
Структура IPSec-пакета (на примере TCP-контента):
- Поля IP-пакета остаются неизменными, кроме:
proto=TCP → proto=AH (51)
pkt_len=size → pkt_len=size+AH_size
Между заголовком и контентом IP-пакета добавляется сам AH (с полем next=TCP)
В целях аутентификации вычисляется контрольная сумма всех полей, кроме тех, что меняются по дороге, а также контента (TCP-пакета)
⇒ вычисляется контрольная сумма полей src_IP и dst_IP
AH + Tunnel
Структура IPSec-пакета (на примере TCP-контента):
- Поля IP-пакета остаются неизменными, кроме:
proto=TCP → proto=AH (51)
pkt_len=size → pkt_len=size+AH_size+IP_header_size`
Между заголовком и исходным IP-пакетом в неизменном виде вставляется сам AH (с полем next=IP)
В целях аутентификации вычисляется контрольная сумма всех полей, кроме тех, что меняются по дороге, а также контента (IP-пакета)
⇒ вычисляется контрольная сумма полей src_IP и dst_IP как IPSec-пакета, так и туннелируемого IP-пакета
Encapsulating Security Payload (ESP)
Шифрование и (по необходимости) аутентификация.
ESP + Transport
Структура IPSec-пакета (на примере TCP-контента):
- Поля IP-пакета остаются неизменными, кроме:
proto=TCP → proto=ESP (50)
pkt_len=size → pkt_len=new_size
- Далее следует ESP-секция, содержащая заголовок ESP, исходный TCP-пакет и метаданные TCP-пакета, в которой шифруется всё, кроме заголовка
⇒ шифруются также метаданные, например поле next=TCP
Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.
ESP + Tunnel
Структура IPSec-пакета (на примере TCP-контента):
Поля IP-пакета никого не интересуют, потому что они есть внутри туннелируемого контента; поле proto=ESP (50)
- Далее следует ESP-секция, содержащая заголовок ESP, исходный IP-пакет и метаданные IP-пакета, в которой шифруется всё, кроме заголовка
⇒ шифруются также метаданные, например поле next=IP
Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.
«And the winner is… oops… er… never mind»
Вывод: в жизни можно использовать только ESP и лучше в туннельном виде:
- AH не совместим с NAT вида «много→один»
- ESP+Transport требует настройки IPSec на всех абонентах сети
Ну, и чем это лучше других туннелей?
Виды VPN (первый заход)
- «Old Windows style»: PPP+GRE
- «New Windows style»: ipsec+l2tp
- OpenVPN
- …