Налаштування проксі Git

Налаштування Git-проксі передбачає конфігурацію параметрів Git http.proxy та https.proxy, або використання змінних середовища, таких як HTTP_PROXY та HTTPS_PROXY, або застосування ProxyCommand у конфігураціях SSH для Git-операцій на основі SSH, щоб направляти трафік через проміжний сервер.

Розуміння вимог до Git-проксі

Корпоративні фаєрволи, політики мережевої безпеки або обмежений доступ до інтернету часто вимагають маршрутизації Git-трафіку через проксі-сервер. Це стосується таких операцій, як git clone, git fetch, git pull та git push. Метод конфігурації залежить від протоколу URL Git: https:// (або http://) використовує HTTP/HTTPS-проксі, тоді як ssh:// (або git@) використовує методи проксі, специфічні для SSH.

Конфігурація HTTP/HTTPS Git-проксі

Для Git-репозиторіїв, доступ до яких здійснюється за допомогою URL-адрес https:// або http://, Git використовує налаштування HTTP/HTTPS-проксі.

Метод конфігурації Git (git config)

Це рекомендований метод для конфігурації HTTP/HTTPS-проксі для Git. Налаштування можуть бути глобальними (для всіх репозиторіїв) або специфічними для одного репозиторію.

Глобальна конфігурація

Щоб налаштувати проксі глобально для всіх Git-репозиторіїв у системі:

# Для HTTP-проксі (наприклад, для URL-адрес https://github.com через HTTP-проксі)
git config --global http.proxy http://proxy.example.com:8080

# Для HTTPS-проксі (наприклад, для URL-адрес https://github.com через HTTPS-проксі)
# Примітка: Часто HTTPS-проксі налаштовується аналогічно HTTP-проксі,
# але трафік явно тунелюється.
git config --global https.proxy http://proxy.example.com:8080

Якщо проксі вимагає автентифікації:

git config --global http.proxy http://username:[email protected]:8080
git config --global https.proxy http://username:[email protected]:8080

З міркувань безпеки, замість вбудовування пароля безпосередньо в URL, Git може запитувати облікові дані або отримувати їх від помічника з облікових даних. Пропуск пароля призведе до того, що Git запитає його.

Конфігурація для кожного репозиторію

Щоб налаштувати проксі для конкретного репозиторію, перейдіть до кореневого каталогу репозиторію та опустіть прапорець --global:

cd /path/to/my/repo
git config http.proxy http://proxy.example.com:8080
git config https.proxy http://proxy.example.com:8080

Ці налаштування будуть збережені у файлі .git/config цього репозиторію.

Вимкнення проксі для певних хостів

Щоб обійти проксі для певних доменів (наприклад, внутрішніх Git-серверів), використовуйте http.noProxy:

git config --global http.noProxy "localhost,127.0.0.1,*.internal.com"

Кілька хостів можна розділити комами.

Перевірка SSL-сертифіката

У корпоративних середовищах, що використовують прозорі або перехоплюючі проксі (MITM-проксі), перевірка SSL-сертифіката Git може завершитися помилкою через те, що проксі надає власний сертифікат замість сертифіката вихідного сервера.

Щоб вирішити цю проблему, налаштуйте Git довіряти корпоративному кореневому сертифікату CA:

git config --global http.sslCAInfo /path/to/corporate/ca-cert.pem

Альтернативно, і не рекомендовано для виробничих середовищ через ризики безпеки, перевірку SSL можна вимкнути:

git config --global http.sslVerify false

Це обходить перевірку сертифікатів, роблячи з'єднання вразливими до реальних атак "людина посередині". Використовуйте це лише для тимчасового налагодження або в контрольованих, ізольованих середовищах.

Змінні середовища

Інструменти командного рядка, включаючи curl (який Git часто використовує для HTTP/HTTPS-передач), зазвичай поважають змінні середовища HTTP_PROXY, HTTPS_PROXY та NO_PROXY. Ці змінні надають системні або сесійні налаштування проксі, які програми можуть успадковувати.

# Для HTTP-проксі
export HTTP_PROXY="http://proxy.example.com:8080"
export HTTPS_PROXY="http://proxy.example.com:8080" # Часто те саме для тунелювання HTTPS-трафіку

# Для SOCKS-проксі
export ALL_PROXY="socks5://proxy.example.com:1080"

# Виключити певні хости з проксі
export NO_PROXY="localhost,127.0.0.1,*.internal.com"

Зауважте, що конфігурації Git http.proxy та https.proxy мають пріоритет над цими змінними середовища для власних HTTP/HTTPS-операцій Git. Змінні середовища корисні, коли git config явно не встановлено, або для інших інструментів, що взаємодіють з Git.

Порівняння: git config проти змінних середовища

Конфігурація SSH Git-проксі

Для Git-репозиторіїв, доступ до яких здійснюється за допомогою URL-адрес ssh:// або git@, налаштування проксі керується через конфігурацію SSH-клієнта, зокрема за допомогою директиви ProxyCommand у ~/.ssh/config. Стандартні налаштування HTTP/HTTPS-проксі (наприклад, http.proxy) не впливають на SSH-з'єднання.

Використання ~/.ssh/config з ProxyCommand

ProxyCommand вказує SSH встановити з'єднання з цільовим хостом (%h) та портом (%p), спочатку маршрутизуючи його через зовнішню команду, зазвичай клієнт проксі.

Передумови

• netcat (nc): Для базового TCP-тунелювання та SOCKS-проксі.
• corkscrew або connect-proxy: Для тунелювання SSH через HTTP/HTTPS-проксі, які вимагають автентифікації.

