Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Использует [ редактировать ]

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

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

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

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

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

Технический обзор [ править ]

В качестве примера сетевого уровня над сетевым уровнем, Generic Routing Encapsulation (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

Туннелирование Secure Shell [ править ]

Secure Shell (SSH) туннель состоит из зашифрованного туннеля , созданного через протокол SSH - соединение. Пользователи могут настраивать туннели SSH для передачи незашифрованного трафика по сети через зашифрованный канал. Это программный подход к сетевой безопасности, результатом которого является прозрачное шифрование. [3]

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

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

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

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

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

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

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

См. Также [ править ]

  • HTTP туннель
  • ICMP туннель
  • NVGRE
  • Протокол туннелирования GPRS (GTP)
  • Псевдо-провод
  • Туннельный брокер
  • Виртуальная расширяемая локальная сеть (VXLAN)
  • Виртуальная частная сеть (VPN)
  • Stunnel
  • Модель OSI (Схема)

Ссылки [ править ]

  1. ^ «Обновление до TLS в HTTP / 1.1» . RFC 2817 . 2000 . Проверено 20 марта 2013 года .
  2. ^ «Примечание об уязвимости VU # 150227: конфигурации HTTP-прокси по умолчанию разрешают произвольные TCP-соединения» . US-CERT . 2002-05-17 . Проверено 10 мая 2007 .
  3. ^ Барретт, Дэниел Дж .; Барретт, Дэниел Дж .; Сильверман, Ричард Э .; Сильверман, Ричард (2001). SSH, Secure Shell: полное руководство . "O'Reilly Media, Inc.". ISBN 978-0-596-00011-0.
  4. ^ Тиц, Олаф (2001-04-23). «Почему TCP поверх TCP - плохая идея» . Проверено 17 октября 2015 .
  5. ^ Хонда, Осаму; Осаки, Хироюки; Имасе, Макото; Ишизука, Мика; Мураяма, Дзюнъити (октябрь 2005 г.). «Понимание TCP поверх TCP: влияние TCP-туннелирования на сквозную пропускную способность и задержку». В Атикуззамане, Мохаммед; Баландин Сергей I (ред.). Производительность, качество обслуживания и контроль коммуникационных и сенсорных сетей нового поколения III . 6011 . Bibcode : 2005SPIE.6011..138H . CiteSeerX 10.1.1.78.5815 . DOI : 10.1117 / 12.630496 . S2CID 8945952 .  
  6. Каминский, Дэн (13.06.2003). "Re: Расширения для длинных толстых сетей?" . [email protected] (список рассылки). код пересылки TCP также довольно быстр. Просто чтобы заранее ответить на вопрос, ssh декапсулирует и повторно инкапсулирует TCP, поэтому у вас не возникает классических проблем TCP-over-TCP.

Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или новее.

Внешние ссылки [ править ]

  • Распределенное решение PortFusion в обратном / прямом направлении, локальный прямой прокси и туннелирование для всех протоколов TCP
  • SSH VPN-туннель, см. Раздел ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕТИ НА ОСНОВЕ SSH
  • Проект BarbaTunnel - Бесплатная реализация HTTP-туннеля и UDP-туннеля с открытым исходным кодом в Windows
  • VpnHood Project - Бесплатная реализация VPN с открытым исходным кодом с использованием перенаправления сокетов.