Сети операторов связи могут также предоставлять услуги виртуальных частных сетей на основе техники туннелирования. Эта техника уже рассматривалась нами на частном примере туннелирования трафика IPv6 через 1Р\4-сеть. Так как техника туннелирования весьма распространена, здесь мы рассмотрим ее с общих позиций.

Туннелирование у или инкапсуляция, - это нестандартный (отличающийся от принятого в модели OSI порядка) способ инкапсуляции пакетов некоторого протокола двух объединяемых сетей или узлов в пакеты протокола транзитной сети на ее границе и передача пакетов объединяемых сетей через транзитную сеть. Туннелирование применяется в тех случаях, когда транзитная сеть либо не поддерживает протокол объединяемых сетей, либо стремится изолировать транзитную сеть от объединяемых сетей.

Данное описание подходит к стандартной схеме, описанной в модели OSI, если под протоколом объединяемых сетей понимать протокол IP, а под протоколом транзитной сети - любой протокол канального уровня, например Ethernet. Действительно, IP-пакеты могут инкапсулироваться на границе сети в кадры Ethernet и передаваться в этих кадрах через транзитную сеть Ethernet в неизменном виде. А при выходе из транзитной сети IP-пакеты извлекаются из кадров Ethernet и дальше уже обрабатываются маршрутизатором.

Для того чтобы понять, в чем нестандартность инкапсуляции, сначала заметим, что в этом процессе принимают участие три типа протоколов:

• протокол-пассажир;
• несущий протокол;
• протокол инкапсуляции.

При стандартной работе составной сети, описанной в модели OSI (и повсеместно применяемой на практике), протоколом-«пассажиром» является протокол IP, а несущим протоколом - один из протоколов канального уровня отдельных сетей, входящих в составную сеть, например Frame Relay или Ethernet. Протоколом инкапсуляции также является протокол IP, для которого функции инкапсуляции описаны в стандартах RFC для каждой существующей технологии канального уровня.

При туннелировании протоколом-пассажиром является протокол объединяемых сетей, это может быть протокол канального уровня, не поддерживаемый транзитной сетью, или же протокол сетевого уровня, например протокол IPv6, отличный от протокола сетевого уровня транзитной сети.

На рис. 1 показан пример сети, в которой трафик сетей Frame Relay передается по туннелю через транзитную IP-сеть, канальный уровень которой эту технологию не поддерживает, так как построен на технологии Ethernet,

Рис. 1. Туннелирование трафика Frame Relay через ІР-сеть

Таким образом, протоколом-пассажиром является протокол а несущим протоколом - протокол IР. Пакеты протокола-пассажира помещаются в поле данных пакетов несущего протокола с помощью протокола инкапсуляции. Инкапсуляция FR-кaдpoв в IР-пакеты не является стандартной операцией для IР-маршрутизаторов. Это дополнительная для маршрутизаторов функция описывается отдельным стандартом и должна поддерживаться пограничными маршрутизаторами транзитной сети, если мы хотим организовать такой туннель.

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

В связи с популярностью Интернета и стека TCP/IP ситуация, когда несущим протоколом транзитной сети обычно выступает протокол IP, а протоколом-пассажиром - некоторый канальный протокол, является очень распространенной. Вместе с тем применяются и другие схемы инкапсуляции, такие как инкапсуляция IP в IP, Ethernet в MPLS, Ethernet в Ethernet. Подобные схемы инкапсуляции нужны не только для того, чтобы согласовать транспортные протоколы, но и для других целей, например для шифрования исходного трафика или для изоляции адресного пространства транзитной сети провайдера от адресного пространства пользовательских сетей.

Понадобилось мне тут на днях воспользоваться достаточно известным приемом, а именно - HTTP-туннелингом. О существовании решений, позволяющих создать TCP-соединение поверх HTTP-запросов, я знал давно, но на практике никогда не использовал. Как оказалось, это действительно неплохо работающий способ обойти файрвол и достучаться до внутренних хостов локальной сети через веб-сервер, который открыт «наружу».