Тунелювання через HTTP/HTTPS-проксі

Якщо ваш проксі є HTTP/HTTPS-проксі, ви можете використовувати corkscrew або connect-proxy.

1. Встановіть corkscrew або connect-proxy (якщо ще не встановлено).

   • На Debian/Ubuntu: sudo apt-get install corkscrew
   • На macOS (з Homebrew): brew install corkscrew
   • connect-proxy часто є частиною openssh або доступний окремо.

2. Відредагуйте ~/.ssh/config:
   Створіть або змініть ~/.ssh/config наступним чином:

   ```ssh
   Host github.com
   ProxyCommand corkscrew proxy.example.com 8080 %h %p
   # Якщо проксі вимагає автентифікації:
   # ProxyCommand corkscrew proxy.example.com 8080 %h %p /path/to/proxy_auth_file

   Host gitlab.com
   ProxyCommand corkscrew proxy.example.com 8080 %h %p

   Або для всіх хостів

   Host *
   ProxyCommand corkscrew proxy.example.com 8080 %h %p
   `` Замінітьproxy.example.comта8080на адресу та порт вашого проксі. Файл/path/to/proxy_auth_fileповинен міститиusername:passwordв одному рядку. Переконайтеся, що цей файл має обмежувальні дозволи (наприклад,chmod 600`).

Тунелювання через SOCKS-проксі

Якщо ваш проксі є SOCKS-проксі, використовуйте netcat (nc) з опцією -X:

1. Переконайтеся, що netcat встановлено. Зазвичай він попередньо встановлений на більшості Unix-подібних систем.

2. Відредагуйте ~/.ssh/config:

   ```ssh
   Host github.com
   ProxyCommand nc -X 5 -x proxy.example.com:1080 %h %p

   Host gitlab.com
   ProxyCommand nc -X 5 -x proxy.example.com:1080 %h %p

   Або для всіх хостів

   Host *
   ProxyCommand nc -X 5 -x proxy.example.com:1080 %h %p
   `` Замінітьproxy.example.comта1080на адресу та порт вашого SOCKS-проксі. *-X 5: Вказує SOCKS версії 5. Використовуйте-X 4для SOCKS версії 4. *-x`: Вказує адресу та порт проксі.

Автентифікація для SOCKS-проксі

Деякі версії netcat (nc з OpenBSD, часто за замовчуванням на Linux) підтримують автентифікацію SOCKS-проксі. Наприклад:

Host *
    ProxyCommand nc -X 5 -x user:[email protected]:1080 %h %p

Зверніться до сторінки man вашої версії netcat для отримання конкретного синтаксису та можливостей автентифікації.

Перевірка налаштування проксі

Після налаштування проксі перевірте, чи правильно маршрутизуються Git-операції.

Для HTTP/HTTPS Git-операцій

Перевірте конфігурацію Git:

git config --global --get http.proxy
git config --global --get https.proxy
git config --global --get http.noProxy

Виконайте операцію git clone або git fetch на HTTPS-репозиторії:

git clone https://github.com/git/git.git

Якщо проксі працює, з'єднання має бути успішним. Інструменти моніторингу мережі можуть підтвердити маршрутизацію трафіку.

Для SSH Git-операцій

Детально протестуйте ваше SSH-з'єднання:

ssh -vT [email protected]

Шукайте вивід, що вказує на виконання ProxyCommand. Наприклад:

debug1: Executing proxy command: exec corkscrew proxy.example.com 8080 github.com 22

Потім спробуйте виконати Git-операцію:

git clone [email protected]:git/git.git

Усунення поширених проблем

• Неправильна адреса або порт проксі: Двічі перевірте IP-адресу або ім'я хоста проксі-сервера та призначений порт.
• Помилка автентифікації: Перевірте ім'я користувача та пароль проксі. Для git config переконайтеся, що облікові дані правильні або що налаштовано помічника з облікових даних. Для ProxyCommand переконайтеся, що файл автентифікації або вбудовані облікові дані правильні.
• Проблеми з SSL-сертифікатом (https://): Якщо ви стикаєтеся з помилками SSL certificate problem: self signed certificate in certificate chain, ваш корпоративний проксі може виконувати SSL-інспекцію. Налаштуйте http.sslCAInfo за допомогою корпоративного кореневого сертифіката CA, або, як останній засіб, тимчасово встановіть http.sslVerify false для налагодження (не рекомендується для виробництва).
• Блокування фаєрволом: Переконайтеся, що ваш локальний фаєрвол (якщо є) та корпоративний фаєрвол дозволяють вихідні з'єднання до проксі-сервера на його вказаному порту. Сам проксі-сервер також повинен дозволяти з'єднання до Git-хостинг-сервісів.
• Допоміжна програма ProxyCommand не знайдена (ssh://): Якщо ProxyCommand завершується помилкою "command not found", переконайтеся, що netcat, corkscrew або connect-proxy встановлено, а шлях до їхнього виконуваного файлу знаходиться у змінній середовища PATH вашої системи. За потреби вкажіть повний шлях до виконуваного файлу (наприклад, ProxyCommand /usr/bin/corkscrew ...).
• Проксі обійдено: Якщо git config http.noProxy занадто широкий, або якщо змінні середовища встановлені неправильно, Git може спробувати пряме з'єднання. Перевірте налаштування noProxy.
• Таймаут проксі: Довготривалі операції можуть завершитися таймаутом, якщо проксі має агресивні налаштування таймауту. Зазвичай це проблема конфігурації на стороні сервера.