Я ищу способ получить быстрое соединение OpenVPN через ограничительный брандмауэр (это не рабочее место, и я не нарушаю никаких правил поведения).
В настоящее время я использую порт 443 напрямую для сервера openvpn, поскольку брандмауэр разрешает произвольный TCP на этом порту. Нет открытых портов, кроме 80 и 443 (только TCP), а DNS является внутренним. Однако для порта 443 применено ограничение скорости 15 Мбит / с, и он крайне ненадежен (ссылка openvpn полностью отключается каждые несколько минут).
Я тщательно протестировал и пришел к выводу, что порт 80 будет разрешать только традиционные HTTP-запросы - все, что связано с CONNECT или Transfer-Encoding: Chunked, будет автоматически отброшено.
Пинг достаточно низкий (5-10 мс) и достаточно высокая скорость (70 Мбит вниз, 15 Мбит вверх), поэтому я действительно готов рассмотреть туннель опроса HTTP (или какое-то волшебство, которое устанавливает огромную длину контента и запускает множество пустышек. data), но проблема в том, что я не могу его найти. Существует ли уже какое-либо решение для этого?
Я пробовал обычно рекомендуемые http://sourceforge.net/projects/http-tunnel/, но без радости, так как для этого требуется фрагментированное кодирование.
Редактировать: Нашел полурешение - http://www.targeted.org/htthost/. Работает, но, к сожалению, слишком медленно с точки зрения задержки, чтобы с этим можно было особо справиться. Интересно, что до того, как я поставил его за nginx, открыв его внутренние URL-адреса, я смог увидеть страницу по умолчанию прозрачного прокси, за которым я скрываюсь (очевидно, wampserver apache).
У вас возникла проблема, упомянутая в этой статье Олафа Титца?
http://sites.inka.de/bigred/devel/tcp-tcp.html
Цитирование (так как я не мог выразиться яснее). Обратите внимание, что TCP верхнего и нижнего уровней имеет разные таймеры. Когда соединение верхнего уровня запускается быстро, его таймеры тоже работают быстро. Теперь может случиться так, что у нижнего соединения есть более медленные таймеры, возможно, как остаток периода с медленным или ненадежным базовым соединением.
Представьте, что происходит, когда в этой ситуации базовое соединение начинает терять пакеты. TCP нижнего уровня ставит в очередь повторную передачу и увеличивает время ожидания. Поскольку соединение заблокировано на этот период времени, TCP верхнего уровня (то есть полезной нагрузки) не получит своевременного ACK, а также поставит в очередь повторную передачу. Поскольку тайм-аут по-прежнему меньше тайм-аута нижнего уровня, верхний уровень будет ставить в очередь больше повторных передач быстрее, чем нижний уровень может их обработать. Это приводит к очень быстрому срыву соединения верхнего уровня, и каждая повторная передача только усугубляет проблему - эффект внутреннего срыва.
Обеспечение надежности TCP дает здесь обратный эффект. Повторные передачи верхнего уровня совершенно не нужны, поскольку оператор связи гарантирует доставку, но TCP верхнего уровня не может этого знать, потому что TCP всегда предполагает ненадежную передачу ".
Может это обсуждение в этой ветке (http://news.ycombinator.com/item?id=2409090) даст вам несколько полезных указателей.