Протокол туннелирования - Tunneling protocol

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

В компьютерная сеть, а протокол туннелирования это протокол связи что позволяет перемещать данные из одной сети в другую. Это предполагает разрешение частная сеть сообщения, которые будут отправлены через общедоступную сеть (например, Интернет ) через процесс, называемый инкапсуляция.

Поскольку туннелирование включает переупаковка данные о трафике в другую форму, возможно, с шифрование как правило, он может скрывать характер трафика, проходящего через туннель.

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

Использует

Протокол туннелирования может, например, позволить стороннему протоколу работать в сети, которая не поддерживает этот конкретный протокол, например IPv6 над IPv4.

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

Обход политики брандмауэра

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

Другой метод туннелирования на основе HTTP использует Метод / команда HTTP CONNECT. Клиент выдает команду HTTP CONNECT прокси-серверу HTTP. Затем прокси устанавливает TCP-соединение с определенным сервером: портом и передает данные между этим сервером: портом и клиентским соединением.[1] Поскольку это создает брешь в безопасности, прокси-серверы HTTP с поддержкой CONNECT обычно ограничивают доступ к методу CONNECT. Прокси-сервер разрешает подключения только к определенным портам, например 443 для HTTPS.[2]

Технический обзор

В качестве примера сетевого уровня поверх сетевого уровня, Универсальная инкапсуляция маршрутизации (GRE), протокол, работающий через IP (Номер протокола IP 47), часто служит для передачи IP-пакетов, с RFC 1918 частные адреса через Интернет с использованием пакетов доставки с общедоступными IP-адресами. В этом случае протоколы доставки и полезной нагрузки одинаковы, но адреса полезной нагрузки несовместимы с адресами сети доставки.

Также возможно установить соединение, используя уровень канала передачи данных. В Протокол туннелирования уровня 2 (L2TP) позволяет передавать кадры между двумя узлами. По умолчанию туннель не зашифрован: TCP / IP Выбранный протокол определяет уровень безопасности.

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

Чтобы понять конкретный стек протоколов, обусловленный туннелированием, сетевые инженеры должны понимать как полезную нагрузку, так и наборы протоколов доставки.

Общие протоколы туннелирования

  • IP в IP (Протокол 4): IP в IPv4 / IPv6
  • SIT / IPv6 (протокол 41): IPv6 в IPv4 / IPv6
  • GRE (Протокол 47): Общая инкапсуляция маршрутизации
  • OpenVPN (Порт UDP 1194)
  • SSTP (TCP-порт 443): протокол туннелирования защищенных сокетов
  • IPSec (Протокол 50 и 51): безопасность интернет-протокола
  • L2TP (Протокол 115): протокол туннелирования уровня 2
  • VXLAN (UDP-порт 4789): виртуальная расширяемая локальная сеть.
  • WireGuard

Безопасное туннелирование оболочки

А Безопасная оболочка (SSH) туннель состоит из зашифрованного туннеля, созданного через Протокол SSH подключение. Пользователи могут настроить SSH-туннели для передачи незашифрованный трафик по сети через зашифрованный канал. Например, компьютеры Microsoft Windows могут обмениваться файлами с помощью Блок сообщений сервера (SMB) протокол, незашифрованный протокол. Если бы кто-то смонтировал файловую систему Microsoft Windows удаленно через Интернет, кто-то, отслеживающий соединение, мог бы увидеть переданные файлы. Чтобы безопасно смонтировать файловую систему Windows, можно установить SSH-туннель, который направляет весь SMB-трафик на удаленный файловый сервер через зашифрованный канал. Хотя сам протокол SMB не содержит шифрования, зашифрованный канал SSH, по которому он проходит, обеспечивает безопасность.

Переадресация локальных и удаленных портов с помощью ssh выполняется на синем компьютере.

Как только SSH-соединение установлено, туннель начинается с SSH, прослушивающего порт на   удаленный или локальный хост. Любые подключения к нему перенаправляются на указанный   адрес и порт из   противостоящий (удаленный или локальный, как раньше) хост.

