Twoja brama VPN nadal potrzebuje sposobu na instalowanie aktualizacji

Tunel działa dla wszystkich za nim, brama przekazuje ich ruch, a jednak sam host nie potrafi zainstalować aktualizacji bezpieczeństwa. To typowy kształt problemu: uprawnienie do przekazywania przyznano klientom, a własne połączenia wychodzące bramy nigdy nie trafiły do planu. Menedżer pakietów otwiera własne gniazda, z bramy, do repozytorium, którego prawdopodobnie nigdzie nie nazwałeś w polityce zapory.

Zabezpieczenie bramy jest słuszne. Zabezpieczenie jej tak gruntownie, że przestaje otrzymywać poprawki, to inna decyzja, i zwykle przypadkowa.

Ruch lokalny to nie przekazywanie klientów

Reguły przekazywania dotyczą pakietów, które przychodzą skądinąd i wychodzą przez bramę. Własny ruch aktualizacyjny bramy nigdy ich nie dotyczy; powstaje lokalnie i podąża ścieżką wyjściową. Ta różnica wyjaśnia awarię, która wygląda na niemożliwą, podczas gdy dostęp klientów działa bezbłędnie.

Wyjaśnia też lukę w polityce, która przetrwa testy, bo szybkie sprawdzenie z laptopa za tunelem dowodzi, że łańcuch przekazywania działa, i nic nie mówi o własnych połączeniach hosta. Traktuj bramę jako dwa podmioty: router z łańcuchem przekazywania i host z łańcuchem wyjściowym. Oba potrzebują zdania, a zwykle zapisuje się tylko jedno.

Nazwij etap, który zawiódł

Błędy aktualizacji nazywają różne granice, a sięganie po regułę portu, zanim przeczyta się, która zawiodła, kosztuje popołudnie. Nazwa repozytorium, której nie da się rozwiązać, to pytanie do resolvera, a nie pytanie o transport.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

Przekroczenie limitu czasu po udanym rozwiązaniu nazwy przenosi pytanie na transport: jaki adres, jaki port i jaki skonfigurowany proxy menedżer pakietów faktycznie wypróbował. Błąd weryfikacji TLS to trzecia, zupełnie inna sprawa, i oznacza, że połączenie działało wystarczająco dobrze, by wynegocjować sesję. Skarga na uwierzytelnianie archiwum to czwarty etap, i dotyczy podpisanych metadanych, a nie osiągalności. Cztery etapy, cztery różne naprawy, a ping zawsze opisuje tylko jeden protokół, którego żaden menedżer pakietów nie używa.

Przeczytaj listę źródeł, zanim dodasz regułę

Wypisz rzeczywiste URI źródeł i efektywną konfigurację proxy, a nie te, które pamiętasz. Reguła napisana dla zwykłego HTTP jest bezużyteczna, gdy źródło korzysta z HTTPS, a proxy znany powłoce może być niewidoczny dla usługi uruchamianej przy starcie w innym środowisku.

Dokumentacja transportu HTTP w APT obejmuje ustawienia proxy środowiskowe i specyficzne dla APT, w tym wybory dla poszczególnych hostów, a jej transport HTTPS ma własne ustawienia weryfikacji. Ścieżka przeglądarki i ścieżka menedżera pakietów to osobne ścieżki, nawet na tej samej maszynie.

Zanotuj, do jakich rodzin rozwiązują się źródła. Reguła zezwalająca tylko na IPv4 będzie nadal zawodzić na hoście, którego źródła preferują rekord AAAA, a błąd wygląda na okresowy, bo zależy od tego, która odpowiedź dotrze pierwsza.

Wybierz jedną ścieżkę utrzymania i się jej trzymaj

Istnieją trzy możliwe do obrony opcje: ruch utrzymaniowy przez tunel, przez zarządzane proxy aktualizacji albo przez wąski wyjątek bezpośredni. Wybierz jedną świadomie i doprowadź do tego, by resolver się z nią zgadzał, ponieważ podział, w którym nazwy rozwiązują się w jedną stronę, a połączenia idą w drugą, daje awarie, których nikt nie umie wyjaśnić.

Cokolwiek wybierzesz, nie może to stać się nieograniczonym rozwiązaniem zastępczym. Jeśli bezpośredni ruch wychodzący jest zabroniony, gdy tunel nie działa, wyjątek utrzymaniowy, który po cichu pozwala na wszystko, jest zmianą polityki udającą poprawkę. Trzymaj własny punkt końcowy tunelu i potrzeby bootstrapu w osobnej kategorii niż dostęp do repozytoriów, bo wskazują na różne miejsca docelowe i zawodzą na różne sposoby, więc jedno wyłączenie nie może zastąpić drugiego.

Weryfikuj bez osłabiania kontroli

Zastosuj zakres przez zaporę, która już włada polityką, zamiast dodawać drugi menedżer, bo jedna instrukcja go używała. Następnie uruchom odświeżenie metadanych i jedną prawdziwą transakcję pakietową w ramach utrzymywanej polityki, i przeczytaj dane wyjściowe, a nie sam kod wyjścia.

Udany transport nie jest pozwoleniem na poluzowanie weryfikacji. Uwierzytelnianie archiwum i tożsamość serwera TLS to osobne gwarancje, a wyłączenie którejkolwiek z nich, by uciszyć błąd, zmienia to, czemu ufasz, a nie to, do czego docierasz.

Zakończ świadomym testem przypadku bez tunelu. Wiedza o tym, jak brama zachowuje się bez tunelu, należy do projektu, odkrycie tego podczas awarii już nie. Wyłącz tunel, uruchom odświeżenie metadanych i potwierdź, że host zawodzi w zamierzony sposób, a nie po cichu cofa się na otwartą ścieżkę. Trzymaj dane logowania do repozytoriów i proxy poza współdzieloną diagnostyką i zostaw notatkę wskazującą, kto odpowiada za ścieżkę aktualizacji.