Ожидание туннеля прокси

Туннелирование TCP через web-прокси

Ожидание туннеля прокси

Лажу я, значит, по каталогу шаре- и фриварного софта www.davecentral.

com в наиболее любимом мной разделе Windows | Connectivity | Winsock Tools, и задерживается мой взгляд на таком вот ревью к одной из утилит: “HTTPort является полезным решением, если вы находитесь в корпоративной Internet-среде, которая блокирована от внешнего мира прокси/файерволлом, который не позволяет вам использовать никакие интернет-сервисы кроме веба (HTTP), а вам их таки нужно (или очень хочется;) использовать. Продукт также позволяет вам увеличить вашу анонимность при работе в Сети…”Теперь стыдно признаться, но тогда я восприняла это как стремную рекламную листовку. Однако продукт скачала. По диагонали пробежав документацию, запускаю я это чудо, нацеливаю на первый попавшийся под руку открытый и соответствующий определенным условиям (об условиях – ниже) веб-проксик и, пустив слезу умиления, вылажу на Dalnet IRC.Кроме меня слезу умиления пускают и окружающие, в том числе и на IRC. Первый пункт обещаний “рекламной листовки” оказался явью. Далее был произведен эксперимент с увеличением анонимности. Анонимность увеличивается радикально – администратор вашего прокси-сервера, призванный следить за тем, чтобы ваши ползанья по вебу ограничивались рамками служебной необходимости, а не всякими там ххх, yyy и т. д., видит, что целый божий рабочий день вы самозабвенно устанавливаете соединение с неким “бесцветным”, неопасным хостом. Правда, не по 80-му порту, но это уже вопрос для многих администраторов десятый, несущественный, в общем, вопрос.Ну вот, кое-кого мы уже заинтриговали, кое-кого напугали, теперь оставим шуточки и завлекалки и займемся делом.

ход мысли

Протокол HTTP знают все? Все, я думаю. Многие даже читали спецификации версий 1.0 и 1.1. Кстати, для справки: HTTP 1.1 имеет две спецификации – RFC 2616 и устаревший RFC 2068. Версия 1.0 описывается документом RFC 1945. Выпишем себе на промокашку методы, описанные для каждой версии в каждом из RFC:RFC 1945 (HTTP 1.0) – GET, HEAD, POSTRFC 2068 (HTTP 1.

1) – OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACERFC 2616 (HTTP 1.1) – OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECTСтоп! Вот то, что нам нужно. Читаем: “Спецификация резервирует имя метода CONNECT для использования с прокси, которые могут динамически переключаться на работу в качестве туннеля (например, туннелирование SSL).

” Далее следует кривая ссылка на документ “Tunneling TCP based protocols through Web proxy servers”, который мне все-таки удалось отыскать. Перед тем, как приступить к изложению сути технологии, кратко опишу историю этого документа, ибо это есть поучительно.Автором означенного документа является некто Ари Луотонен.

Систематически ведя исследования в данной области, Ари публикует результаты в качестве Internet-Drafts. Интересно то, что все предшествующие материалы были объединены в серию draft-luotonen-ssl-tunneling-XX.txt и, как видно из названия, описывали проблему исключительно с позиции тунелирования SSL.

Соответственно все ссылались на разработку Луотонена как на “туннелирование SSL” (SSL tunneling). И только в 1998 году Луотонен открывает новую серию, поименованную draft-luotonen-web-proxy-tunneling-XX.txt.

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

А по жизни происходит вот что: производители прокси-серверов включают поддержку метода СONNECT для туннелирования SSL, указывая в документации и release notes что-то типа “SSL proxy support (https)” либо умалчивая об экспериментальной фиче вовсе. Итого имеем: поддержку https в WinProxy 1.4 c 1996 года (см. release notes), строку вида https://irc.dal. net:6667/ в логах все того же WinProxy и лицо вида Ж8-() у сетевого администратора. Приехали, в общем ;).
собственно технология

Упомянутый выше документ (который draft-luotonen-web-proxy-tunneling-00.txt) описывает расширение протокола HTTP 1.x (важно: не только HTTP 1.1, как вам могло показаться, но и старого доброго HTTP 1.0) для организации туннелирования TCP на прокси-серверах (веб-прокси).

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

