Jak udostępnić serwer deweloperski webpack pod adresem VPN

Wybierz adres nasłuchu w zależności od tego, kto musi dotrzeć do serwera deweloperskiego, następnie zawęź sprawdzanie nazwy hosta i potwierdź, że zarówno strona, jak i gniazdo przeładowania na żywo się łączą.

Serwer deweloperski, który odpowiada na laptopie i nigdzie indziej, jest zwykle powiązany z niewłaściwym adresem. Serwer, który akceptuje połączenie, ale odrzuca stronę, zwykle nie przechodzi sprawdzania nazwy hosta. To różne usterki z różnymi poprawkami, a wybór właściwej konfiguracji zależy od tego, kto musi dotrzeć do obszaru roboczego i jak tam trafia.

Odpowiedź określają trzy pytania: kto się łączy, jaki adres może osiągnąć i czy przeładowanie na żywo musi dla niego działać.

Zacznij od gniazda, a nie od pliku konfiguracyjnego

Przeczytaj, do czego faktycznie przypisany jest działający proces, w tym samym kontekście sieciowym, który go uruchomił, ponieważ kontener lub przestrzeń nazw może posiadać gniazdo, którego powłoka hosta nie widzi. Kolumna nasłuchu odpowiada na pierwsze pytanie: tylko ścieżka lokalna, jeden konkretny interfejs czy wszystkie interfejsy.

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

Adres pętli zwrotnej jest bezpiecznym ustawieniem domyślnym i bezużytecznym dla zdalnego klienta. Powiązanie z symbolem wieloznacznym jest wygodne i wystawia port na każdym interfejsie, który ma trasę, co jest szersze, niż większość ludzi zamierza na maszynie, która niesie też tunel. Konkretny adres to opcja pośrednia i działa tylko wtedy, gdy interfejs posiada ten adres w chwili tworzenia gniazda. Rozróżnienie ma znaczenie, ponieważ dwa z tych trzech powiązań wyglądają w przeglądarce identycznie i zachowują się zupełnie inaczej, gdy istnieje drugi interfejs.

Dostosuj się do tej obserwacji, zanim dotkniesz tras lub reguł zapory. Jeśli proces nasłuchuje na niewłaściwym adresie, żadne trasowanie polityk nie doprowadzi do niego klienta.

Wybierz adres powiązania według tego, kto musi do niego dotrzeć

Jeśli tylko ty na tej maszynie potrzebujesz strony, zachowaj powiązanie z pętlą zwrotną i skończ. Jeśli potrzebuje jej jeden kolega w tym samym tunelu, powiąż adres interfejsu tunelu i pozwól zaporze dopuścić tylko to źródło. Publikowanie serwera deweloperskiego poza krąg osób, które go aktywnie testują to nawyk, który w końcu wystawia obszar roboczy na internet.

Jeśli przeglądarka w kontenerze musi dotrzeć do serwera, adres powiązania musi być taki, do którego sieć kontenera potrafi trasować, a to często nie jest adres, który host rozwiązuje dla siebie. Zdecyduj o przypadku przed edycją konfiguracji, ponieważ trzy przypadki dają trzy różne wartości i tylko jedna jest właściwa. Zgadywanie tutaj traci więcej czasu niż jakakolwiek inna część konfiguracji.

Następnie ustaw adres w formie, którą twój launcher naprawdę czyta. Plik konfiguracyjny i skrypt, który buduje serwer programowo, nie zużywają tych samych opcji:

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

Adres w tym fragmencie jest ilustracyjny i oznacza adres VPN, który posiada host. Jeśli projekt buduje serwer za pomocą new WebpackDevServer(options, compiler) przekaż opcje przez argument konstruktora, ponieważ oddzielna właściwość devServer w konfiguracji webpacka nie jest na tej ścieżce sprawdzana. Ta różnica między plikiem konfiguracyjnym a Node API łapie osoby, które kopiują fragment do projektu, który nigdy go nie czyta. Dokumentacja dev-servera rozdziela dwa style uruchamiania i jest referencją, z którą należy porównać używaną wersję.

Dopasuj sprawdzanie nazwy hosta do nazw, które zatwierdzasz

Sprawdzanie nazwy hosta istnieje po to, aby strona serwowana z nazwy kontrolowanej przez atakującego nie rozmawiała z twoim serwerem deweloperskim przez przeglądarkę. Wyłączenie go za pomocą allowedHosts: "all" usuwa tę ochronę, a wygoda rzadko jest tego warta na maszynie, która może dotrzeć do usług wewnętrznych. Sprawdzenie jest tanie do poprawnego spełnienia, gdy wiesz, jakie nazwy wyśle przeglądarka.

Wymień dokładne nazwy, których będziesz używać, w tym nazwę prywatną, która rozwiązuje się na adres tunelu. Jeśli klient rozwiązuje nazwę na inny adres niż ten, z którym powiązałeś nasłuch, masz problem z rozwiązywaniem nazw, a nie z konfiguracją serwera, i dodanie nazwy do listy dozwolonych tego nie naprawi. Potwierdź rozwiązanie od klienta, nie od serwera.

Trzymaj trzy mechanizmy oddzielnie w głowie: adres powiązania decyduje, które interfejsy przyjmują połączenie, lista dozwolonych decyduje, które nagłówki Host są akceptowane, a uwierzytelnianie decyduje, kto może wejść. Tylko trzeci jest kontrolą dostępu, a serwer deweloperski zwykle nie ma żadnej. Adres tunelu też nie jest mechanizmem uwierzytelniania, ponieważ każdy, kto potrafi do niego trasować, jest już wewnątrz granicy, na której polegałeś.

Sprawdź stronę i gniazdo przeładowania na żywo razem

Wczytaj świeże żądanie od zamierzonego klienta ze skonfigurowanym schematem i czytaj wynik, a nie pamięć podręczną. W przypadku HTTPS zachowaj oczekiwaną nazwę hosta i walidację certyfikatu, ponieważ ostrzeżenie przeglądarki nie jest udanym testem akceptacyjnym. Strona, która się renderuje, gdy przeładowanie na żywo po cichu zawodzi, jest tutaj najczęstszym częściowym sukcesem i łatwo ją przeoczyć podczas szybkiego sprawdzenia.

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

Następnie otwórz diagnostykę sieci przeglądarki i obserwuj połączenie WebSocket. Strona może się wczytać przez jedną nazwę hosta, port i schemat, podczas gdy gniazdo przeładowania używa innych, dlatego oba trzeba sprawdzić osobno. Konfiguruj udokumentowany adres URL klienta tylko wtedy, gdy wdrożona ścieżka naprawdę wymaga innej wartości, i preferuj naprawienie ścieżki zamiast uczenia klienta obejścia.

Zapisz adres nasłuchu, zaakceptowaną nazwę, dozwolone źródło i oba wyniki w notatkach projektu. Ten zapis przetrwa następną osobę, która uruchomi obszar roboczy i zastanowi się, dlaczego strona się wczytuje, ale nigdy nie odświeża.

Powiązane artykuły