Туннелирование и IPSec

«Определение»: инкапсуляция трафика внутрь специального сетевого протокола

Задачи:

• Организация общего адресного пространства
• Аутентификация и шифрование трафика целиком

Простейшее решение: использовать прикладной уровень:

1. Подключение и авторизация

   • Клиент                                           Сервер
     VPN-клиент ---> eth0: 5.6.7.8 ---> (Интернет) ---> eth0: 1.2.3.4 ---> VPN-сервер

2. Создание виртуальных сетевых tun или tap интерфейсов и настройка их как обычных сетевых карт:

   • Клиент                                           Сервер
     VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер
      |                                                                     |
     tun0: 192.168.10.2                                                    tun0: 192.168.10.1

3. Обмен данными через туннель:

   • 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):

1. Сокрытие трафика:

   • (нет): Authentication Header (AH)

   • (да): Encapsulating Security Payload (ESP)

2. Какой уровень протоколов защищаем:

   • (транспортный): 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

2. Между заголовком и контентом IP-пакета добавляется сам AH (с полем next=TCP)

3. В целях аутентификации вычисляется контрольная сумма всех полей, кроме тех, что меняются по дороге, а также контента (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`

2. Между заголовком и исходным IP-пакетом в неизменном виде вставляется сам AH (с полем next=IP)

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

   • ⇒ вычисляется контрольная сумма полей src_IP и dst_IP как IPSec-пакета, так и туннелируемого IP-пакета

Encapsulating Security Payload (ESP)

Шифрование и (по необходимости) аутентификация.

ESP + Transport

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета остаются неизменными, кроме:

   • proto=TCP → proto=ESP (50)

   • pkt_len=size → pkt_len=new_size

2. Далее следует ESP-секция, содержащая заголовок ESP, исходный TCP-пакет и метаданные TCP-пакета, в которой шифруется всё, кроме заголовка

   • ⇒ шифруются также метаданные, например поле next=TCP

3. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.

ESP + Tunnel

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета никого не интересуют, потому что они есть внутри туннелируемого контента; поле proto=ESP (50)

2. Далее следует ESP-секция, содержащая заголовок ESP, исходный IP-пакет и метаданные IP-пакета, в которой шифруется всё, кроме заголовка

   • ⇒ шифруются также метаданные, например поле next=IP

3. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей 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
• …