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

Введение

Протокол компьютерной связи

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

Применение

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

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

Пользователи также могут использовать туннелирование, чтобы "пройти" через брандмауэр, используя протокол, который брандмауэр обычно блокирует, но "завёрнутый" в протокол, который брандмауэр не блокирует, например HTTP. Если политика брандмауэра не конкретно запрещает такую "обёртку", этот приём может позволить обойти заданную политику брандмауэра (или набор взаимосвязанных политик брандмауэра). Другой метод туннелирования на основе HTTP использует метод/команду HTTP CONNECT. Клиент отправляет команду HTTP CONNECT HTTP-прокси. Прокси затем устанавливает TCP-соединение с определённым сервером:портом и передаёт данные между этим сервером:портом и клиентским соединением. Поскольку это создаёт уязвимость в системе безопасности, HTTP-прокси, поддерживающие CONNECT, обычно ограничивают доступ к этому методу. Прокси-сервер разрешает подключения только к определённым портам, таким как 443 для HTTPS. Другие методы туннелирования, способные обходить сетевые брандмауэры, используют различные протоколы, такие как DNS, MQTT, SMS.

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

В качестве примера сетевого уровня поверх сетевого уровня, Generic Routing Encapsulation (GRE) – протокол, работающий поверх IP (IP-протокол номер 47) – часто используется для передачи IP-пакетов с частными адресами, определенными в RFC 1918, через Интернет, используя пакеты доставки с публичными IP-адресами. В этом случае протоколы доставки и полезной нагрузки могут быть одинаковыми, но адреса полезной нагрузки несовместимы с адресами сети доставки. Также возможно установить соединение, используя канальный уровень. Протокол туннелирования уровня 2 (L2TP) позволяет передавать кадры между двумя узлами. Туннель по умолчанию не шифруется: уровень безопасности определяется выбранным протоколом TCP/IP. SSH использует порт 22 для обеспечения шифрования передаваемых данных (полезной нагрузки) по общедоступной сети (например, Интернет), тем самым предоставляя функциональность VPN. IPsec имеет режим транспортного уровня «конец в конец», но также может работать в режиме туннелирования через доверенный шлюз безопасности. Для понимания конкретного стека протоколов, определяемого туннелированием, сетевым инженерам необходимо понимать как наборы протоколов полезной нагрузки, так и наборы протоколов доставки.

Безопасный туннель

Туннель Secure Shell (SSH) состоит из зашифрованного туннеля, созданного через соединение протокола SSH. Пользователи могут настраивать SSH-туннели для передачи незашифрованного трафика по сети через зашифрованный канал. Это программный подход к сетевой безопасности, результатом которого является прозрачное шифрование. Например, компьютеры Microsoft Windows могут обмениваться файлами с использованием протокола Server Message Block (SMB) — незашифрованного протокола. Если бы кто-то удалённо подключил файловую систему Microsoft Windows через Интернет, посторонний, перехватывающий соединение, мог бы видеть передаваемые файлы. Для безопасного монтирования файловой системы Windows можно установить SSH-туннель, который направляет весь трафик SMB на удалённый файловый сервер через зашифрованный канал. Несмотря на то, что сам протокол SMB не содержит шифрования, зашифрованный канал SSH, через который он проходит, обеспечивает безопасность. После установления SSH-соединения туннель начинает работу с прослушивания SSH-порта на удалённом или локальном хосте. Любые подключения к нему перенаправляются на указанный адрес и порт, исходящие от противоположного хоста (удалённого или локального, как указано ранее). Туннелирование TCP-инкапсулированной полезной нагрузки (например, PPP) через TCP-соединение (например, переадресацию портов SSH) известно как «TCP поверх TCP», и это может привести к резкому снижению производительности передачи (проблема, известная как «TCP- meltdown»), поэтому программное обеспечение виртуальных частных сетей может вместо этого использовать протокол, более простой, чем TCP, для туннельного соединения. Однако это часто не является проблемой при использовании переадресации портов OpenSSH, поскольку во многих случаях использования не требуется туннелирование TCP поверх TCP; сбой предотвращается, поскольку клиент OpenSSH обрабатывает локальное клиентское TCP-соединение для доступа к фактической полезной нагрузке, которая отправляется, а затем отправляет эту полезную нагрузку непосредственно через собственное TCP-соединение туннеля на серверную сторону, где сервер OpenSSH аналогично «распаковывает» полезную нагрузку, чтобы «упаковать» её снова для маршрутизации к конечному пункту назначения. Естественно, эта упаковка и распаковка также происходят в обратном направлении для двунаправленного туннеля. SSH-туннели предоставляют возможность обхода брандмауэров, запрещающих определённые интернет-сервисы, при условии, что сайт разрешает исходящие соединения. Например, организация может запретить пользователю прямой доступ к веб-страницам Интернета (порт 80) без прохождения через прокси-фильтр организации (который предоставляет организации средства мониторинга и контроля за тем, что пользователь просматривает в Интернете). Однако пользователи могут не желать, чтобы их веб-трафик отслеживался или блокировался прокси-фильтром организации. Если пользователи могут подключиться к внешнему SSH-серверу, они могут создать SSH-туннель для переадресации заданного порта на своей локальной машине на порт 80 на удалённом веб-сервере. Для доступа к удалённому веб-серверу пользователи должны указать свой браузер на локальный порт по адресу http://localhost/.

