Przejdź do treściJak używać proxy w GitHub Codespaces w sieci z ograniczeniami
GitHub Codespace uruchamia kontener programistyczny w środowisku hostowanym, natomiast przeglądarka, w której go wyświetlasz, działa na Twoim urządzeniu. To ważne rozróżnienie: skonfigurowanie proxy w kontenerze może kierować przez nie pobieranie pakietów z Codespace, ale nie zmienia automatycznie sposobu, w jaki lokalna przeglądarka łączy się ze stronami.
Jeśli instalacja zależności nie działa za firmową zaporą sieciową, najpierw ustal, które połączenie jest blokowane. Od tego zależy, gdzie trzeba skonfigurować proxy i jakie połączenia powinna dopuścić Twoja organizacja. Jeśli zastanawiasz się, jak ustawić proxy w GitHub Codespaces, zacznij od wskazania, czy problem dotyczy ruchu z kontenera, czy z lokalnej przeglądarki.
1. Ustal, który ruch z Codespaces ma przechodzić przez proxy
Wskaż konkretną operację, która kończy się niepowodzeniem. Instalowanie pakietu Pythona za pomocą pip, pobieranie zależności Node.js przy użyciu npm i pobieranie narzędzia wiersza poleceń z terminala to żądania wysyłane przez oprogramowanie działające w kontenerze programistycznym. Z kolei karta otwarta w przeglądarce na laptopie korzysta z połączenia sieciowego laptopa.
To rozróżnienie może zaoszczędzić czas. Jeśli strona nie otwiera się w lokalnej przeglądarce, dodanie zmiennej HTTPS_PROXY w Codespace może nic nie zmienić. Jeśli polecenie npm install nie działa w terminalu Codespace, proxy skonfigurowane tylko na laptopie również może nie pomóc.
Zapisz, które narzędzie zgłasza błąd, z jakim adresem próbuje się połączyć i czy żądanie pochodzi z terminala, rozszerzenia edytora czy lokalnej przeglądarki. Na przykład błąd polecenia pip install wskazuje na ruch z kontenera, a nieudane logowanie w lokalnej przeglądarce — na konfigurację sieci lokalnej lub przeglądarki.
Ogranicz zakres zmian. Kierowanie całego ruchu przez proxy, gdy zablokowane jest tylko jedno repozytorium pakietów, może powodować niepotrzebne problemy — zwłaszcza jeśli usługi wewnętrzne powinny być dostępne bezpośrednio.
2. Sprawdź, na co pozwala proxy w Twojej organizacji
Poproś administratora sieci o nazwę hosta i port proxy, wymagany protokół oraz metodę uwierzytelniania. Zapytaj też, czy proxy wymaga nazwy użytkownika i hasła, certyfikatu klienta czy certyfikatu urzędu certyfikacji zainstalowanego w kontenerze. Nie zgaduj tych danych na podstawie ustawień proxy z innego urządzenia.
Poproś o listę dozwolonych adresów potrzebnych do wykonania konkretnego zadania. Menedżer pakietów może wymagać dostępu do repozytorium, a instalator narzędzia może pobierać pliki z osobnego serwera z wydaniami. Administrator może potwierdzić, które nazwy hostów są dozwolone. Zapisz je przed rozpoczęciem diagnostyki, aby odróżnić zablokowany adres od nieprawidłowego adresu proxy.
Sprawdź, czy włączona jest inspekcja HTTPS. W takim przypadku proxy może przedstawiać certyfikaty wystawione przez Twoją organizację, a nie przez publiczny urząd certyfikacji, którego oczekuje dane narzędzie. Certyfikat organizacji i zatwierdzoną procedurę jego instalacji uzyskaj od administratora — nie kopiuj certyfikatu z komunikatu o błędzie.
Jeśli porównujesz rodzaje proxy lub konfigurujesz dostęp dla innych narzędzi, zapoznaj się z poradnikiem bezpiecznego uwierzytelniania proxy. Więcej informacji o wyborze sposobu kierowania ruchu sieciowego znajdziesz w artykule jak wybrać VPN. VPN i proxy konfiguruje się w Codespaces w różny sposób.
3. Skonfiguruj zmienne proxy w kontenerze programistycznym
Wiele narzędzi wiersza poleceń odczytuje zmienne środowiskowe HTTP_PROXY i HTTPS_PROXY. Ustaw je w środowisku kontenera programistycznego Codespace, używając formatu adresu podanego przez administratora. Typowa wartość wygląda tak: http://proxy.example.net:8080, ale użyj protokołu, nazwy hosta i portu właściwych dla Twojej organizacji. Tę część konfiguracji można opisać jako konfiguracja HTTP_PROXY i HTTPS_PROXY w Codespaces.
Ustaw zmienną NO_PROXY dla adresów, które powinny omijać proxy, na przykład zatwierdzonych usług wewnętrznych lub adresów lokalnych. Dokładne wpisy zależą od Twojej sieci i używanych narzędzi. Zbyt szeroka wartość może skierować żądania do usług wewnętrznych poza zamierzoną trasą, a zbyt wąska — spowodować, że żądanie do zablokowanego adresu nadal będzie wysyłane bezpośrednio.
Na potrzeby szybkiego, tymczasowego testu możesz ustawić zmienne w sesji terminala przed uruchomieniem polecenia. To przydatny sposób, by sprawdzić, czy instalacja pakietu zadziała, ale nie jest to niezawodna metoda konfiguracji wszystkich terminali ani przyszłych sesji Codespace. Składnia zależy też od powłoki. Nie wklejaj adresu proxy zawierającego dane logowania do polecenia, które może zostać zapisane w historii powłoki.
Aby konfiguracja projektu była powtarzalna, umieść ustawienia niezawierające poufnych danych w używanej przez repozytorium konfiguracji kontenera programistycznego, na przykład w odpowiednim pliku konfiguracyjnym Dev Container lub skrypcie konfiguracyjnym. Nie zapisuj haseł ani tokenów w plikach śledzonych przez system kontroli wersji. Jeśli potrzebujesz danych uwierzytelniających, skorzystaj z zatwierdzonej przez organizację metody wstrzykiwania sekretów i sprawdź, które procesy mogą uzyskać do nich dostęp.
Nie zakładaj, że każda aplikacja korzysta z tych zmiennych. Niektóre narzędzia odczytują ich warianty pisane małymi literami, inne korzystają z własnych plików konfiguracyjnych, a jeszcze inne ignorują zmienne środowiskowe. Przetestuj konkretne polecenie, które wcześniej nie działało. Sama obecność zmiennej HTTPS_PROXY nie dowodzi, że cały ruch z Codespace przechodzi przez proxy.
4. Zachowaj ustawienia proxy po przebudowaniu Codespace
Ustawienie wprowadzone w jednym terminalu może zniknąć po jego zamknięciu lub przebudowaniu Codespace. Aby ustawienia wymagane przez projekt i niezawierające poufnych danych pozostały dostępne, użyj konfiguracji na poziomie repozytorium, która jest stosowana podczas tworzenia kontenera programistycznego. Dzięki temu osoba otwierająca ten sam projekt może korzystać z tej samej podstawowej konfiguracji bez konieczności umieszczania prywatnych danych uwierzytelniających w repozytorium.
Ustawienia osobiste mogą być lepszym rozwiązaniem, jeśli proxy dotyczy tylko Twojego konta albo jeśli jego konfiguracja zawiera dane poufne. Zanim wybierzesz tę opcję, sprawdź zasady organizacji dotyczące Codespaces i dostępne ustawienia. Administrator może ograniczać konfigurację osobistą, używanie sekretów lub korzystanie z określonych funkcji kontenerów programistycznych.
Po zmianie konfiguracji przebuduj Codespace, jeśli zmiana wpływa na sposób tworzenia kontenera. Następnie otwórz nowy terminal i sprawdź zmienne. Przebudowanie to dobry test: jeśli ustawienie proxy zniknie, prawdopodobnie dodano je tylko do poprzedniej powłoki, a nie do trwałego źródła konfiguracji.
Oddziel konfigurację współdzieloną od sekretów. W repozytorium możesz opisać nazwy zmiennych proxy i oczekiwany format, ale prawdziwe hasło należy przekazywać za pomocą zatwierdzonego mechanizmu obsługi sekretów. Dzięki temu zwykłe zatwierdzenie zmian nie ujawni danych logowania wszystkim osobom mającym dostęp do historii projektu.
5. Jeśli to konieczne, zaufaj certyfikatowi proxy
Jeśli żądania HTTPS kończą się błędem weryfikacji certyfikatu, a organizacja potwierdzi, że inspekcja HTTPS jest włączona, kontener może wymagać zaufania urzędowi certyfikacji organizacji. Uzyskaj oficjalny certyfikat i instrukcję instalacji od administratora. Nie wyłączaj weryfikacji certyfikatów w ramach obejścia problemu — może to ukryć problem z przechwytywaniem połączeń zamiast go rozwiązać.
Sposób instalacji zależy od systemu operacyjnego kontenera i obrazu bazowego. Obrazy oparte na Debianie i Alpine oraz obrazy przeznaczone dla konkretnych języków mogą inaczej obsługiwać pakiety certyfikatów. Sprawdź również, czy certyfikat trzeba dodać podczas tworzenia kontenera, aby pozostał dostępny po jego przebudowaniu.
Po zainstalowaniu certyfikatu przetestuj zwykłe żądanie HTTPS do zatwierdzonego adresu, używając tego samego narzędzia, które wcześniej zgłaszało błąd. Jeśli przeglądarka działa, ale klient wiersza poleceń nadal zgłasza niezaufanego wystawcę, może on korzystać z osobnego magazynu certyfikatów lub wymagać własnego ustawienia. Zanim zmienisz konfigurację zaufania, zapytaj administratora, jakiego pliku certyfikatu i formatu należy użyć w kontenerze.
6. Osobno przetestuj Git i narzędzia programistyczne
Zacznij od nieszkodliwego żądania do adresu zatwierdzonego przez administratora. Następnie przetestuj menedżer pakietów lub narzędzie, które wcześniej nie działało. Sukces jednego polecenia nie oznacza, że Git, pip, npm i instalator konkretnego języka korzystają z proxy w ten sam sposób.
W przypadku Gita sprawdź, czy zainstalowana wersja w Twojej konfiguracji odczytuje zmienne środowiskowe proxy. Jeśli nie, Git może wymagać własnej konfiguracji proxy. Nie wpisuj hasła bezpośrednio do pliku konfiguracyjnego Git, który mógłby trafić do repozytorium lub zostać skopiowany do dzienników. Zamiast tego użyj metody obsługi danych uwierzytelniających zatwierdzonej przez organizację.
W przypadku menedżerów pakietów sprawdź zarówno ustawienie proxy, jak i skonfigurowany rejestr. Menedżer pakietów korzystający z wewnętrznego rejestru może nie potrzebować dostępu do tego samego zewnętrznego adresu, co narzędzie pobierające pliki bezpośrednio. Z kolei narzędzie pobierające archiwum wydania może łączyć się z zupełnie innym hostem. Porównaj adres widoczny w błędzie z otrzymaną listą dozwolonych adresów.
Jeśli pojawia się problem z instalacją pakietów w Codespaces za proxy, sprawdź, czy błąd dotyczy adresu proxy, uwierzytelniania, certyfikatu, czy hosta rejestru pakietów. Zapisz, który test zakończył się powodzeniem, który się nie powiódł i jakiej nazwy hosta dotyczył. Taka krótka notatka daje administratorowi konkretne informacje — na przykład: „Git łączy się z zatwierdzonym hostem, ale rejestr pakietów odrzuca żądanie przez proxy” — zamiast ogólnego zgłoszenia, że Codespaces nie ma dostępu do internetu.
7. Diagnozuj problemy z połączeniem bez ujawniania danych logowania
Przeprowadź nieszkodliwy test połączenia z zatwierdzonym adresem i sprawdź, czy wynik wskazuje na problem z rozpoznawaniem DNS, przekroczenie limitu czasu, uwierzytelnianie proxy, zablokowany adres czy weryfikację certyfikatu. Każdy z tych błędów sugeruje inny kolejny krok. Przekroczenie limitu czasu nie oznacza na przykład tego samego co odrzucenie uwierzytelniania.
Sprawdź, czy nazwa hosta i port proxy są zgodne z danymi podanymi przez administratora, i upewnij się, że zmienna jest dostępna w tej samej sesji terminala, w której uruchamiasz test. Jeśli proxy wymaga uwierzytelniania, brakujące lub nieaktualne dane logowania mogą uniemożliwić dostęp nawet wtedy, gdy adres jest prawidłowy.
Przed udostępnieniem wyniku z terminala usuń nazwy użytkowników, hasła, tokeny i adresy URL zawierające dane logowania. Błędy proxy mogą zawierać pełny adres żądania, a historia powłoki może zachować polecenia zawierające sekrety. Zamiast tego podaj rodzaj błędu, nazwę hosta docelowego, nazwę narzędzia i godzinę wystąpienia problemu. Te informacje często wystarczają zespołowi wsparcia sieci do sprawdzenia dzienników.
Jeśli proxy działa w jednym Codespace, ale nie w innym, porównaj konfigurację kontenerów, obrazy systemu operacyjnego, zmienne środowiskowe i ustawienia certyfikatów. Wprowadzaj po jednej zmianie naraz, a następnie powtarzaj ten sam test. Dzięki temu łatwiej ustalić, czy przyczyną jest brak zmiennej, zablokowany adres czy różnica w magazynie zaufanych certyfikatów.