Суть отступления в следующем: следует иметь в виду, что протокол HTTPS, который по сути является реализацией HTTP поверх SSL, может обрабатываться прокси и иным образом, как обычный маппинг, использующийся в различных реализациях прокси для поддержки большинства протоколов – Telnet, FTP и др.

В таком варианте имеем следующего рода взаимодействие: прокси устанавливает безопасное (secure) соединение с удаленным HTTPS-сервером и осуществляет транзакции от имени клиента. Полученные в ходе взаимодействия данные дешифруются проксью и по нормальному (unsecure, опасному, в общем) HTTP отдаются клиенту. Минусы такого варианта очевидны.Итак, что нам предлагает г-н Луотонен.

Клиент соединяется с прокси-сервером и использует метод CONNECT для задания имени хоста и номера TCP-порта, к которым ему вздумалось подключиться. Имя хоста и номер порта разделяются двоеточием (:), причем оба эти параметра должны быть заданы явно (никаких дефолтов). Сочетание host:port дополняется строкой с указанием версии HTTP и символом перевода строки.

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

Потом сервер открывает соединение с указанными в запросе хостом:портом и начинает прозрачно, не вдаваясь в суть дела, передавать данные между сокетами со стороны клиента и со стороны сервера – туда и обратно. Вот с большего и все.Приведем пример диалога, результатом которого станет работа с IRC через веб-туннель:клиент:CONNECT irc.dal.net:6667 HTTP/1.0

сервер:HTTP/1.

0 200 Connection establishedProxy-agent: WinRoute Pro/4.1

Знатоки протокола HTTP наверняка обратили внимание на отсутствие в ответе сервера поля Content-Type, которое является обязательным в обычном HTTP/1.x.

Действительно, текущей спецификацией не предусмотрена “обязательность” наличия этого поля, поскольку на данный момент не существует стандартного типа данных MIME, ассоциирующегося с туннелем. Автор спецификации не исключает, что в будущих версиях он предложит ввести стандартный тип данных, например “application/tunnel”.

Поэтому для будущей совместимости при реализации поле Content-Type должно быть разрешено, но для совместимости с ранними версиями поле это не должно быть обязательным.Процедура создания туннеля может свободно модифицироваться использованием стандартных заголовков HTTP 1.x. В качестве дежурного примера возьмем механизм прокси-аутентификации.

Чтобы заставить клиента пройти аутентификацию, прокси просто должен послать в качестве ответа код 407 и стандартный заголовок Proxy-authenticate. Клиент должен доложить о себе в поле Proxy-authorization. Таким образом, диалог клиента с сервером в случае необходимости аутентификации будет выглядеть вот так:клиент:CONNECT irc.dal.net:6667 HTTP/1.0

сервер:HTTP/1.

0 407 Proxy auth requiredProxy-agent: WinRoute Pro/4.1Proxy-authenticate:…

клиент:CONNECT irc.dal.net:6667 HTTP/1.0Proxy-authorization:…

сервер:HTTP/1.0 200 Connection establishedProxy-agent: WinRoute Pro/4.1

В самом конце документа есть такой вот интересный пункт: Security Considerations.

В нем автор намекает, что придуманная им технология дает почву для разного рода злоупотреблений, о которых вы, мои читатели, по идее уже догадались 😉 Поэтому Ари Луотонен настоятельно рекомендует (цитирую): “…конфигурация прокси должна явно ограничивать возможность соединения стандартными (well-known) портами”.

А далее делается оговорка, что даже за известными портами в некоторых случаях надо “последить”.

Вот, в частности, как вам перспектива туннелирования SMTP для рассылки спама? ;)Однако автор ограничивается лишь напоминанием о потенциальной проблеме, не давая конкретных рекомендаций разработчикам прокси-серверов относительно того, каким образом грамотнее всего это ограничение организовать. Мои эксперименты с WinRoute Pro 4.1 и WinProxy 1.

4 (чешским) показывают, что ни по дефолту, ни вручную ничегошеньки там не ограничивается;) А вот squid – совсем другое дело. Юниксовый софт вообще всегда радовал исключительной конфигурабельностью и нелюбовью к дефолтам. Уважают разработчики нужды и чаянья сисадминов.