Туннелирование TCP-инкапсуляция полезная нагрузка (например, PPP ) через TCP-соединение (например, перенаправление портов SSH), известное как «TCP-over-TCP», и это может вызвать резкое снижение производительности передачи (проблема, известная как «распад TCP»),[3][4] вот почему виртуальная частная сеть программное обеспечение может вместо этого использовать для туннельного соединения протокол более простой, чем TCP. Однако это часто не проблема при использовании переадресации портов OpenSSH, потому что многие варианты использования не влекут за собой туннелирование TCP-over-TCP; краха можно избежать, потому что клиент OpenSSH обрабатывает локальное TCP-соединение на стороне клиента, чтобы получить фактическую отправляемую полезную нагрузку, а затем отправляет эту полезную нагрузку непосредственно через собственное TCP-соединение туннеля на сторону сервера, где OpenSSH сервер аналогичным образом «разворачивает» полезную нагрузку, чтобы «обернуть» ее снова для маршрутизации к конечному месту назначения.[5] Естественно, это сворачивание и разворачивание также происходит в обратном направлении двунаправленного туннеля.

Туннели SSH позволяют обходить брандмауэры которые запрещают определенные интернет-сервисы - до тех пор, пока сайт разрешает исходящие соединения. Например, организация может запретить пользователю доступ к веб-страницам в Интернете (порт 80) напрямую, не проходя через прокси-фильтр (который предоставляет организации средства мониторинга и контроля того, что пользователь видит в сети). Но пользователи могут не захотеть, чтобы их веб-трафик отслеживался или блокировался прокси-фильтром организации. Если пользователи могут подключиться к внешнему SSH сервер, они могут создать SSH-туннель для перенаправления заданного порта на своей локальной машине на порт 80 на удаленном веб-сервере. Чтобы получить доступ к удаленному веб-серверу, пользователи будут указывать свои браузер на локальный порт http: // localhost /

Некоторые клиенты SSH поддерживают динамический Перенаправление порта что позволяет пользователю создавать НОСКИ 4/5 прокси. В этом случае пользователи могут настроить свои приложения для использования своего локального прокси-сервера SOCKS. Это дает больше гибкости, чем создание SSH-туннеля к одному порту, как описано ранее. SOCKS может освободить пользователя от ограничений подключения только к заранее определенному удаленному порту и серверу. Если приложение не поддерживает SOCKS, можно использовать прокси-сервер для перенаправления приложения на локальный прокси-сервер SOCKS. Некоторые прокси-серверы, такие как Proxycap, поддерживают SSH напрямую, что позволяет избежать использования клиента SSH.

В последних версиях OpenSSH даже разрешено создавать туннели уровня 2 или уровня 3 если на обоих концах включены такие возможности туннелирования. Это создает тун (слой 3, по умолчанию) или нажмите (уровень 2) виртуальные интерфейсы на обоих концах соединения. Это позволяет использовать обычное управление сетью и маршрутизацию, а при использовании на маршрутизаторах трафик для всей подсети может быть туннелирован. Пара нажмите виртуальные интерфейсы функционируют как кабель Ethernet, соединяющий оба конца соединения, и могут соединять мосты ядра.

Смотрите также

использованная литература

  1. ^ «Обновление до TLS в HTTP / 1.1». RFC 2817. 2000. Получено 20 марта, 2013.
  2. ^ «Примечание об уязвимости VU № 150227: конфигурации HTTP-прокси по умолчанию разрешают произвольные TCP-соединения». US-CERT. 2002-05-17. Получено 2007-05-10.
  3. ^ Титц, Олаф (2001-04-23). «Почему TCP поверх TCP - плохая идея». Получено 2015-10-17.
  4. ^ Хонда, Осаму; Осаки, Хироюки; Имасе, Макото; Ишизука, Мика; Мураяма, Джуничи (октябрь 2005 г.). Атикуззаман, Мохаммед; Баландин Сергей I (ред.). «Производительность, качество обслуживания и управление коммуникационными и сенсорными сетями нового поколения III». Производительность, качество обслуживания и контроль коммуникационных и сенсорных сетей нового поколения III. 6011: 60110H. Bibcode:2005SPIE.6011..138H. Дои:10.1117/12.630496. S2CID  8945952. Цитировать журнал требует | журнал = (Помогите); | chapter = игнорируется (Помогите)
  5. ^ Каминский, Дан (2003-06-13). "Re: Расширения для длинных толстых сетей?". [email protected] (Список рассылки). код пересылки TCP также довольно быстрый. Просто чтобы заранее ответить на вопрос, ssh декапсулирует и повторно инкапсулирует TCP, поэтому у вас не возникает классических проблем TCP-over-TCP.

Статья основана на материалах, взятых из Бесплатный онлайн-словарь по вычислительной технике до 1 ноября 2008 г. и зарегистрированы в соответствии с условиями «перелицензирования» GFDL, версия 1.3 или новее.

внешние ссылки