A Secure Shell (SSH) tunnel consists of an encrypted tunnel created through an SSH protocol connection. Users may set up SSH tunnels to transfer unencrypted traffic over a network through an encrypted channel. It is a software based approach to network security and the result is transparent encryption. For example, Microsoft Windows machines can share files using the Server Message Block (SMB) protocol, a non encrypted protocol. If one were to mount a Microsoft Windows file system remotely through the Internet, someone snooping on the connection could see transferred files. To mount the Windows file system securely, one can establish a SSH tunnel that routes all SMB traffic to the remote fileserver through an encrypted channel. Even though the SMB protocol itself contains no encryption, the encrypted SSH channel through which it travels offers security. Once an SSH connection has been established, the tunnel starts with SSH listening to a port on the remote or local host. Any connections to it are forwarded to the specified address and port originating from the opposing (remote or local, as previously) host. Tunneling a TCP encapsulating payload (such as PPP) over a TCP based connection (such as SSH's port forwarding) is known as "TCP over TCP", and doing so can induce a dramatic loss in transmission performance (a problem known as "TCP meltdown"), which is why virtual private network software may instead use a protocol simpler than TCP for the tunnel connection. However, this is often not a problem when using OpenSSH's port forwarding, because many use cases do not entail TCP over TCP tunneling; the meltdown is avoided because the OpenSSH client processes the local, client side TCP connection in order to get to the actual payload that is being sent, and then sends that payload directly through the tunnel's own TCP connection to the server side, where the OpenSSH server similarly "unwraps" the payload in order to "wrap" it up again for routing to its final destination. Naturally, this wrapping and unwrapping also occurs in the reverse direction of the bidirectional tunnel. SSH tunnels provide a means to bypass firewalls that prohibit certain Internet services so long as a site allows outgoing connections. For example, an organization may prohibit a user from accessing Internet web pages (port 80) directly without passing through the organization's proxy filter (which provides the organization with a means of monitoring and controlling what the user sees through the web). But users may not wish to have their web traffic monitored or blocked by the organization's proxy filter. If users can connect to an external SSH server, they can create an SSH tunnel to forward a given port on their local machine to port 80 on a remote web server. To access the remote web server, users would point their browser to the local port at http://localhost/

Некоторые SSH-клиенты поддерживают динамическую переадресацию портов, которая позволяет пользователю создавать прокси SOCKS 4/5. В этом случае пользователи могут настроить свои приложения на использование локального прокси-сервера SOCKS. Это обеспечивает большую гибкость, чем создание SSH-туннеля к одному порту, как описано ранее. SOCKS может освободить пользователя от ограничений подключения только к заранее определённому удалённому порту и серверу. Если приложение не поддерживает SOCKS, можно использовать проксификатор для перенаправления приложения на локальный прокси-сервер SOCKS. Некоторые проксификаторы, такие как Proxycap, поддерживают SSH напрямую, что избавляет от необходимости в SSH-клиенте. В последних версиях OpenSSH даже разрешено создавать туннели уровня 2 или уровня 3, если обе стороны включили такие возможности туннелирования. Это создаёт виртуальные интерфейсы tun (уровень 3, по умолчанию) или tap (уровень 2) на обоих концах соединения. Это позволяет использовать обычное управление сетью и маршрутизацию, а при использовании на маршрутизаторах трафик для всей подсети может быть туннелирован. Пара виртуальных интерфейсов tap функционирует как кабель Ethernet, соединяющий оба конца соединения, и может быть подключена к мостам ядра.

Кибератаки на основе туннелирования

На протяжении многих лет туннелирование и инкапсуляция данных в целом часто использовались в злонамеренных целях для скрытной связи с внешними сетями. В этом контексте к известным туннелям относятся протоколы, такие как HTTP, SSH, DNS, MQTT.