Если ты сможешь залить на этот сервер специальный веб-сценарий, то с большой вероятностью получишь возможность обращаться к узлам из локальной сети этого сервера, которые при этом в инете не открыты! Любое подобное решение состоит из двух частей - клиента и сервера, которые инкапсулируют трафик в обычные HTTP GET- и POST-запросы и передают в таком виде данные между собой.

Данные при этом сжимаются, криптуются и кодируются в base64. Существует много реализаций подобного подхода, в том числе немало коммерческих. Опытные товарищи посоветовали две бесплатные разработки: reDuh (sensepost.com/labs/tools/pentest/reduh) и HTTPTunnel (). Мне приглянулась первая, так как ее серверная часть (та, которая заливается на веб-сервер) доступна в трех вариациях: на JSP, PHP и ASPX. В зависимости от того, какие технологии используются на веб-сервере, можно выбрать подходящий вариант.

Клиентская часть при этом написана на Java и, соответственно, может быть запущена под любой ОС. Итак, как это работает? Рассмотрим конкретный пример.

Допустим, пентестер Иван, проводя исследование, нашел в некотором вебсценарии уязвимость и может загрузить на сервер скрипт для HTTP-туннелинга.
При этом ему стало известно, что где-то внутри локалки находится RPD-сервер с названием хоста term-serv.victim.com , к которому нет доступа «снаружи» из-за файрвола. Брандмауэр пропускает к вебсерверу только HTTP-трафик и больше ничего. Подключиться к этому серверу и другим хостам из внутренней локальной сети Иван может с помощью HTTPтуннелинга. Это выглядит так:

1. Иван заливает на сервер скрипт reDuh.jsp, который становится доступным по некоторому адресу (пусть это будет ). Это серверная часть, и она не нуждается в настройке.

2. На локальной машине запускается клиентская часть reDuh - reDuhClient. Это консольное приложение, которому в качестве параметра для запуска передается адрес только что загруженного скрипта:

$ java reDuhClient ubunt00.victim.com 80 /uploads/reDuh.jsp

3. Указать адрес серверной части мало - необходимо еще отконфигурировать туннели с помощью админки, которая по умолчанию запускается на 1010 порту.
Ивану требуется пробросить локальный порт 1234 на порт 3389 (RPD) хоста termserv.victim.com , поэтому правило будет следующим:

1234:term-serv.victim.com:3389

4. Все, теперь если Иван подключится с помощью любого RDP-клиента к localhost:1234, то весь его TCP-трафик будет инкапсулироваться в HTTP-запросы, которые передаются на ubunt00.victim.com/uploads/reDuh.jsp , а оттуда уже переадресуются на целевой сервер. Таким образом, он получит желанный доступ к удаленному рабочему столу.

Тут надо сказать, что reDuh не ограничивает количество соединений, поэтому ты можешь создать несколько туннелей для разных хостов и разных сервисов (например, SSH) и использовать их одновременно! Ради интереса я попробовал еще и HTTPTunnel, которая оказалась не менее замечательной разработкой.
Ее большой плюс заключается в наличии специальной клиентской версии с удобным GUI-интерфейсом (только для Windows).

Серверная часть есть в двух вариантах: на PHP и Perl’е. При этом HTTPTunnel может работать в качестве SOCKS-сервера.

Соответственно, подключаясь к внутренним хостам (например, в том же самом RDP-клиенте), ты можешь сразу указывать внутренний адрес хостов для подключения (если возвращаться к нашему примеру, то это term-serv.victim.com ).

Но при этом надо предварительно позаботиться о том, чтобы в настройках программы был прописан локальный SOCKS, созданный HTTPTunnel. На случай, если какое-то приложение не поддерживает работу через прокси, его трафик можно принудительно соксофицировать с помощью FreeCap (freecap.ru), tsocks () или любых других аналогичных приложений.

IP protocol был разработан для самых различных типов подключений, и хотя максимальная длина для IP datagram составляет 64K, большинство подключений (transmission links) используют меньший максимальный размер для IP-пакета или MTU.
MTU, Maximum Transmission Unit - максимальный размер блока в байтах, который может быть передан на канальном уровне сетевой модели OSI.

