Pierwsze uruchomienie: rejestracja floty urządzeń WireGuard

Jeden obraz, jeden klucz na płytkę i krok autoryzacji, który nie ufa twierdzeniu samego urządzenia. Cztery etapy od rozruchu do zatwierdzonego peera.

Płytka uruchamia się ze wspólnego obrazu, otrzymuje dzierżawę DHCP, a skrypt przygotowania działa, zanim ktokolwiek dotknął urządzenia. Gdzieś w tym skrypcie musi uzyskać tożsamość WireGuard należącą do tej płytki i do żadnej innej, doprowadzić do autoryzacji tej tożsamości i zapisać profil, który zaakceptuje brama. Obraz może przenosić oprogramowanie klienta, sprawdzony szablon i klucz publiczny bramy. Tym, czego nigdy nie może przenosić, jest jeden klucz prywatny współdzielony przez całą flotę, ponieważ zamienia to jedną skradzioną płytkę w incydent dla całej floty. Poniższa kolejność utrzymuje tożsamość lokalnie, a autoryzację jawnie.

Co obraz przenosi, a czego nie

Dostarczaj paczkę, szablon z symbolami zastępczymi, klucz publiczny bramy i klienta rejestracji. Szablon to forma, nie tajemnica: powinien być czytelny dla użytkownika przygotowania i nie zawierać żadnego materiału klucza.

Klucz prywatny jest generowany na urządzeniu przy pierwszym uruchomieniu i nigdy go nie opuszcza. Podróżuje tylko połowa publiczna, wewnątrz żądania rejestracji autoryzowanego przez coś innego niż twierdzenie samego urządzenia o tym, kim jest. To właśnie ta różnica powstrzymuje skradzioną płytkę przed staniem się problemem całej floty. I to jest ta część, którą większość skryptów pierwszego uruchomienia robi źle.

Krok 1: wygenerować klucz lokalnie

Uruchom generowanie w chronionym katalogu po zatwierdzeniu i uruchomieniu podstawowego połączenia sieciowego. Podpowłoka utrzymuje zmianę umask lokalnie dla tej operacji, a set -C odmawia nadpisania istniejącego pliku:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

Szybki start WireGuard dokumentuje zależność generowania kluczy, na której opierają się te dwie komendy. Jeśli generowanie zostanie przerwane, pozostaw urządzenie niezarejestrowane i pozwól przepływowi pracy uzgodnić pliki. Nie usuwaj istniejącej tożsamości tylko po to, by skrypt czysto przeszedł od początku.

Zachowaj oczekujący klucz między ponowieniami. Ponowne generowanie tożsamości po każdej chwilowej awarii sieci to sposób, w jaki flota zostaje z osieroconymi peerami, których nikt nie potrafi dopasować do urządzenia.

Krok 2: autoryzować rekord urządzenia

Załóżmy, że inwentarz nazywa tę płytkę device-042 i przydziela jej 10.90.0.42/32. Usługa rejestracji musi zweryfikować, że ten wnioskujący ma prawo do tego rekordu. Numer seryjny wpisany w formularz nie jest dowodem, ponieważ numery seryjne są drukowane na zewnątrz pudełka.

Poświadczenie startowe na urządzenie, zatwierdzenie przez operatora lub atestacja wspierana sprzętowo mogą ustalić twierdzenie. Chroń integralność żądania i autentyczność odpowiedzi i nie zastępuj jednego współdzielonego sekretu VPN jednym współdzielonym poświadczeniem fabrycznym.

Zarejestrowany rekord wiąże urządzenie, jego klucz publiczny, przydzielony adres i dozwoloną rolę zarządzania. Sam WireGuard nie definiuje żadnego API rejestracji, więc ta usługa to coś, co świadomie budujesz i utrzymujesz.

Krok 3: zapisać dwie pasujące konfiguracje

Urządzenie potrzebuje profilu, który kieruje prefiksy zarządzania do tunelu, a brama potrzebuje wpisu peera, który dopuszcza tylko własny adres źródłowy tego urządzenia. Przy bramie pod 10.90.0.1 i sieci zarządzania 10.60.0.0/16 strona urządzenia wygląda tak:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

Wartości w nawiasach kwadratowych to symbole zastępcze, nie klucze. Keepalive ma znaczenie, gdy płytka siedzi za NAT i musi pozostać osiągalna; nie jest wymagany wszędzie, a dodawanie go z przyzwyczajenia trzyma radio w stanie czuwania bez powodu.

Na bramie wpis peera jest celowo wąski:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

Nie kopiuj listy miejsc docelowych urządzenia do wpisu peera na bramie. Na urządzeniu ta lista mówi, co kierować do tunelu; na bramie mówi, których adresów źródłowych ten peer może używać, a to są różne stwierdzenia.

Przekazywanie, reguły zapory i droga powrotna do sieci zarządzania nadal muszą dopuszczać zatwierdzony dostęp. Zarejestrowany peer nie jest zezwoleniem dla każdej aplikacji za nim.

Krok 4: zatwierdzić rejestrację jako stan cyklu życia

Zastosuj rekord bramy i profil urządzenia przez tego, kto posiada daną konfigurację, a następnie oznacz rejestrację jako zakończoną tylko wtedy, gdy zamierzona tożsamość i adres zostaną zaakceptowane. Ponowienia powinny uzgadniać ten sam rekord, zamiast przydzielać drugiego peera lub drugi adres.

Utrzymuj ścieżkę odzyskiwania dla przerwanego przygotowania, w tym przypadek, gdy brama zaakceptowała klucz, a urządzenie nigdy nie zapisało swojego profilu.

Gdy płytka jest wymieniana lub wycofywana, usuń jej klucz publiczny i jej autoryzację razem. Nowy klucz to świadome zdarzenie ponownej rejestracji, a nie skutek uboczny ponownego wgrania obrazu. Kolejność pracy: wygenerować lokalnie, autoryzować wobec inwentarza, zapisać obie strony, zatwierdzić stan, a następnie przetestować jedno żądanie zarządzania przez tunel.

Powiązane artykuły