Czy WireGuard jest gotowy na produkcję? Odpowiedź nie leży w protokole

Ludzie pytają, czy WireGuard jest gotowy na produkcję, co brzmi jak pytanie o kryptografię, a w rzeczywistości jest pytaniem o twoje środowisko. Protokół jest analizowany od lat; wdrożenie wciąż musi odpowiedzieć, czy twoje sieci przenoszą jego transport, kto rejestruje i wycofuje urządzenia i kto łata pakiet na obu końcach. Te odpowiedzi różnią się między dwoma serwerami w jednej szafie a tysiącem laptopów. Protokół jest w obu przypadkach ten sam; operacje nie.

Pytanie za pytaniem

Ludzie zwykle chcą wiedzieć, czy mogą zobowiązać się do projektu, który nie wprawi ich w zakłopotanie za pół roku. To pytanie o wdrożenie z czterech części, a każda część może zawieść niezależnie od pozostałych. Dobre odpowiedzi na trzy z nich nie rekompensują czwartej.

Stare ostrzeżenie o wersji przedpremierowej jest faktem o tej wersji, a nie trwałą etykietą na każdym późniejszym pakiecie. Podobnie żaden wpis na blogu nie może ogłosić gotowym twojej konkretnej kombinacji jądra, klienta, sieci i personelu. Praca polega na tym, by kombinację uczynić jawną i ją sprawdzić.

Traktuj gotowość jako zestaw bram, które albo przechodzisz, albo zapisujesz jako otwarte. To zamienia spór w listę kontrolną z właścicielami. To także czyni otwarte punkty widocznymi dla każdego, kto zatwierdza, zamiast grzebać je w raporcie pilotażowym.

Brama pierwsza: ścieżka musi przenosić UDP

WireGuard przenosi swój ruch przez UDP i dokumentuje, że nie oferuje trybu TCP ani zaciemniania ruchu. Projekt, który opiera się na tym, że będzie wyglądał jak zwykły ruch webowy, albo na zmianie portu w celu uzyskania zachowania TCP, stoi na założeniu, którego oprogramowanie nie wspiera.

Pierwszą bramą jest więc rozpoznanie, a nie test na jednej maszynie. Wypisz środowiska dostępu, w których twoi użytkownicy naprawdę pracują, następnie sprawdź zatwierdzoną ścieżkę UDP w każdym z nich i zdecyduj, co się dzieje, gdy jest niedostępna.

Połączenie działające z biura niczego nie dowodzi o sieci hotelowej, zaporze kampusu czy operatorze komórkowym, który obsługuje UDP inaczej. To właśnie te środowiska są powodem, dla którego wdrożenia dostępu zdalnego zawodzą po udanym pilocie. Pilot nie był błędny; był wąski. Jego poszerzenie jest bramą.

Zapisz też ścieżkę awaryjną. Jeśli odpowiedź brzmi, że nie ma ścieżki awaryjnej, to decyzja warta ogłoszenia z góry, a nie odkrycia w trakcie podróży służbowej.

Brama druga: ktoś musi posiadać klucze

Peery WireGuard uwierzytelniają się kluczami, jedna para na uczestnika. To łatwe do opisania i wymagające w eksploatacji, bo nic w protokole nie rejestruje urządzenia, nie śledzi, kto ma który klucz, ani nie odbiera dostępu, gdy laptop zginie. Protokół zakłada, że klucze są już poprawne, a poprawność jest czyjąś pracą.

Nazwij osobę, która rejestruje urządzenie, rekord wiążący klucz publiczny z osobą i urządzeniem oraz procedurę usuwania. Jeśli usuwanie zależy od pamiętania, gdzie zainstalowano kopie pliku konfiguracyjnego, procedura nie jest skończona.

Wybierz jedno urządzenie podczas pilota i wycofaj je od początku do końca. To ćwiczenie daje użyteczniejsze informacje niż kolejny test łączności, bo ujawnia luki w twoich rejestrach.

Brama trzecia: pakiet potrzebuje opiekuna

WireGuard może przyjść jako implementacja w jądrze, jako pakiet dystrybucji lub jako klient w przestrzeni użytkownika, a każdy ma własną ścieżkę aktualizacji. Pytanie operacyjne brzmi, którą wersję uruchamiasz, skąd przyszła i kto stosuje biuletyn bezpieczeństwa.

Używamy WireGuard to nie inwentarz. Nie wskazuje pakietu do załatania, wersji na bramie ani osoby, która potrafi wycofać złą aktualizację.

Brama czwarta: zaakceptuj obciążenie pracą, nie uzgadnianie połączenia

Kryteria akceptacji powinny opisywać, co robią użytkownicy. Dotarcie do aplikacji wewnętrznej, rozwiązanie jej prywatnej nazwy, odmowa na nieautoryzowanym celu i przestrzeganie zdefiniowanego zachowania, gdy tunel jest wyłączony, są wszystkie obserwowalne, a udane uzgadnianie połączenia nie jest żadnym z nich.

Przeprowadź te kontrole przez zmianę sieci, restart urządzenia i okno serwisowe bramy, bo właśnie na tych przejściach wdrożenia się łamią.

Trzymaj dowody obok kryteriów, wraz z lokalnym stanem, który je wytworzył:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Zielony test w spokojnej sieci z jednym laptopem to obserwacja początkowa. To nie jest twierdzenie o niezawodności, a traktowanie go tak jest drogą, którą działający projekt staje się projektem, któremu się ufa.