Значение MTU зависит от типа подключения. Дизайн IP сетей допускает возможность фрагментирования IP пакетов в том случае когда MTU меньше размера пакета, - в этом случае принимающая станция вновь собирает искомый пакет из фрагментов.

На рисунке отображен заголовок IP пакета и то, как он инкапсулируется в датаграмму второго уровня.
Здесь важно отметить, что в поле FLAGS включает в себя три бита, один из которых "don"t fragment" (DF) bit , который определяет разрешено данный пакет фрагментировать или нет.

Вопросы с IP фрагментированием

Хотя фрагментация пакета выполняется достаточно быстро, обратная сборка исходного пакета требует значительных ресурсов: затрат памяти, вопросы быстродействия.
В случае потери одного из фрагментов вся датаграмма должна быть передана заново.
Фрагметы очень тяжело обрабатывать на брендмауэрах (с 4-го по 7 уровень), при неправильной последовательности они будут забракованы.

TCP MSS и избегание дефрагментации

TCP Maximum Segment Size (MSS) - определяет максимальный размер датаграммы TCP/IP, которую будет принимать данный хост.
Датаграмма TCP/IP может быть фрагментирована на уровне IP.
Значение MSS отсылается внутри TCP header только в сегментах TCP SYN. Каждая сторона TCP соединения объявляет другой стороне свое значение MSS.
Вопреки распространенному мнению, значение MSS не согласовывается между хостами, - у каждого хоста они могут оставаться разными, только отсылающий хост отдает сегменты размером не больше, чем требует принимающий хост.

Таким образом TCP MSS позволяет избежать фрагментации на уровне двух участников сессии TCP. Но TCP MSS не может обработать тот случай, когда по пути между хостами есть меньший MTU.

PMTUD

PMTUD (Path Maximum Transmission Unit Discovery) - был разработан для избегания фрагментации по пути между хостами. PMTUD используется для автоматического определения минимального MTU вдоль пути пакета между хостами.

PMTUD поддерживается только TCP, UDP и другие протоколы не поддерживают PMTUD.

Хост отсылает нефрагментированный пакет с установленным DF bit . Если маршрутизатор пытается отдать пакет на link, с меньшей MTU чем этот пакет, маршрутизатор дропнет этот пакет и возвратит сообщение ICMP "Destination Unreachable", с кодом "fragmentation needed and DF set" (type 3, code 4). Когда Хост-источник получает эту информацию, он понижает MSS и затем пересылает TCP сегмент заново.

Наиболее часто встречающаяся проблема с PMTUD - это среда в которой не пропускается сообщения ICMP

Где актуально использование PMTUD

Как уже было сказано, PMTUD нужен в случаях, когда по пути от хоста А к хосту Б встречаются линки с меньшими значениями MTU.
Наиболее общие примеры:
- PPPoE (часто используемый вместе с ADSL) использует 8 bytes для своего заголовка. Это уменьшает эффективное значение MTU для Ethernet до 1492 (1500 - 8).
- Туннельный протоколы GRE, IPsec, and L2TP также используют пространство для своих заголовков, что также уменьшает эффективное MTU на исходящем интерфейсе.

Вообще Path MTU Discovery (RFC 1191) осуществляется всеми клиентами включая Windows 2000/2003/XP/7/8.
Для нормальной работы PMTUD необходимо, чтобы пропускался протокол ICMP, в частности должны пропускаться сообщения ICMP "unreachable" и "time-exceeded".

Для проверки можно использовать утилиту mturoute.exe. Утилита отрабатывает аналогично PMTUD и возвращает значение MTU, которое необходимо использовать на данном хосте.

Текущее значение MTU можно увидеть через команды:
Windows 7, Windows Vista: netsh interface ipv4 show subinterfaces
Windows XP: netsh interface ip show interface

Значения MTU для локальной машины можно поменять и вручную (хотя и не рекомендуется)
Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems
Также можно использовать утилиту Set MTU, поставляемой с Cisco Systems VPN Client.

Что такое туннель

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