В squid'е запросто можно ограничить использование метода CONNECT, например свести его только к SSL-туннелированию. Вот вам пример участков конфигурационного файла squid.conf (к версии 2.1), где прописывается такое ограничение.acl CONNECT method CONNECTacl SSL_ports port 443 563http_access deny CONNECT!SSL_portsКстати, о портах и протоколах: факт, что не все базирующиеся на TCP протоколы будут работать через туннель. Наверняка их найдется по крайней мере штук 5, но очевиден мне пока один – FTP. Ну вы сами догадываетесь, почему 😉 Не догадываетесь – пробегитесь по спецификации FTP, пусть это будет вам эдаким заданием для самостоятельной работы 😉 И вот еще что… Сессия NetBIOS у нас, если мне мемори не изменяет, по TCP работает, а вот разрешение имен NetBIOS – увы, по UDP. В принципе, запасшись терпением, документацией, генератором пакетов или умением программировать под Windows Sockets, добавив минимум социально-инженерных навыков (для альтернативного разрешения имен ;), можно организовать непрошенное туннелирование NetBIOS'а, что может оказаться весьма интересным занятием. У вашей покорной слуги как-то пока не получилось – явно терпения не хватает 😉

вместо рекламы

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

Сразу предупреждаю: продукт сий бесплатный, с автором его я ни лично, ни виртуально не знакома, посему – никакого подвоха, все честно 😉 Кстати, насколько мне удалось понять из краткого мануала к программе, ее автор просто искал выход из неуютной ситуации в рамках файерволла своей сети.

В частности, неуютным было отсутствие поддержки SOCKS-прокси.Задача HTTPort – сделать возможной работу с туннелем для “неподготовленного” клиентского ПО, коим большинство интернет-клиентов и является. Софтина устроена просто как грабельки и состоит, условно говоря, из двух модулей.

Первый модуль работает как прокси-клиент, организующий туннель с нужным прокси-сервером, а вторая открывает на клиентской станции слушающие (listening) сокеты, по одному на каждый потенциальный туннель. Таким образом, “неподготовленное” ПО соединяется с неким локальным сокетом, смотрящим (замапленным) на определенный туннель.

В нашем случае с IRC имеет место такая пара: локальный сокет 127.0.0.1:6667 смотрит в туннель на irc.dal.net:6667. IRC-клиент настроен таким образом, что если вы хотите попасть на DALNet через веб-прокси, он соединялся с “сервером” 127.0.0.1 по порту 6667.

Аналогично настраивается и “нелегальное каскадирование” прокси для увеличения анонимности веб-серфинга, где в качестве “той стороны туннеля” выступает некий публичный прокси-сервер.

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

Кстати (или некстати), программа made in Russia (или made by russian ;), автора зовут Dmitry Dvoinikov. Все, для кого тема этого материала стала откровением, хором скажем Дмитрию спасибо!

Источник: https://nestor.minsk.by/sr/2000/06/00607.html

Исправить ERR TUNNEL CONNECTION FAILED ошибку в браузере

Ожидание туннеля прокси

Наверное, трудно найти хоть одного активного интернет-пользователя, который за время своих виртуальных путешествий по просторах Глобальной паутины ни разу не сталкивался с проблемой доступа к тому или иному веб-ресурсу.

Большинство людей подобные, согласитесь, весьма неприятные ситуации встречались. Одна из них – это когда, вместо желаемого отображения нужной странички в браузере на экране возникает сообщение NET ERR TUNNEL CONNECTION FAILED.

Следствием возникновения этой неприятности становится невозможность дальнейшего перехода на тот или иной сайт. Естественно, это автоматически приводит к возникновению вопроса: ERR TUNNEL CONNECTION FAILED – как исправить? В этой статье мы постараемся дать на него максимально понятный и полный ответ.

Почему это происходит?

Итак, ERR TUNNEL CONNECTION FAILED – что за ошибка? Практически всегда она связана с так называемыми прокси-серверами, во время использования которых происходит подмена оригинального АйПи-адреса пользователя.

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

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

