5.1 Основные положения IP Tunneling

5. IP Tunneling

5.1 Основные положения IP Tunneling

 IP-туннель — соединение между двумя разными сетями. Обычно сети по разным сторонам туннеля географически разнесены и не имеют собственного маршрута друг к другу, поэтому необходима транспортная сеть (такая как интернет например) для формирования туннеля и образования соединений через него.

IP туннелям необходим протокол туннелирования, который позволит создать защищённое или незащищённое соединение. Протоколы туннелирования могут зашифровывать данные для защиты не зашифрованной информации, передаваемой через публичные сети доступа, такое как Интернет, таким образом обеспечивая функциональность VPN. Для шифрования может использоваться IPSec (IP Security), который работает как в транспортном режиме, так и в туннельном.

Туннелирование IP пакетов

3-4-18

Пакет при попадании в туннель полностью (включая заголовок) инкапсулируется туннельным протоколом и пересылается к next hop’у по пути следования к конечной точке туннеля. В конечной точке туннеля пакет декапсулируется и отправляется в сеть назначения согласно содержимого оригинального IP заголовка. В качестве конечных устройств, стоящих туннель, в основном применяются маршрутизаторы. Находятся они , как правило, на границе между отправляющей/принимающей сетями и транспортной сетью.


 Требования к туннелям

  1. Необходимо создать и настроить туннельный интерфейс на конечных сторонах (маршрутизаторах) туннеля. Если настраивается GRE-туннель, то создаётся логический интерфейс gr-x/y/z, если настраивается IP-IP-туннель, то создаётся логический интерфейс ip-x/y/z. Данные интерфейсы являются software’ными. Каждый туннельный интерфейс является point-to-point, требует указания source — и destination-адресов туннеля. Можно создать несколько логических units для каждого GRE или IP-IP интерфейса, но на каждом unit’е можно настроить только один туннель.
  2. Конечные точки туннеля (маршрутизаторы) должны иметь маршрут для достижения друг друга (причём туннель не должен выступать в роли next-hop’а); все промежуточные устройства должны иметь маршрут к конечным точкам (маршрутизаторам) туннеля; конечные точки туннеля (маршрутизаторы) должны иметь маршрут, который направит трафик в туннель (next hop’ом для этого трафика будет являться туннельный интерфейс). Одна сплошная маршрутизация :-)

 Некоторые нюансы, касаемые туннелей

1). Keepalive. По-умолчанию конечная точка туннеля, а именно логический интерфейс ge или ip, не может отследить состояние, к котором находится интерфейс на другой стороне туннеля, и таким образом не уйдёт в состоянии down, когда туннельный интерфейс на другой стороне уйдёт в down. Таким образом любой маршрут, ассоциированный с эти интерфейсом остаётся в таблице маршрутизации не зависимо от того, находится ли туннель в рабочем состоянии или нет.

GRE имеет механизм keepalive для проверки состояния и доступности конечных интерфейсов туннеля:

[edit]
user@host# show
protocols {
     oam {
          gre-tunnel {
               interface gr-1/1/10.1 {
                    keepalive-time 10;
                    hold-time 30;
               }
          }
     }
}

Когда настраивается keepalive, то необходимо указать параметр «family inet» в «секции» [edit interfaces interface-name unit unit] туннельного интерфейса. Также стоит отметить, что параметр hold-time должен быть как минимум вдвое больше параметра keepalive-time.

GRE keepalives поддерживаются на маршрутизаторах M и MX серий.

Для тех же целей, что и keepalive, может использоваться Bidirectional Forwarding Detection (BFD), но о нём позже.

2). MTU. MTU (maximum transmission unit) — максимальный размер пакета, пересылаемый интерфейсом, и зависит от типа интерфейса. Протокол IP может вмещать различный MTU, позволяя маршрутизаторам фрагментировать пакет при необходимости. Устройства, получая фрагментированный пакет, собирают этот пакет заново (reassembling). Для Ethernet MTU как правило составляет 1500 байт.

Когда 2 устройства взаимодействуют по TCP, они определяют maximum segment size (MSS) — размер полезных данных без заголовков TCP (+ 20 байт) и без заголовка IP (+ ещё 20 байт), разрешённый через соединение между ними. Таким образом при MTU=1500 байт на интерфейсе, MSS должен быть не более 1460 байт для того, чтобы пакет не был фрагментирован при отправке через этот интерфейс.

При использовании GRE-туннеля, при инкапсуляции пакета в GRE, к нему будет добавлен заголовок GRE размером 4 байта + новый заголовок IP размером 20 байт (итого дополнительных 24 байта к пакету). Следовательно для того, чтобы пакет не был фрагментирован, необходимо установить размер maximum segment size (MSS) на туннельном интерфейсе, равный:

1500 — 20 (TCP header) — 20 (IP header) — 24 (GRE) = 1436 байт

а размер MTU на туннельном GRE интерфейсе: 1500 — 24 = 1476

для туннеля IP-IP это значение будет составлять:

1500 — 20 (TCP header) — 20 (IP header) — 20 (IP header) = 1440 байт

а размер MTU на туннельном IP-IP интерфейсе: 1500 — 20 = 1480

Если маршрутизатор получит пакет размером 1500 байт, который необходимо отправить в туннель и у этого пакета будет установлен бит don’t fragment (DF), то маршрутизатор отбросит этот пакет, т.к. после инкапсуляции этого пакета в GRE или IP-IP его MTU будет больше 1500 байт и не сможет быть передан через туннель.

Выходом из данной ситуации может служить команда clear-dont-fragment, которая будет сбрасывать бит don’t fragment (DF), и таким образом, пакеты превышающие после инкапсуляции размер MTU туннеля отбрасываться не будут, а будут фрагментироваться и отправляться в туннель.

Стоит отметить, что фрагментация пакетов отправляющей стороной и сборка их принимающей стороной расходует ресурсы устройств при выполнении этих действий.

3).  Для достижения конечных точек туннеля не может использоваться маршрут через сам туннель, иначе туннель станет неработоспособен.

К оглавлению

Добавить комментарий