HTTP-туннель
HTTP-туннелирование используется для создания сетевого соединения между двумя компьютерами в условиях ограниченного сетевого подключения, включая брандмауэры , NAT и ACL , а также другие ограничения. Туннель создается посредником, называемым прокси-сервером , который обычно находится в демилитаризованной зоне .
Туннелирование также может обеспечить связь с использованием протокола , который обычно не поддерживается в сети с ограниченным доступом.
Метод HTTP-ПОДКЛЮЧЕНИЯ
[ редактировать ]Наиболее распространенной формой туннелирования HTTP является стандартизированный метод HTTP CONNECT . [1] [2] В этом механизме клиент запрашивает прокси-сервер HTTP перенаправить TCP -соединение в желаемый пункт назначения. Затем сервер устанавливает соединение от имени клиента. После того как соединение установлено сервером, прокси-сервер продолжает пересылать TCP-поток к клиенту и от него. Только первоначальный запрос на соединение является HTTP — после этого сервер просто проксирует установленное TCP-соединение.
Этот механизм позволяет клиенту за HTTP-прокси получать доступ к веб-сайтам с использованием SSL или TLS (т. е. HTTPS). Прокси-серверы также могут ограничивать подключения, разрешая подключения только к порту HTTPS по умолчанию 443, внося хосты в белый список или блокируя трафик, который не похож на SSL.
Пример переговоров
[ редактировать ]Клиент подключается к прокси-серверу и запрашивает туннелирование, указав порт и хост-компьютер, к которому он хочет подключиться. Порт используется для указания запрашиваемого протокола. [3]
CONNECT streamline.t-mobile.com:22 HTTP/1.1
Proxy-Authorization: Basic encoded-credentials
Если соединение было разрешено и прокси-сервер подключился к указанному хосту, прокси-сервер вернет ответ об успехе 2XX. [3]
HTTP/1.1 200 OK
Теперь клиент пересылается на удаленный хост. Любые данные, отправленные на прокси-сервер, теперь пересылаются в неизмененном виде на удаленный хост. [3] и клиент может общаться, используя любой протокол, принятый удаленным хостом. В приведенном ниже примере клиент запускает соединение SSH, на что указывает номер порта в исходном запросе CONNECT.
SSH-2.0-OpenSSH_4.3\r\n ...
HTTP-туннелирование без использования CONNECT
[ редактировать ]HTTP-туннель также можно реализовать, используя только обычные методы HTTP, такие как POST, GET, PUT и DELETE. Это похоже на подход, используемый в двунаправленных потоках через синхронный HTTP ( BOSH ).
Специальный HTTP-сервер работает вне защищенной сети, а клиентская программа запускается на компьютере внутри защищенной сети. Всякий раз, когда от клиента передается какой-либо сетевой трафик, клиент переупаковывает данные трафика в HTTP-запрос и передает данные на внешний сервер, который извлекает и выполняет исходный сетевой запрос для клиента. Ответ на запрос, отправленный на сервер, затем переупаковывается как ответ HTTP и передается обратно клиенту. Поскольку весь трафик инкапсулируется внутри обычных запросов и ответов GET и POST, этот подход работает через большинство прокси-серверов и межсетевых экранов. [а]
См. также
[ редактировать ]- ICMP-туннель
- Псевдопровод
- Туннельный брокер
- Виртуальная частная сеть (VPN)
- Виртуальная расширяемая локальная сеть
- Виртуализация сети с использованием общей инкапсуляции маршрутизации
Примечания
[ редактировать ]Ссылки
[ редактировать ]- ^ Филдинг, Р. (июнь 1999 г.). «Определения методов, CONNECT» . Протокол передачи гипертекста — HTTP/1.1 . IETF . п. 56. сек. 9.9. дои : 10.17487/RFC2616 . РФК 2616 . Проверено 9 июля 2010 г.
- ^ Харе, Р.; Лоуренс, С. (2000). «Обновление до TLS в HTTP/1.1 (RFC 2817)» . дои : 10.17487/RFC2817 . РФК 2817 . Проверено 3 июля 2011 г.
{{cite journal}}: Для цитирования журнала требуется|journal=( помощь ) - ^ Jump up to: а б с "СОЕДИНЯТЬ" . Семантика и контент HTTP/1.1 . IETF . Июнь 2014. с. 30. сек. 4.3.6. дои : 10.17487/RFC7231 . РФК 7231 . Проверено 4 ноября 2017 г.