Как показала практика, чаще всего такая ситуация наблюдается в интернет-браузере Гугл Хром. Хотя в Сети можно встретить просьбы о помощи, написанные людьми, которые эксплуатируют другие, альтернативные продукты.

К примеру, некоторые пишут о состоянии ERR TUNNEL CONNECTION FAILED Opera. Тем не менее, учитывая массовость этой ошибки именно в Google Chrome, мы будет строить свою методику лечения именно на основе этой программы.

Как исправить: инструкция по устранению

Существует четыре основных вариантов действий в этой ситуации. Конечно, можно самостоятельно выстраивать их последовательность. Но мы рекомендуем следовать той, которая будет описана ниже. И, естественно, выполнять обязательную проверку результата после завершения каждого из этапов, чтобы не тратить время, если один из вариантов позволил избавиться от этого сбоя:

Деактивация настроек прокси

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

  • Кликнуть по кнопке «пуск» и воспользоваться системной поисковой строкой, которая есть в любой современной операционной системе Виндовс.
  • Вбить в поле «Прокси» и перейти по ссылке, предлагающей осуществить настройку этого функционала.
  • В итоге, на экране должно появиться окно, которое называется «Свойства: интернет» с активной вкладкой «Подключения».
  • В его нижней части воспользоваться кнопкой «Настройки сети».
  • Остается только снять галочку рядом с пунктом, который подразумевает использование прокси-серверов.

Естественно, не забыть нажать на «ОК», чтобы изменения, внесенные только что, сохранились.

Сброс сетевых установок

Учитывая, что именно они могут оказаться первопричиной данной неприятности, не удивительно, что их откат до изначального состояния часто позволяет получить требуемый результат:

  • Опять перейти к системной поисковой строке.
  • Использовать запрос «cmd» – не забыть убрать кавычки.
  • На предложенной ссылке кликнуть правой кнопочкой комп.мышки, чтобы появилась возможность запуска с правами администратора.
  • Последовательно ввести четыре команды: «ipconfig /flushdns», «nbtstat –r», «netsh int ip reset», «netsh winsock reset».
  • Конечно же, убрав кавычки и не забываея сопровождать каждую из них нажатием клавиши ВВОД (Enter).

Перед проверкой обязательно выполнить перезапуск компьютерного оборудования!

Смена ДНС-серверов

Этот метод подразумевает переход на альтернативные ДНС-сервера, предлагаемые компанией ГУГЛ:

  • Обратить внимание на правую часть трея. Там есть иконка, похожая на изображение компьютера.
  • Воспользовавшись на ней ПКМ, перейти в «Центр управления сетями…».
  • В блоке «подключение и отключение» кликнуть по подключению по локалке.
  • Активируется дополнительное окошко, где требуется осуществить переход через «Свойства» к протоколу Протокол Интернета версии 4 (TCP / IPv4) (здесь потребуется двойное нажатие).
  • Во кладке «общие» сменить флажок на «Использовать следующие адреса…».
  • Вставить в первую строку 8.8.8.8, а во вторую – 8.8.4.4.

Не забыть нажать на «ОК», и обязательно – перезагрузить используемый интернет-браузер. Не обязательно перезапускать всю систему.

Чистка кэша

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

В Гугл Хром процедура выглядит следующим образом:

  • Активировать браузер и вставить в адресную строку chrome://settings. Естественно, нажать на Enter.
  • Пролистать открывшееся таким образом окно параметров в его нижнюю часть, чтобы появилась возможность воспользоваться разделом «Дополнительно».
  • Перейти в «Конфиденциальность и безопасность», в этом подразделе нажать на предложение, позволяющее выполнить очистку истории.
  • Временной диапазон выставить на «Все время». Все пункты отметить галочками.
  • Нажать на «Удалить данные».

После завершения процедуры очистки – перезапустить еще раз используемый веб-браузер.

Источник: https://komp-tvoy.ru/ispravit-err-tunnel-connection-failed-oshibku-v-brauzere/

ERR_PROXY_CONNECTION_FAILED: как исправить ошибку?

Ожидание туннеля прокси

