I2PTunnel

Обзор

I2PTunnel — это инструмент для взаимодействия с сервисами в сети I2P и их предоставления. Назначение I2PTunnel может быть определено с использованием имени хоста , Base32 или полного 516-байтного ключа назначения. Созданный I2PTunnel будет доступен на вашей клиентской машине как localhost:port. Если вы хотите предоставить сервис в сети I2P, просто создайте I2PTunnel для соответствующего ip_address:port. Для сервиса будет сгенерирован соответствующий 516-байтный ключ назначения, и он станет доступен по всей сети I2P. Веб-интерфейс для управления I2PTunnel доступен по адресу localhost:7657/i2ptunnel/ .

Службы по умолчанию

Серверные туннели

• I2P Webserver - Туннель, направленный на веб-сервер Jetty, работающий на localhost:7658 для удобного и быстрого хостинга в I2P. Корневой каталог документов:
  • Unix - $HOME/.i2p/eepsite/docroot
  • Windows - %LOCALAPPDATA%\I2P\I2P Site\docroot, что раскрывается в: C:\Users\**username**\AppData\Local\I2P\I2P Site\docroot

Клиентские туннели

• I2P HTTP Proxy - localhost:4444 - HTTP прокси, используемый для анонимного просмотра I2P и обычного интернета через I2P. Просмотр интернета через I2P использует случайный прокси, указанный в опции “Outproxies:”.
• Irc2P - localhost:6668 - IRC tunnel к стандартной анонимной IRC сети, Irc2P.
• gitssh.idk.i2p - localhost:7670 - SSH доступ к Git репозиторию проекта
• smtp.postman.i2p - localhost:7659 - SMTP сервис, предоставляемый postman по адресу hq.postman.i2p
• pop3.postman.i2p - localhost:7660 - Сопутствующий POP сервис postman по адресу hq.postman.i2p

Конфигурация

Конфигурация I2PTunnel

Клиентские режимы

Стандартный

