Перейти до змістуЯк використовувати проксі з GitHub Codespaces в мережі з обмеженнями
Середовище GitHub Codespaces запускає контейнер розробки на хостингу, тоді як браузер, у якому ви його переглядаєте, працює на вашому пристрої. Це важливо: налаштувавши проксі в контейнері, ви можете спрямувати через нього завантаження пакетів із Codespace, але це автоматично не змінить спосіб, у який локальний браузер відкриває сайти. Якщо ви шукаєте, як налаштувати проксі в GitHub Codespaces, спершу визначте, який саме трафік потрібно перенаправити.
Якщо встановлення залежностей не вдається через корпоративний брандмауер, спершу з’ясуйте, яке саме з’єднання заблоковано. Від цього залежить, де потрібно налаштувати проксі та що має дозволити ваша організація.
1. Визначте, для якого трафіку Codespaces потрібен проксі
З’ясуйте, яка саме операція не працює. Встановлення пакета Python за допомогою pip, отримання залежності Node.js через npm і завантаження інструмента командного рядка з термінала — це запити, які надсилає програмне забезпечення в контейнері розробки. Натомість вкладка браузера, відкрита на вашому ноутбуці, використовує мережеве з’єднання ноутбука.
Розуміння цієї різниці заощадить час. Якщо сайт не відкривається в локальному браузері, додавання HTTPS_PROXY у Codespace може нічого не змінити. А якщо в терміналі Codespace не працює команда npm install, проксі, налаштований лише на ноутбуці, теж може не допомогти.
Запишіть, який інструмент не працює, до якої адреси він намагається під’єднатися та звідки надходить запит: із термінала, розширення редактора чи локального браузера. Наприклад, помилка під час pip install вказує на трафік контейнера, а невдала спроба ввійти на сторінці в локальному браузері — на проблему з локальною мережею або налаштуваннями браузера.
Обмежте налаштування лише потрібним трафіком. Якщо заблоковано лише один реєстр пакетів, спрямовувати через проксі весь трафік недоцільно: це може спричинити зайві помилки, особливо якщо внутрішні служби мають бути доступні напряму.
2. Дізнайтеся, що дозволяє проксі вашої організації
Запитайте в адміністратора мережі адресу проксі-сервера та порт, потрібний протокол і спосіб автентифікації. Також уточніть, що вимагає проксі: ім’я користувача й пароль, клієнтський сертифікат чи сертифікат центру сертифікації, встановлений у контейнері. Не намагайтеся вгадати ці дані за налаштуваннями проксі на іншому пристрої.
Уточніть, доступ до яких адрес дозволено для конкретного завдання. Менеджеру пакетів може знадобитися доступ до реєстру, а інструменту встановлення — завантаження з окремого сервера релізів. Адміністратор підтвердить, які імена хостів дозволені. Запишіть їх до початку діагностики, щоб відрізнити заблоковану адресу від неправильної адреси проксі.
З’ясуйте, чи ввімкнено перевірку HTTPS-трафіку. У такому разі проксі може показувати сертифікати, видані вашою організацією, а не публічним центром сертифікації, якого очікує інструмент. Сертифікат організації та схвалені інструкції з його встановлення має надати адміністратор — не копіюйте сертифікат із повідомлення про помилку.
Якщо ви порівнюєте типи проксі або налаштовуєте доступ для інших інструментів, перегляньте порадник із безпечної автентифікації через проксі. Ширший огляд вибору способу маршрутизації мережевого трафіку наведено в статті як вибрати VPN: VPN і проксі налаштовуються в Codespaces по-різному.
3. Налаштуйте змінні проксі для контейнера розробки
Багато інструментів командного рядка читають змінні середовища HTTP_PROXY та HTTPS_PROXY. Саме змінні HTTP_PROXY і HTTPS_PROXY у Codespaces дають змогу багатьом таким інструментам спрямовувати запити через проксі. Задайте їх у середовищі контейнера розробки Codespace, використовуючи адресу, надану адміністратором. Типове значення має вигляд http://proxy.example.net:8080, але використовуйте протокол, ім’я хоста й порт, передбачені вашою організацією.
Укажіть у NO_PROXY адреси, які мають оминати проксі, наприклад схвалені внутрішні служби або локальні адреси. Точний список залежить від вашої мережі та інструментів. Занадто широкий список може спрямувати внутрішні запити не тим маршрутом, а надто вузький — змусити запит напряму звертатися до заблокованої адреси.
Для швидкої тимчасової перевірки можна задати змінні в сеансі термінала перед запуском команди. Це допоможе з’ясувати, чи працює встановлення пакета, але не забезпечить надійного налаштування для кожного термінала або наступних сеансів Codespace. Синтаксис командної оболонки також різниться, тож не вставляйте URL проксі з обліковими даними в команду, яка може зберегтися в історії оболонки.
Щоб налаштування проєкту можна було повторно використовувати, збережіть несекретні параметри в конфігурації контейнера розробки репозиторію, наприклад у відповідному файлі конфігурації Dev Container або скрипті налаштування. Не додавайте паролі й токени до файлів, що відстежуються системою контролю версій. Якщо потрібні облікові дані, скористайтеся схваленим у вашій організації способом передавання секретів і з’ясуйте, які процеси матимуть до них доступ.
Не припускайте, що всі програми використовують ці змінні. Деякі інструменти читають змінні з малими літерами, деякі мають власні файли конфігурації, а інші взагалі ігнорують змінні середовища. Перевірте саме команду, яка не працювала: наявність HTTPS_PROXY ще не означає, що весь трафік Codespace спрямовується через проксі.
4. Збережіть налаштування проксі після перебудови Codespace
Налаштування, задане в одному терміналі, може зникнути після його закриття або перебудови Codespace. Щоб потрібні проєкту несекретні параметри зберігалися, скористайтеся конфігурацією рівня репозиторію, яка застосовується під час створення контейнера розробки. Тоді колега, який відкриє той самий проєкт, отримає такі самі базові налаштування, а приватні облікові дані не доведеться копіювати в репозиторій.
Якщо проксі потрібен лише для вашого облікового запису або містить конфіденційні дані, краще підійдуть персональні налаштування. Перш ніж обрати цей спосіб, перевірте політики Codespaces у вашій організації та доступні параметри: адміністратор може обмежити персональні налаштування, секрети або використання певних функцій контейнера розробки.
Після зміни конфігурації перебудуйте Codespace, якщо вона впливає на створення контейнера. Потім відкрийте новий термінал і перевірте змінні. Перебудова — корисна перевірка: якщо налаштування проксі зникло, найімовірніше, його додали лише до попередньої оболонки, а не до постійного джерела конфігурації.
Зберігайте спільні налаштування окремо від секретів. У репозиторії можна задокументувати назви змінних проксі та очікуваний формат значень, але справжній пароль потрібно передавати через схвалений механізм роботи із секретами. Так звичайний коміт не відкриє облікові дані всім, хто може переглядати історію проєкту.
5. За потреби додайте сертифікат проксі до довірених
Якщо HTTPS-запити завершуються помилкою перевірки сертифіката, а ваша організація підтверджує, що перевірка HTTPS-трафіку ввімкнена, контейнеру може знадобитися сертифікат центру сертифікації організації. Отримайте офіційний сертифікат та інструкції з його встановлення в адміністратора. Не вимикайте перевірку сертифікатів як обхідний шлях: це може приховати перехоплення трафіку, а не усунути проблему.
Спосіб встановлення залежить від операційної системи та базового образу контейнера. У Debian, Alpine та спеціалізованих образах для мов програмування набори сертифікатів можуть оброблятися по-різному. Також з’ясуйте, чи потрібно додавати сертифікат під час створення контейнера, щоб він залишався доступним після перебудови.
Після встановлення перевірте звичайний HTTPS-запит до схваленої адреси — тим самим інструментом, який спочатку не працював. Якщо браузер відкриває сайт, але клієнт командного рядка й далі повідомляє про недовіреного видавця, цей клієнт може використовувати окреме сховище сертифікатів або вимагати власного налаштування. Перш ніж змінювати параметри довіри, запитайте адміністратора, який файл сертифіката та формат використовувати в контейнері.
6. Перевіряйте Git та інструменти розробки окремо
Спочатку виконайте простий тестовий запит до адреси, схваленої адміністратором. Потім перевірте менеджер пакетів або інструмент, який не працював. Успішний запит з однієї команди не доводить, що Git, pip, npm і спеціалізований інсталятор для певної мови програмування однаково використовують проксі.
Для Git перевірте, чи використовує встановлена версія у вашому середовищі змінні проксі. Якщо ні, можливо, проксі потрібно налаштувати окремо для Git. Не записуйте пароль безпосередньо у файл конфігурації Git, який можуть додати до коміту або скопіювати в журнали. Натомість використовуйте схвалений організацією спосіб роботи з обліковими даними.
Для менеджерів пакетів перевірте і налаштування проксі, і адресу налаштованого реєстру. Якщо менеджер пакетів використовує внутрішній реєстр, йому може не знадобитися доступ до того самого зовнішнього ресурсу, що й для прямого завантаження. Інструмент, який завантажує архів релізу, може звертатися до зовсім іншого хоста. Зіставте адресу в повідомленні про помилку зі списком дозволених адрес.
Якщо вам потрібно з’ясувати, як встановлювати пакети в Codespaces за корпоративним брандмауером, перевірте налаштування проксі й реєстру пакетів, а також дозвіл на доступ до адрес, до яких звертається менеджер пакетів.
Запишіть, які перевірки пройшли, які завершилися помилкою та яке ім’я хоста фігурувало. Такий короткий звіт дасть адміністратору конкретну інформацію — наприклад, «Git з’єднується зі схваленим хостом, але проксі відхиляє запит до реєстру пакетів», — замість розпливчастої скарги, що в Codespaces немає інтернету.
7. Діагностуйте проблеми з’єднання, не розкриваючи облікові дані
Виконайте безпечний тест з’єднання зі схваленою адресою та перевірте, чи вказує результат на проблему з DNS, перевищення часу очікування, автентифікацію через проксі, блокування адреси чи перевірку сертифіката. Кожен тип помилки підказує наступний крок. Наприклад, перевищення часу очікування — це не те саме, що відмова в автентифікації.
Переконайтеся, що ім’я хоста й порт проксі відповідають даним адміністратора, а змінна доступна в тому самому сеансі термінала, у якому ви запускаєте перевірку. Якщо проксі вимагає автентифікації, неправильні або прострочені облікові дані можуть блокувати доступ навіть за правильної адреси.
Перш ніж ділитися виводом термінала, видаліть імена користувачів, паролі, токени та URL-адреси з обліковими даними. Повідомлення про помилки проксі можуть містити повну адресу запиту, а в історії оболонки можуть зберігатися команди із секретами. Натомість повідомте тип помилки, ім’я цільового хоста, назву інструмента та час збою — часто цієї інформації достатньо, щоб фахівці з мережі перевірили журнали.
Якщо проксі працює в одному Codespace, але не в іншому, порівняйте конфігурацію контейнерів, образ операційної системи, змінні середовища та налаштування сертифікатів. Змінюйте лише один параметр за раз і повторюйте ту саму перевірку. Так буде простіше з’ясувати, у чому причина: відсутній змінний параметр, заблокована адреса чи відмінності у сховищі довірених сертифікатів.