С каждым разом статьи становятся все больше, а почерк размашистей :) В этот раз я решил разделить тему настройки GRE Туннелей, а так же их защиту с помощью IPSec на две части – теоретическую и практическую. Если вы пришли сюда из поисковых систем и сразу собираетесь бросаться в омут с головой, то можете непосредственно перейти к настройке GRE over IPSec с применением IPSec профилей и crypto map.
Туннели
В интерпретации Cisco туннель – это логический интерфейс, роль которого состоит в том, чтобы инкапсулирование пакеты одного протокола (passenger protocol), с помощью второго (carrier protocol) и передать его по третьему (transport protocol). В роли протокола, который занимается инкапсуляцией могут выступать такие протоколы как GRE, IPIP. GRE (Generic Routing Encapsulation) – протокол, который в отличии от IPIP, позволяет инкапсулировать в себя другие протоколы, такие как AppleTalk, IP, IPX и другие. Лишь бы ethertype был правильным.
Пакет, попавший в туннель с инкапсуляцией GRE, будет выглядеть следующим образом:
Заголовок GRE может варьироваться от 4 до 16 байт в зависимости от того какие опции включены.
- C, K и S в заголовке это опции, говорящие следует ли ожидать поля с контрольной суммой (checksum), ключом (key) и номер последовательности (sequence number)
- ver – номер версии GRE (0)
- Protocol – ethertype инкапсулируемого протокола
- Checksum – контрольная сумма (опциональна)
- Key – ключ безопасности туннеля (опционален)
- Sequence number – номер последовательности (опционален)
По умолчанию все опции отключены и заголовок равен 4 байтами. Остальные опции можно включить в процессе конфигурации туннельного интерфейса:
Rx(config)#int tunnel #_number Rx(config-if)#tunnel checksum Rx(config-if)#tunnel key [0-4294967295] Rx(config-if)#tunnel sequence-datagrams
Пакет, попавший в IPIP туннель, будет выглядеть точно так же, только без заголовка GRE. По понятным причинам в качестве passenger protocol в IPIP туннеле может выступать только IP.
Чем же так хороши туннели?
- Например, когда ваши площадки используют приватные адреса и их надо объединить через Интернет.
- Позволяют объединять мультипротокольные сети, что уже не очень актуально.
- Ну, и самое главное, позволяют шифровать информацию, передаваемую через сети с низким уровнем доверия, в комбинации с IPSec.
Причем, в отличии от чистого IPSec, по такому каналу можно передавать не только unicast трафик, но и broadcast с multicast. Последний делает возможным работу протоколов динамической маршрутизации. Такие VPN являются постоянно доступными (always on), а не только когда существуют данные, попадающие под crypto ACL.
А проблемы?
- Recursive routing – когда протокол маршрутизации начинает считать, что использовать туннель до удаленного хоста выгоднее, чем реальный путь. Решается этот вопрос либо статическими маршрутами, либо процессом маршрутизации, отличным от используемого на WAN интерфейсах.
- IP Fragmentation
MTU и IP Fragmentation
MTU (Maximum Transfer Unit) указывает на максимальный размер информации в байтах, которая может быть передана. Для ethernet это 1500 байт, если не принимать во внимание Jumbo Frames. MSS или Maximum Segment Size – это максимальный размер передаваемого TCP сегмента и обычно равен 1460 байтам (1500 – 20 байт заголовка IP – 20 байт заголовка TCP).
Но тут в дело вступают туннели. Как я уже говорил, GRE добавляет свой заголовок (4 байта) и новый IP заголовок (20 байт), соответственно MTU на туннельном интерфейсе нужно уменьшить до 1476 байт в случае GRE и до 1480 в случае IPIP. Сделать это можно вручную или с помощью PMTUD – path MTU discovery.
Так же не стоит забывать о накладных расходах IPSec, в случае если мы решим шифровать данные попадающие в туннель. В худшем случае накладные расходы для IPSec, вдобавок к тем 24 байтам от GRE, будут выглядеть следующим образом:
| Transform set | Накладные расходы, байт |
| esp AES + hash | 73 |
| esp AES | 61 |
| esp DES, 3DES | 45 |
| esp DES, 3DES + hash | 57 |
| esp NULL + hash | 45 |
| NAT-T | 8 |
| ah + hash | 44 |
Сама Cisco рекомендует устанавливать MTU в 1400 байт вне зависимости от того работает GRE поверх IPSec в туннельном или в транспортном режиме. Делается это так:
Rx(config)# interface interface Rx(config-if)# ip mtu size
При использования VTI и чистых IPSec туннелей происходит префрагментация трафика до того, как он будет зашифрован.
Path MTU Discovery (PMTUD)
Основная проблема в ручной настройке MTU и/или MSS состоит в том, что по пути между вашими площадками может оказаться линк с MTU, скажем, 1300. Тут на помощь может придти PMTUD. Протокол целиком и полностью полагается на ICMP unreachable messages, которые должны быть разрешены на всем пути между соседями.
На GRE туннели он включается следующим образом:
Rx(config)# interface tunnel #_number Rx(config-if)# tunnel path-mtu-discovery
Работу PMTUD можно лицезреть с помощью команды debug tunnel.