Всем привет! Сегодня мы поговорим сразу про две ошибки: «ERR_TUNNEL_CONNECTION_FAILED» и «ERR_PROXY_CONNECTION_FAILED». Они появляются при заходе на сайт в браузерах Google Chrome и Яндекс, когда сама программа не может получить ответа от сервера. Далее я расскажу – как решить эту проблему. Если у вас будут вопросы по поводу статьи – пишите в комментарии.

Первые действия

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

Нажмите на три точки в правом верхнем углу, перейдите в «Настройки». Далее слева найдите пункт «Расширения».

Нажмите по любому расширению правой кнопкой мыши и далее по кнопке «Настроить расширения».

Очистите кэш-браузера – для этого нажмите на клавиши «Ctrl+Shift+Del». Оставляем все по умолчанию и нажимаем «Удалить данные».

Проверьте, что вы корректно вводите адрес в адресную строку. Если есть возможность, то найдите этот сайт в поисковике и перейдите на страницу оттуда. Если вы не можете зайти только на один сайт, то есть несколько вариантов:

  • На сайте ведутся технические работы.
  • Со стороны провайдера и его DNS есть проблемы.
  • Сайт заблокирован и попасть туда можно только через VPN – по поводу бесплатного использования ВПН смотрим инструкцию тут.
  • Идет блокировка со стороны антивируса – можно попробовать его отключить. Если проблема решится, то вам нужно зайти в настройки антивируса и внести данный сайт в исключение проверки.

В первых двух случаях нужно просто подождать. Если же не открываются все сайты, или со временем проблема «ERROR_TUNNEL_CONNECTION_FAILED» так и не решилась – то пробуем следующие способы.

Проверка прокси

Очень часто ошибка возникает из-за включенного прокси-сервера. Также некоторые программы или даже вирусы могут устанавливать свои надстройки. Давайте проверим это! Нажмите на клавиши «Win» (находится в первом ряду между «Ctrl» и «Alt») и клавишу «R». Далее вылезет окошко «Выполнить», где нужно ввести команду:

inetcpl.cpl

На вкладке «Подключения» нажимаем по кнопке с настройками и далее выключаем все надстройки, которые там есть, далее применяем параметр и проверяем. Если это не поможет, то вернитесь обратно и включите галочку «Автоматическое определение параметров».

Если вы используете VPN, то отключите данное подключение.

DNS

Возможно, есть проблема с DNS от провайдера, поэтому можно их попробовать изменить. Жмем опять на «Win» и «R», и вводим команду:

ncpa.cpl

Далее вы увидите все ваши подключения – выделите то, через которое у вас идет интернет. Зайдите в «Свойства» с помощью правой кнопкой мыши. Далее выделяем 4 протокол, заходим в «Свойства» и вводим DNS, как на картинке ниже (8.8.8.8 и 8.8.4.4). Жмем два раза «ОК».

Чистка компа

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

Скачайте программу «CCleaner», установите и запустите её. Скачиваем бесплатную «FREE» версию – её будет достаточно.

Переходим в раздел «Стандартной очистки», нажимаем на «Анализ» и через некоторое время, когда программа найдет все временные файлы – кликаем по кнопке «Очистка».

Аналогичные действия проделываем в разделе «Реестр» для исправления некоторых ошибок.

Теперь зайдите в «Автозагрузку» – там мы уберем все лишние программы, которые запускаются вместе с системой.

Win+R=msconfig

Нажимаем ПКМ по нижней полосе и заходим в «Диспетчер задач».

Теперь на вкладке «Автозагрузки» отключаем все кроме антивируса и звукового драйвера.

Я бы ещё зашел в «Программы и компоненты» – данный раздел находится в «Панели управления». В семерке туда можно попасть через «Пуск», а в десятке нужно вызвать с помощью команды: Win+R=control.

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

Далее нужно его скачать с интернета и установить заново.

СОВЕТ! Про более детальную очистку системы от нежелательного мусора – читаем тут.

Сброс кэш DNS и другие настройки сети

Откройте командную строку от имени администратора.

Введите поочередно четыре команды:

ipconfig /flushdns
nbtstat –r
netsh int ip reset
netsh winsock reset

Перезагрузите комп.

Источник: https://WiFiGid.ru/reshenie-problem-i-oshibok/err_tunnel_connection

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.