Запуск GitLab через I2P | I2P - Проект невидимого интернета

Хостинг GitLab внутри I2P прост: запустите контейнер GitLab omnibus, откройте его на loopback и перенаправьте трафик через I2P-туннель. Приведённые ниже шаги повторяют конфигурацию, используемую для git.idk.i2p, но работают для любого самостоятельно размещённого экземпляра.

1. Предварительные требования

Debian или другой дистрибутив Linux с установленным Docker Engine (sudo apt install docker.io или docker-ce из репозитория Docker).
I2P router (Java I2P или i2pd) с достаточной пропускной способностью для обслуживания ваших пользователей.
Опционально: выделенная виртуальная машина, чтобы GitLab и router оставались изолированными от вашего рабочего окружения.

2. Загрузите образ GitLab

docker pull gitlab/gitlab-ce:latest

Официальный образ собирается на основе базовых слоев Ubuntu и регулярно обновляется. Изучите Dockerfile , если вам требуются дополнительные гарантии.

3. Определитесь с выбором между бриджингом и режимом только I2P

I2P-only инстансы никогда не связываются с хостами в clearnet. Пользователи могут зеркалировать репозитории из других I2P-сервисов, но не из GitHub/GitLab.com. Это обеспечивает максимальную анонимность.
Bridged инстансы обращаются к Git-хостам в clearnet через HTTP-прокси. Это полезно для зеркалирования публичных проектов в I2P, но при этом происходит деанонимизация исходящих запросов сервера.

Если вы выбираете режим bridged, настройте GitLab на использование I2P HTTP-прокси, привязанного к хосту Docker (например, http://172.17.0.1:4446). Стандартный прокси router по умолчанию слушает только на 127.0.0.1; добавьте новый прокси-tunnel, привязанный к адресу шлюза Docker.

4. Запуск контейнера

docker run --detach \
  --env HTTP_PROXY=http://172.17.0.1:4446 \  # omit for I2P-only
  --publish 127.0.0.1:8443:443 \
  --publish 127.0.0.1:8080:80 \
  --publish 127.0.0.1:8022:22 \
  --name gitlab \
  --restart always \
  --volume /srv/gitlab/config:/etc/gitlab:Z \
  --volume /srv/gitlab/logs:/var/log/gitlab:Z \
  --volume /srv/gitlab/data:/var/opt/gitlab:Z \
  gitlab/gitlab-ce:latest

Привяжите опубликованные порты к loopback; I2P туннели откроют их по мере необходимости.
Замените /srv/gitlab/... на пути хранения, соответствующие вашему хосту.

После запуска контейнера перейдите по адресу https://127.0.0.1:8443/, установите пароль администратора и настройте ограничения для учетных записей.

5. Открыть доступ к GitLab через I2P

Создайте три серверных туннеля I2PTunnel:

Purpose	Local target	Suggested inbound port
HTTPS web UI	`127.0.0.1:8443`	auto-generated
HTTP web UI (optional)	`127.0.0.1:8080`	auto-generated
SSH push/pull	`127.0.0.1:8022`	auto-generated
Настройте каждый tunnel с соответствующей длиной и пропускной способностью. Для публичных экземпляров хорошей отправной точкой является 3 хопа с 4–6 tunnels в каждом направлении. Опубликуйте получившиеся Base32/Base64 адреса назначения на вашей целевой странице, чтобы пользователи могли настроить клиентские tunnels.

Destination Enforcement

Если вы используете HTTP(S) туннели, включите принудительное применение назначения (destination enforcement), чтобы только предполагаемое имя хоста могло получить доступ к сервису. Это предотвращает использование туннеля в качестве обычного прокси.

6. Maintenance Tips

Выполняйте docker exec gitlab gitlab-ctl reconfigure каждый раз при изменении настроек GitLab.
Следите за использованием дискового пространства (/srv/gitlab/data) — Git-репозитории быстро растут.
Регулярно создавайте резервные копии каталогов конфигурации и данных. Задачи резервного копирования rake GitLab работают внутри контейнера.
Рассмотрите возможность размещения внешнего мониторингового tunnel в клиентском режиме, чтобы обеспечить доступность сервиса из более широкой сети.

6. Советы по обслуживанию

Правильно настроенный экземпляр GitLab обеспечивает центр совместной разработки полностью внутри I2P. Поддерживайте router в рабочем состоянии, своевременно устанавливайте обновления безопасности GitLab и координируйте действия с сообществом по мере роста пользовательской базы.