Туннель состоит из основных компонентов:
- Passenger protocol
- Carrier protocol . Протокол, осуществляющий инкапсуляцию:
GRE
IP in IP tunnels
- Transport protocol . Протокол отвечающий за маршрутизацию encapsulated protocol. В нашем случае это IP.

На приведенном рисунке IP у нас выступает как transport protocol и как passenger protocol .

Инкапсуляция трафика дает следующие преимущества:

• Endpoints могут использовать private addresses
• Позволяет строить VPN поверх WAN сетей
• Возможность использования шифрования

Исходя из того, что наиболее "тяжелый" вариант - это одновременное использование GRE и IPsec, рекомендации будут следующие:
- PMTUD позволяет установить на GRE интерфейсе оптимальное значение MTU и включается на туннельном интерфейсе командой tunnel path-mtu-discovery
- Обеспечьте нормальную работу PMTUD, при этом на обоих целевых хостах должна успешно выполняться mturoute.exe
- Также рекомендуется одновременно использовать и команду ip mtu 1400 . В этом случае ip mtu будет обеспечивать пространство для GRE + IPSec, в случае же более низких значениях MTU по пути, IP MTU бует подкорректировано динамически. Значение 1400 рекомендовано, т.к. оно покрывает большинство возможных комбинаций GRE + IPSec.
- Следует использовать ip tcp adjust-mss 1360 на туннельном интерфейсе. Это позволит маршрутизатору уменьшить значение TCP MSS в TCP SYN Packet. Что позволить двух конечным хостам генерировать достаточно малые пакеты. (1360 = 1400 - 20(TCP) - 20 (IP))

Общий конфиг для туннельного интефейса DMVPN + IPSec будет выглядеть:
interface Tunnel200
description ### DMVPN TUNNEL HUB
ip address 10.5.0.1 255.255.255.0
no ip redirects
ip mtu 1400
tunnel path-mtu-discovery
ip nbar protocol-discovery
ip hold-time eigrp 1 35
no ip next-hop-self eigrp 1
ip flow ingress
ip flow egress
ip nhrp authentication baurus
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip tcp adjust-mss 1360
no ip split-horizon eigrp 1
delay 100000
tunnel source 87.237.40.107
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile DMVPN

Процесс, в ходе которого создается защищенное логическое соединение между двумя конечными точками посредством инкапсуляции различных протоколов. Туннелирование представляет собой метод построения сетей, при котором один сетевой протокол инкапсулируется в другой. От обычных многоуровневых сетевых моделей (таких как OSI или TCP/IP) туннелирование отличается тем, что инкапсулируемый протокол относится к тому же или более низкому уровню, чем используемый в качестве тоннеля.

Суть туннелирования состоит в том, чтобы «упаковать» передаваемую порцию данных, вместе со служебными полями, в новый «конверт» для обеспечения конфиденциальности и целостности всей передаваемой порции, включая служебные поля. Туннелирование может применяться на сетевом и на прикладном уровнях. Комбинация туннелирования и шифрования позволяет реализовать закрытые виртуальные частные сети. Туннелирование обычно применяется для согласования транспортных протоколов либо для создания защищённого соединения между узлами сети.

Типы протоколов

В процессе инкапсуляции (туннелирования) принимают участие следующие типы протоколов:

1. транспортируемый протокол;
2. несущий протокол;
3. протокол инкапсуляции.

Протокол транзитной сети является несущим , а протокол объединяемых сетей - транспортируемым . Пакеты транспортируемого протокола помещаются в поле данных пакетов несущего протокола с помощью протокола инкапсуляции. Пакеты-«пассажиры» не обрабатываются при транспортировке их по транзитной сети никаким образом. Инкапсуляцию выполняет пограничное устройство (маршрутизатор или шлюз), которое находится на границе между исходной и транзитной сетями. Извлечение пакетов транспортируемого протокола из несущих пакетов выполняет второе пограничное устройство, расположенное на границе между транзитной сетью и сетью назначения. Пограничные устройства указывают в несущих пакетах свои адреса, а не адреса узлов в сети назначения.

Согласование транспортных протоколов