Открывает локальный TCP-порт, который подключается к сервису (например, HTTP, FTP или SMTP) на назначении внутри I2P. tunnel направляется к случайному хосту из списка назначений, разделённых запятыми (", “).

HTTP

HTTP-клиентский туннель. Туннель подключается к месту назначения, указанному в URL HTTP-запроса. Поддерживает проксирование в интернет, если предоставлен outproxy. Удаляет из HTTP-соединений следующие заголовки:

• Accept*: (не включая “Accept” и “Accept-Encoding”), поскольку они сильно различаются между браузерами и могут использоваться как идентификатор.
• Referer:
• Via:
• From:

HTTP клиентский прокси предоставляет ряд сервисов для защиты пользователя и обеспечения лучшего пользовательского опыта.

Обработка заголовков запроса: - Удаление заголовков, проблематичных с точки зрения конфиденциальности - Маршрутизация к локальному или удаленному outproxy - Выбор outproxy, кэширование и отслеживание доступности - Поиск назначений по именам хостов - Замена заголовка Host на b32 - Добавление заголовка для указания поддержки прозрачной декомпрессии - Принуждение connection: close - RFC-совместимая поддержка proxy - RFC-совместимая обработка и удаление hop-by-hop заголовков - Дополнительная digest и базовая аутентификация по имени пользователя/паролю - Дополнительная outproxy digest и базовая аутентификация по имени пользователя/паролю - Буферизация всех заголовков перед передачей для эффективности - Ссылки jump-сервера - Обработка jump-ответов и форм (address helper) - Обработка слепых b32 и форм учетных данных - Поддержка стандартных HTTP и HTTPS (CONNECT) запросов

Обработка заголовков ответа: - Проверка необходимости распаковки ответа - Принудительное закрытие соединения - RFC-совместимая обработка и удаление заголовков hop-by-hop - Буферизация всех заголовков перед передачей для повышения эффективности

HTTP-ответы об ошибках: - Для многих распространенных и не очень распространенных ошибок, чтобы пользователь знал, что произошло - Более 20 уникальных переведенных, стилизованных и отформатированных страниц ошибок для различных ошибок - Внутренний веб-сервер для обслуживания форм, CSS, изображений и ошибок

Прозрачное сжатие ответов

Сжатие ответа i2ptunnel запрашивается с помощью HTTP заголовка:

• X-Accept-Encoding: x-i2p-gzip;q=1.0, identity;q=0.5, deflate;q=0, gzip;q=0, *;q=0

Серверная сторона удаляет этот заголовок hop-by-hop перед отправкой запроса на веб-сервер. Сложный заголовок со всеми значениями q не является обязательным; серверы должны просто искать “x-i2p-gzip” в любом месте заголовка.

Серверная сторона определяет, следует ли сжимать ответ, основываясь на заголовках, полученных от веб-сервера, включая Content-Type, Content-Length и Content-Encoding, чтобы оценить, является ли ответ сжимаемым и стоит ли дополнительной нагрузки на процессор. Если серверная сторона сжимает ответ, она добавляет следующий HTTP заголовок:

• Content-Encoding: x-i2p-gzip

Если этот заголовок присутствует в ответе, HTTP-клиентский прокси прозрачно распаковывает его. Клиентская сторона удаляет этот заголовок и выполняет gunzip перед отправкой ответа в браузер. Обратите внимание, что у нас по-прежнему есть базовое gzip-сжатие на уровне I2CP, которое остается эффективным, если ответ не сжат на HTTP-уровне.

Данная архитектура и текущая реализация нарушают RFC 2616 несколькими способами:

• X-Accept-Encoding не является стандартным заголовком
• Не выполняет разбивку/склейку чанков на каждом хопе; передаёт чанкинг сквозным образом
• Передаёт заголовок Transfer-Encoding сквозным образом
• Использует Content-Encoding, а не Transfer-Encoding, для указания кодировки на каждом хопе
• Запрещает x-i2p gzip-сжатие, когда установлен Content-Encoding (но мы, вероятно, всё равно не хотим этого делать)
• Серверная сторона выполняет gzip-сжатие серверного чанкинга, вместо выполнения операций дечанк-gzip-речанк и дечанк-gunzip-речанк
• Сжатое gzip содержимое не разбивается на чанки после этого. RFC 2616 требует, чтобы все Transfer-Encoding, кроме “identity”, были разбиты на чанки
• Поскольку нет чанкинга снаружи (после) gzip, сложнее найти конец данных, что усложняет любую реализацию keepalive
• RFC 2616 говорит, что Content-Length не должен отправляться, если присутствует Transfer-Encoding, но мы это делаем. Спецификация говорит игнорировать Content-Length, если присутствует Transfer-Encoding, что браузеры и делают, поэтому это работает для нас

Изменения для реализации соответствующего стандартам hop-by-hop сжатия с обратной совместимостью являются темой для дальнейшего изучения. Любое изменение в dechunk-gzip-rechunk потребует нового типа кодирования, возможно x-i2p-gzchunked. Это будет идентично Transfer-Encoding: gzip, но должно сигнализироваться по-другому по соображениям совместимости. Любое изменение потребует формального предложения.

Прозрачное сжатие запросов

Не поддерживается, хотя POST от этого бы выиграл. Обратите внимание, что у нас все еще есть базовое gzip-сжатие на уровне I2CP.

Постоянство

Клиентские и серверные прокси в настоящее время не поддерживают постоянные сокеты HTTP RFC 2616 ни на одном из трех переходов (сокет браузера, I2P сокет, сокет сервера). Заголовки Connection: close внедряются на каждом переходе. В настоящее время исследуются изменения для реализации постоянных соединений. Эти изменения должны соответствовать стандартам и быть обратно совместимыми, и не потребуют формального предложения.

Конвейеризация

Клиентские и серверные прокси в настоящее время не поддерживают HTTP pipelining согласно RFC 2616, и нет планов по добавлению такой поддержки. Современные браузеры не поддерживают pipelining через прокси, поскольку большинство прокси не могут корректно реализовать эту функцию.

Совместимость

Реализации прокси должны корректно работать с другими реализациями на противоположной стороне. Клиентские прокси должны работать без HTTP-aware серверного прокси (т.е. со стандартным tunnel) на стороне сервера. Не все реализации поддерживают x-i2p-gzip.

User Agent

В зависимости от того, использует ли tunnel внешний прокси или нет, он добавит следующий User-Agent:

• Outproxy: User-Agent: Использует user agent из последнего релиза Firefox на Windows
• Внутреннее использование I2P: User-Agent: MYOB/6.66 (AN/ON)

IRC-клиент

Создает соединение со случайным IRC-сервером, указанным в списке назначений, разделенном запятыми (”, “). Из соображений анонимности разрешен только определенный набор IRC-команд из белого списка.

Следующий разрешающий список предназначен для команд, поступающих от IRC-сервера к IRC-клиенту.

Список разрешенных: - AUTHENTICATE - CAP - ERROR - H - JOIN - KICK - MODE - NICK - PART - PING - PROTOCTL - QUIT - TOPIC - WALLOPS

Также существует список разрешений для команд, исходящих от IRC-клиента к IRC-серверу. Он довольно большой из-за количества административных команд IRC. Подробности см. в исходном коде IRCFilter.java.

Фильтр исходящих соединений также модифицирует следующие команды для удаления идентифицирующей информации: - NOTICE - PART - PING - PRIVMSG - QUIT - USER

SOCKS 4/4a/5

Позволяет использовать I2P router в качестве SOCKS-прокси.

SOCKS IRC

Позволяет использовать I2P router в качестве SOCKS-прокси со списком разрешённых команд, указанным в режиме клиента IRC .

CONNECT

Создает HTTP tunnel и использует HTTP-метод запроса “CONNECT” для построения TCP tunnel, который обычно используется для SSL и HTTPS.

Streamr

Создает UDP-сервер, подключенный к клиенту Streamr I2PTunnel. Клиентский tunnel streamr будет подписываться на серверный tunnel streamr.

Серверные режимы

Стандартный

Создает назначение для локального ip:port с открытым TCP-портом.

HTTP

Создает destination для локального HTTP сервера ip:port. Поддерживает gzip для запросов с Accept-encoding: x-i2p-gzip, отвечает с Content-encoding: x-i2p-gzip на такой запрос.

HTTP серверный прокси предоставляет ряд сервисов для упрощения и повышения безопасности хостинга веб-сайтов, а также для улучшения пользовательского опыта на стороне клиента.

Обработка заголовков запроса: - Валидация заголовков - Защита от подделки заголовков - Проверка размера заголовков - Опциональное отклонение inproxy и user-agent - Добавление заголовков X-I2P, чтобы веб-сервер знал, откуда пришел запрос - Замена заголовка Host для упрощения работы с виртуальными хостами веб-сервера - Принудительное connection: close - RFC-совместимая обработка и удаление hop-by-hop заголовков - Буферизация всех заголовков перед передачей для повышения эффективности

Защита от DDoS: - Ограничение POST-запросов - Защита от таймаутов и slowloris - Дополнительное ограничение происходит в потоковой передаче для всех типов tunnel

Обработка заголовков ответа: - Удаление некоторых заголовков, проблематичных с точки зрения конфиденциальности - Проверка MIME-типа и других заголовков для определения необходимости сжатия ответа - Принудительное закрытие соединения - Обработка и удаление заголовков hop-by-hop в соответствии с RFC - Буферизация всех заголовков перед передачей для повышения эффективности

HTTP-ответы об ошибках: - Для многих распространенных и не очень распространенных ошибок, а также при регулировании нагрузки, чтобы пользователь на стороне клиента знал, что произошло

Прозрачное сжатие ответов: - Веб-сервер и/или слой I2CP могут сжимать данные, но веб-сервер часто этого не делает, и наиболее эффективно сжимать на высоком уровне, даже если I2CP также выполняет сжатие. HTTP серверный прокси работает совместно с клиентским прокси для прозрачного сжатия ответов.

HTTP Двунаправленный

Устарело

Функционирует как I2PTunnel HTTP-сервер и I2PTunnel HTTP-клиент без возможностей outproxy. Примером применения может быть веб-приложение, которое выполняет клиентские запросы, или loopback-тестирование I2P-сайта в качестве диагностического инструмента.

IRC Сервер

Создает destination, который фильтрует последовательность регистрации клиента и передает ключ destination клиента в качестве имени хоста IRC-серверу.

Streamr

Создается UDP-клиент, который подключается к медиа-серверу. UDP-клиент связывается с сервером Streamr I2PTunnel.