Nie potrzebujesz klucza prywatnego, aby debugować VPN

Prośba brzmi rozsądnie: wyślij konfigurację, żeby wsparcie zobaczyło, co jest nie tak. W ten sposób klucze prywatne trafiają do systemów zgłoszeń i logów czatu. Konfiguracja to tożsamość, nie diagnostyka, a osoba debugująca twój tunel prawie nigdy nie potrzebuje tej połowy, która dowodzi, kim jesteś. Wyjście statusu odpowiada na te same pytania bez tego ryzyka.

Mit głosi, że konfiguracja to jedyny pełny obraz. To najmniej bezpieczny pełny obraz.

Mit: wsparcie potrzebuje konfiguracji

Wsparcie potrzebuje tekstu błędu, wersji klienta i serwera, punktu końcowego, stanu uzgadniania i kolejności zdarzeń. To wszystko jest statusem. Konfiguracja dodaje klucze, a klucze są tym, co pozwala komuś innemu być tobą. Przekazanie konfiguracji, żeby naprawić problem z routingiem, jest jak wysłanie paszportu pocztą, żeby wyjaśnić opóźniony lot. Prośba zwykle pochodzi od kogoś, kto nigdy nie widział twojej sieci, i dotyczy rzeczy najłatwiejszej do załączenia.

Wyślij najmniejsze wyjście, które odpowiada na pytanie, nie największe, jakie znajdziesz.

Co status faktycznie pokazuje

WireGuard wg show wypisuje interfejsy, peerów, dozwolone adresy IP, punkty końcowe, ostatnie uzgadnianie i liczniki transferu, a nie wypisuje klucza prywatnego. Wyjście statusu i logu OpenVPN podaje stan połączenia i błędy bez wbudowanych bloków kluczy. Oba wystarczą, żeby zobaczyć, czy uzgadnianie się kończy, czy liczniki się ruszają i który peer jest używany, co podręcznik wg dokumentuje jako widok statusu.

Jeśli pomocnik prosi o konfigurację, zanim poprosi o to wyjście, zapytaj, co konfiguracja pokazałaby, czego status nie pokazuje.

Gdzie w każdym formacie ukrywają się sekrety

Pliki konfiguracji WireGuard zawierają linie PrivateKey, a publiczne klucze peerów i metadane punktu końcowego nadal identyfikują nawet bez nich. Profile OpenVPN mogą osadzać bloki <key> i <tls-crypt> albo wskazywać osobne pliki, które podróżują z profilem. Archiwum wsparcia klienta może zawierać znacznie więcej, niż pokazuje okno logu, w tym profile w pamięci podręcznej, o których istnieniu zapomniałeś. Zrzuty ekranu to drugi częsty wyciek, bo okno terminala pokazuje więcej niż polecenie, które chciałeś udostępnić.

Przeczytaj dokumentację eksportu, a potem otwórz plik. Wyjście oznaczone jako diagnostyka niekoniecznie zostało z czegokolwiek oczyszczone.

Zredaguj, a potem wyślij sprawdzoną kopię

Trzymaj oryginał w chronionym miejscu i wysyłaj sprawdzoną kopię. Zastąp punkty końcowe i klucze publiczne stabilnymi znacznikami zastępczymi, gdy prawdziwe wartości nie są potrzebne, a bloki klucza prywatnego usuwaj w całości, zamiast częściowo je zasłaniać. Częściowe zasłonięcie bloku base64 to nadal ujawniony klucz. Przeczytaj plik jeszcze raz, zanim wyjdzie, bo archiwa często niosą drugą kopię tego samego profilu.

Użyj zweryfikowanego kanału i sprawdź, kto go otrzyma, zanim cokolwiek załączysz.

Jeśli klucz już wyciekł

Usunięcie wiadomości nie odzyskuje kopii, które inni już mają. Wymień tożsamość przez proces odwołania i zastąpienia u operatora i traktuj stary klucz jako skompromitowany od chwili wysłania. Większość operatorów szybko wymieni tożsamość klienta, gdy zgłoszono ujawnienie, a właśnie zgłoszenie jest tą częścią, którą ludzie odkładają.

Ta sama zasada dotyczy klucza wklejonego do zgłoszenia, zrzutu ekranu lub wątku czatu. Rotacja jest rozwiązaniem; usuwanie to sprzątanie.