Туннель может быть использован, когда две сети с одной транспортной технологией необходимо соединить через сеть, использующую другую транспортную технологию. При этом пограничные маршрутизаторы , которые подключают объединяемые сети к транзитной, упаковывают пакеты транспортного протокола объединяемых сетей в пакеты транспортного протокола транзитной сети. Второй пограничный маршрутизатор выполняет обратную операцию.

Обычно туннелирование приводит к более простым и быстрым решениям по сравнению с трансляцией, так как решает более частную задачу, не обеспечивая взаимодействия с узлами транзитной сети.

Основные компоненты туннеля

Основными компонентами туннеля являются:

• инициатор туннеля;
• маршрутизируемая сеть;
• туннельный коммутатор;
• один или несколько туннельных терминаторов.

Инициатор туннеля встраивает (инкапсулирует) пакеты в новый пакет, содержащий наряду с исходными данными новый заголовок с информацией об отправителе и получателе. Несмотря на то, что все передаваемые по туннелю пакеты являются пакетами IP, инкапсулируемые пакеты могут принадлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов. Маршрут между инициатором и терминатором туннеля определяет обычная маршрутизируемая сеть , которая может быть и сетью, отличной от Internet . Терминатор туннеля выполняет процесс, который является обратным инкапсуляции - он удаляет новые заголовки и направляет каждый исходный пакет в локальный стек протоколов или адресату в локальной сети. Инкапсуляция сама по себе никак не влияет на защищенность пакетов сообщений, передаваемых по туннелю VPN . Но инкапсуляция даёт возможность полной криптографической защиты инкапсулируемых пакетов. Конфиденциальность инкапсулируемых пакетов обеспечивается путем их криптографического закрытия, т. е. зашифровывания, а целостность и подлинность - путем формирования цифровой подписи . Так как существует множество методов криптозащиты данных, необходимо чтобы инициатор и терминатор туннеля использовали одни и те же методы и могли согласовывать друг с другом эту информацию. Более того, для возможности расшифровывания данных и проверки цифровой подписи при приеме инициатор и терминатор туннеля должны поддерживать функции безопасного обмена ключами. Чтобы туннели VPN создавались только между уполномоченными пользователями, конечные стороны взаимодействия требуется аутентифицировать.

Ссылки

• Стратегии межсетевого взаимодействия: инкапсуляция (туннелирование) протоколов

Wikimedia Foundation . 2010 .

Смотреть что такое "Туннелирование (компьютерные сети)" в других словарях:

У этого термина существуют и другие значения, см. Инкапсуляция. Инкапсуляция в компьютерных сетях это метод построения модульных сетевых протоколов, при котором логически независимые функции сети абстрагируются от нижележащих механизмов… … Википедия

Анонимные сети компьютерные сети, созданные для достижения анонимности в Интернете и работающие поверх глобальной сети. Специфика таких сетей заключается в том, что разработчики вынуждены идти на компромисс между степенью защиты и лёгкостью … Википедия

Туннелирование - способ инкапсуляции произвольных пакетов одного протокола в какой-либо другой транспортный протокол. Для упрощения конфигурирования туннелирование реализовано в виде виртуального (логического) интерфейса. При этом привязки к конкретным протоколам, пропускаемым через туннель, не делается, туннель реализован более как архитектура, позволяющая реализовать любую стандартную схему инкапсуляции.

Рис. 1

Туннельные линки являются poin-to-point линками. Туннелирование состоит из следующих трех компонентов:

• Протокол-"пассажир", который инкапсулируется в туннель, например AppleTalk, CLNS, IP, and IPX.
• Протокол носитель - протокол, который выполняет инкапсуляцию, например GRE, IP-in-IP, L2TP, MPLS, STUN, и DLSw+.
• Транспортный протокол, - протокол, используемый для переноса инкапсулированного протокола. Основной транспортный протокол - это IP.

Рассмотри для примера соединение двух сетей AppleTalk через IP-опорную сеть.

Рис 2. Обход ограничений роутингового протокола.

