Klucz prywatny tutaj, klucz publiczny tam: klucze WireGuard
Twój klucz prywatny zostaje na urządzeniu; wpis partnera zawiera klucz publiczny drugiej strony. Udostępniaj tylko publiczną połowę i daj każdemu urządzeniu własną tożsamość.
Większość ręcznie składanych awarii WireGuard sprowadza się do tego, który klucz trafił gdzie. Sekcja interfejsu zawiera klucz prywatny urządzenia, które konfigurujesz, a sekcja partnera zawiera klucz publiczny maszyny po drugiej stronie. Zamiana tych połówek albo wklejenie niewłaściwej daje uzgadnianie, które nigdy się nie kończy, i log, który nigdy nie nazywa klucza. Wykonaj cztery kontrole poniżej po kolei, zanim dotkniesz AllowedIPs lub DNS.
Dwa klucze, dwa kierunki
Klucz prywatny należy do dokładnie jednego urządzenia i pozostaje w sekcji interfejsu tego urządzenia. Jego publiczna połowa to to, czego każdy inny partner potrzebuje, aby rozpoznać urządzenie, a narzędzia ją wyprowadzają, zamiast wymyślać. Na serwerze klucz publiczny twojego urządzenia pojawia się jako wpis partnera; na twoim urządzeniu tę rolę pełni klucz publiczny serwera. Głośne czytanie konfiguracji w tych terminach wyłapuje większość pomyłek, zanim dotrą do uzgadniania.
Polecenie wg wypisuje, czego lokalny interfejs naprawdę używa, łącznie z oboma kluczami publicznymi. Dzięki temu jest najszybszym sposobem odróżnienia błędu konfiguracji od problemu z łącznością:
wg show
wg show interfacesPierwsze wyjście wymienia każdego partnera z jego kluczem publicznym, ostatnio używanym punktem końcowym i wiekiem ostatniego uzgadniania. Wiek uzgadniania „nigdy” po jednej stronie i świeży po drugiej wskazuje klucz, który przyjął tylko jeden koniec. Drugie polecenie nazywa interfejsy, które możesz zbadać dalej.
Co udostępniać, a czego nigdy
Klucz publiczny jest przeznaczony do przekazania, choć nadal identyfikuje relację urządzeń, dlatego wysłanie go administratorowi, który o niego poprosił, różni się od jego opublikowania. Klucz prywatny nigdy nie opuszcza urządzenia, które go wygenerowało. Wyeksportowany profil lub kod QR zawiera całą konfigurację, w tym ten klucz prywatny, więc żaden z nich nie jest bezpieczny do przekazywania, a ukrycie tekstu w obrazie niczego nie zmienia. Klucze wstępnie współdzielone są opcjonalne i równie tajne, a oba końce muszą mieć tę samą wartość, inaczej uzgadnianie zatrzymuje się na tym etapie.
Jeszcze jedno rozróżnienie warto powiedzieć wprost: punkt końcowy to adres i port, nigdy klucz. Wklejenie klucza publicznego w pole punktu końcowego albo adresu w pole klucza daje profil, który się analizuje, a potem nic nie robi. Narzędzia tego nie wyłapią, bo oba pola to tylko ciągi znaków. Szybki start WireGuard pokazuje łańcuch generowania i wyprowadzania w jednej linii.
Jedno urządzenie, jeden wpis partnera
Gdzie usługa na to pozwala, każde urządzenie powinno mieć własną tożsamość partnera. Wklejenie pełnego profilu laptopa na telefon rozmywa, które urządzenie ma tę tożsamość na serwerze, i utrudnia odwołanie jednego zgubionego telefonu. Jeśli klucz prywatny wycieknie, usuń stare uprawnienie partnera na serwerze i zapewnij zamiennik. Usunięcie pliku lokalnego nie usuwa wpisu na serwerze, a nowy klucz klienta nikomu nie pomoże, dopóki serwer nie zna jego publicznej połowy.
Trzymaj przyporządkowanie urządzenia do klucza publicznego obok listy adresów. To ta lista zamienia odwołanie w zadanie na dwie minuty zamiast całego popołudnia.
Co nadal zawodzi po uzgadnianiu
Pary kluczy identyfikują partnerów; nie decydują o zachowaniu sieci. AllowedIPs wiąże zakresy adresów z partnerem, a trasami wokół zarządza klient lub narzędzie konfiguracyjne. Objaw zwykle mówi, którą warstwę otworzyć następną:
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
DNS może zawieść po tym, jak oba końce poprawnie się uwierzytelnią, a aplikacja może zawieść, gdy sam tunel jest zdrowy, więc działające uzgadnianie nie jest końcem diagnozy. Klucze nie mówią też nic o praktyce logowania operatora ani o tym, czy witryna rozpoznaje twoje konto, a te pytania należą gdzie indziej. Przejdź do warstw sieci, gdy cztery kontrole przejdą, bo brakujący klucz nie jest zamaskowanym problemem routingu.