Туннелирование и 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
- Паразитная нагрузка (поля транспортного и прикладного уровней)
- Примеры: vtun, OpenVPN, …

Использовать сетевой уровень ( «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

Виртуальные машины с GRE-туннелем: одна, другая, маршрутизатор (замена интернету) .

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
…

LecturesCMC/UnixFirewalls2014/11_Tunneling (последним исправлял пользователь FrBrGeorge 2014-05-22 11:41:54)