Большой траффик, создаваемый широковещательными анонсами роутингового протокола RTMP может существенно ухудшить работу опорной сети. Проблема может быть решена туннелированием AppleTalk через IP. Туннелирование инкапсулирует пакеты AppleTalk внутри IP-пакета, который пересылается по опорной сети непосредственно в точку назначения. Роутер в точке назначения "вынимает" пакет AppleTalk из капсулы и передает его в сеть AppleTalk обычным образом. Поскольку пакеты AppleTalk отправляются непосредственно в точку назначения, отсутствует расход полосы пропускания сети на широковещательные анонсы протокола AppleTalk.

Ограничения в реализации туннелирования

Нижеследующее нужно иметь в виду при планировании туннелей:

• В ранних версиях IOS, инкапсуляция и декапсуляция пакетов в конечных точках туннеля производилось процессором (process-switching). Однако, начиная с версии 11.1 реализована обработка (fast-switching) для туннелей GRE. В сегодняшних версиях IOS используется CEF-коммутация для IPv6 и других туннелирующих протоколов.
• Важно разрешать туннельному протоколу проходить через фаревол и через листы доступа
• Роутинговые протоколы, в метрике которых содержится только число промежуточных узлов будут, как правило, предпочитать туннельные линки, так как с точки зрения такого протокола они выглядят существенно короче реальных. Это может оказаться нежелательным, поскольку туннель выглядит как один хоп и может проходить по более медленному каналу связи, чем по линку с промежуточными узлами.

Рис. 3

В топологии, показанной на рис.3 пакеты от Host1 до Host2 пойдут по пути w,q,z, вместо пути w,x,y,z. Потому что первый путь покажется короче.

Существенно худшие проблемы возникают, если информация о роутинге транспортной сети смешивается с информацией о роутинге туннелируемой сети. В этом случае "лучший" путь к точке окончания туннеля (для транспортного протокола) может оказаться через сам туннель! Это называется рекурсивным роутингом (recursive route) и в этом случае роутер временно выключает туннель. Чтобы избежать рекурсивного роутинга, принимайте меры к разделению роутинговой информации "пассажирской" и "транспортной" сетей:

1. Используйте другой номер AS или маркер
2. Используйте другой протокол роутинга
3. Используйте явное указание статических путей (следите, чтобы не получалось петель роутинга)

Если роутер выдает нижеприведенное сообщение, то, скорее всего, имел место рекурсивный роутинг
%TUN-RECURDOWN Interface Tunnel 0 temporarily disabled due to recursive routing

Преимущества туннелирования

В следующих ситуациях полезно применения туннелей:

• Для поддержки многопротокольных локальных сетей с помощью однопротокольной опорной сети
• Для обхода ограничений ряда роутинговых протоколов (например: по числу промежуточных станций на пути пакета). См. Рис. 2
• Для соединения разнесенных подсетей
• Для организации виртуальных приватных сетей (VPN) поверх глобальных сетей (WAN)

Процесс конфигурирования GRE-туннеля

Обязательные действия:

• Указание точки начала туннеля
• Указание точки приемника туннеля

Необязательные действия:

• Задание режима туннелирования
• Задание режима контрольного суммирования
• Задание ключа идентификации туннеля
• Включение отбрасывания "заблудившихся" пакетов

Задание туннельного интерфейса
interface tunnel number
Указание точки начала туннеля
tunnel source {ip-address | type number}
Указание точки приемника туннеля
tunnel destination {hostname | ip-address}
Пример конфигурации роутеров изображенных на Рис 3

Конфигурация роутера A

interface Tunnel0
ip address 192.168.1.1 255.255.255.252
tunnel mode gre
tunnel source FastEthernet0/0
tunnel destination 172.16.15.34
!
interface FastEthernet0/0
ip address 10.0.145.13 255.255.255.0

Конфигурация роутера D

interface Tunnel0
ip address 192.168.1.2 255.255.255.252
tunnel mode gre
tunnel source FastEthernet1/0
tunnel destination 10.0.145.13
!
interface FastEthernet1/0
ip address 172.16.15.34 255.255.255.0 Режим туннелирования GRE всегда включен по умолчанию, поэтому команду tunnel mode gre можно опустить.