Bezpieczna konfiguracja sieci VPN WireGuard dla administratorów serwerów

Sieć serwisowa zamiast publicznie dostępnych portów administracyjnych

Publicznie dostępne porty administracyjne zwiększają powierzchnię ataku serwera: próby logowania przez SSH, błędne konfiguracje interfejsów administracyjnych oraz przypadkowo ujawnione usługi monitorujące są dostępne bezpośrednio z obcych sieci. Dostęp za pośrednictwem WireGuard zmniejsza tę widoczność, ponieważ na początku dostępny musi pozostać jedynie określony port UDP dla szyfrowanego tunelu. WireGuard nie maskuje jednak ruchu jako HTTPS i nie oferuje trybu transportu TCP.

Odpowiednim modelem docelowym dla administracji siecią VPN jest zazwyczaj sieć typu „hub-and-spoke”: serwer obsługuje interfejs wg0 i otrzymuje w tym celu np. adres wewnętrzny 10.77.0.1. Laptop osoby uprawnionej łączy się jako oddzielny węzeł i korzysta np. z adresu 10.77.0.10. Protokół SSH, wewnętrzna konsola internetowa lub punkty końcowe monitoringu akceptują wówczas połączenia za pośrednictwem sieci tunelowej zamiast poprzez publiczny adres serwera.

Nie jest to sieć VPN dla użytkowników końcowych, której zadaniem jest przekierowywanie całego ruchu internetowego z urządzenia. W przypadku konserwacji bardziej sensowny jest model dostępu o wąskim zakresie: tunel służy wyłącznie jako droga do jasno określonych celów administracyjnych. Pełny tunel można co prawda zastosować celowo, ale powoduje on dodatkowe zmiany w routingu, korzystaniu z DNS oraz dostępności usług zewnętrznych. Te skutki uboczne zazwyczaj nie są konieczne w przypadku dostępu przeznaczonego wyłącznie do celów konserwacyjnych.

Das Sieć serwisowa stanowi wyłącznie ograniczenie sieciowe. Nie decyduje o tym, które konto w systemie Linux może się zalogować, jakie polecenia może ono wykonywać ani czy system operacyjny jest aktualny. Dodatkowo potrzebne są klucze SSH i konta osobiste, odpowiednio ograniczone uprawnienia sudo, reguły zapory sieciowej, aktualizacje zabezpieczeń, rejestrowanie zdarzeń oraz zadbany dostęp awaryjny. Dzięki temu błąd w pojedynczej warstwie zabezpieczeń nie będzie jedynym czynnikiem decydującym o dostępie.

Prawidłowe przypisanie kluczy, węzłów równorzędnych i adresów IP z listy dozwolonych

Każdy węzeł WireGuard posiada własną parę kluczy. Klucz prywatny pozostaje wyłącznie na odpowiednim serwerze, laptopie lub urządzeniu administracyjnym; po stronie przeciwnej przechowywany jest jedynie wygenerowany na jego podstawie klucz publiczny. Opcjonalny klucz PresharedKey uzupełnia kryptografię klucza publicznego o dodatkowy klucz symetryczny. Stanowi on dodatkową warstwę zabezpieczeń, ale nie zastępuje ani kluczy prywatnych, ani przejrzystego systemu zarządzania kluczami.

Umieść jeden Peer na urządzenie a nie wspólnego węzła dla zespołu. Dzięki temu można w sposób ukierunkowany usunąć utraconą stację roboczą lub urządzenie dostawcy usług, które nie jest już potrzebne. Klucze WireGuard umożliwiają dostęp do sieci serwisowej. Niezależnie od tego klucze SSH służą do uwierzytelniania osoby lub urządzenia w stosunku do serwisu SSH; w związku z tym cofnięcie uprawnień musi być zaplanowane na obu poziomach.

Szczególnie ważne są Dopuszczalne adresy IP na serwerze. W WireGuard tworzą one tabelę routingu Cryptokey: w przypadku pakietów wychodzących określają one odpowiedniego partnera na podstawie adresu docelowego. W przypadku pakietów przychodzących, które zostały już uwierzytelnione, ograniczają one jednocześnie wewnętrzne adresy źródłowe, z których może korzystać ten peer. Ustawienie to jest zatem czymś więcej niż zwykłym określeniem trasy.

Jeśli laptop administratora otrzyma adres 10.77.0.10, to na serwerze dla właśnie tego węzła AllowedIPs = 10.77.0.10/32. Przydział /32 wiąże pojedynczy adres tunelu z tym węzłem partnerskim. Gdybyś przydzielał każdemu węzłowi administracyjnemu standardowo adres 10.77.0.0/24, przypisanie to stałoby się niejasne, a konfiguracja byłaby niepotrzebnie zbyt szeroka. Sprawdź również, czy wybrana sieć VPN nie koliduje z sieciami lokalnymi, kontenerowymi ani domowymi.

Planowanie granic sieci i modelu dostępu

Przed instalacją zaplanuj sieć adresową VPN. Wybierz zakres adresów prywatnych, który nie pokrywa się ani z istniejącymi sieciami LAN, sieciami w chmurze, sieciami Docker lub Kubernetes, ani z często używanymi sieciami domowymi. Określ, które systemy mają być dostępne przez tunel: tylko serwer bramy, wyodrębniona sieć administracyjna czy poszczególne usługi. Na tej podstawie zostaną później ustalone trasy klientów, reguły zapory sieciowej oraz, w razie potrzeby, trasy powrotne.

Dla każdego urządzenia należy udokumentować: użytkownika odpowiedzialnego za urządzenie, publiczny klucz WireGuard, stały adres IP tunelu, cel udostępnienia oraz sposób cofnięcia uprawnień. Grupy powinny być tworzone w oparciu o zadania, takie jak obsługa systemu, obsługa baz danych lub wsparcie zewnętrzne, a nie na podstawie ogólnego założenia „VPN ma pełny dostęp“. Ponadto należy zapewnić niezależny dostęp awaryjny, na przykład konsolę dostawcy usług. Należy go sprawdzić przed wprowadzeniem zmian w zaporze sieciowej, SSH lub routingu, aby błędna reguła nie spowodowała zablokowania dostępu.

Die Firewall jest to główna granica sieci: zezwala na port UDP WireGuard na interfejsie publicznym, ale połączenia SSH przyjmuje wyłącznie przez interfejs wejściowy wg0 lub faktycznie używany interfejs WireGuard. Dodatkowa weryfikacja sieci źródłowej VPN może jeszcze bardziej zawęzić zakres reguły, nie może jednak zastąpić powiązania z interfejsem. W ten sposób zapora sieciowa nie akceptuje pakietów przychodzących na interfejs publiczny wyłącznie na podstawie deklarowanego adresu źródłowego VPN. WireGuard przypisuje uwierzytelnione adresy wewnętrzne do węzłów partnerskich; gwarancja ta dotyczy pakietów przyjętych przez interfejs tunelowy.

Na poziomie SSH stosuje się klucze zamiast logowania za pomocą hasła, konta osobiste oraz reguły dotyczące polecenia `sudo` ograniczone w jak największym stopniu. OpenSSH może współpracować z AllowUsers Dodatkowe powiązanie kont z adresami źródłowymi lub sieciami CIDR. Ta druga bariera stanowi uzupełnienie tej z wg0 powiązaną regułę zapory, ale jej nie zastępuje.

Publiczne aplikacje internetowe nadal wymagają własnego zabezpieczenia połączenia za pomocą protokołu HTTPS oraz odpowiednich certyfikatów. Przewodnik po zabezpieczaniu stron internetowych za pomocą protokołu TLS Ten poziom dotyczy dostępu za pośrednictwem przeglądarki. Natomiast WireGuard chroni dostęp do prywatnej sieci administracyjnej; nie zastępuje on ani protokołu TLS w usługach publicznych, ani procesów logowania, weryfikacji uprawnień i konserwacji.

Konstrukcja podstawowa z wykorzystaniem wg-quick bez pułapek routingu

W przypadku pojedynczego serwera serwisowego wystarczy scenariusz typu punkt-punkt: serwer obsługuje wg0 z adresem tunelu 10.77.0.1/24, laptop administracyjny jest stale 10.77.0.10/32. Serwer publiczny akceptuje wyłącznie połączenia UDP dla WireGuard. Poniższe pliki stanowią propozycję konfiguracji dla wg-quick; celowo nie zawierają one prawdziwych kluczy.

Na serwerze węzeł łączy klucz publiczny laptopa z jego konkretnym adresem tunelu. Klucz prywatny serwera pozostaje wyłącznie w pliku lokalnym. Umieść konfigurację na przykład w /etc/wireguard/wg0.conf i ogranicz dostęp do odczytu do kontekstu administracyjnego, ponieważ zawiera on klucz tajny. Klucze publiczne są natomiast przeznaczone dla danego odbiorcy.

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

Wskazuje na laptopie Endpoint na publiczny adres serwera i wybrany port UDP. W przypadku czystej konserwacji serwera jako stronę kliencką należy ustawić Dopuszczalne adresy IP zazwyczaj tylko 10.77.0.1/32 konieczne. Dzięki temu do tunelu kierowany jest wyłącznie ruch do adresu VPN serwera; połączenia internetowe z laptopa zachowują swoją zwykłą trasę.

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

Informacja 0.0.0.0/0 Natomiast na kliencie domyślna trasa IPv4 przez tunel oznacza: jeden Tunel pełny. wg-quick wyznacza trasy na podstawie listy AllowedIPs i przetwarza trasy domyślne z wykorzystaniem dodatkowej logiki routingu opartego na zasadach. Jest to możliwe w przypadku celowo tak zaplanowanego dostępu, jednak powoduje to między innymi zmiany w ruchu zewnętrznym i może ujawnić problemy z DNS lub dostępnością.

Ten przykład dotyczy wyłącznie protokołu IPv4. Jeśli serwer posiada publiczną łączność IPv6, port TCP 22 musi zostać tam również wyraźnie zablokowany przez zaporę IPv6 lub usługa SSH musi zostać odpowiednio powiązana. Zamknięte udostępnienie IPv4 nie chroni przed nadal publicznie dostępnym odbiornikiem IPv6. Należy oddzielnie planować adresy tuneli IPv6 oraz prefiksy po stronie klienta; ::/0 byłaby to również trasa domyślna dla IPv6, a nie neutralne uzupełnienie konfiguracji IPv4.

Najpierw aktywuj tunel, sprawdź połączenie z adresem VPN, a następnie zaloguj się do niego za pomocą SSH w drugiej sesji. Dopiero gdy ta metoda będzie działać niezawodnie i dostępny będzie niezależny dostęp do konsoli lub dostęp awaryjny, należy usunąć publiczne udostępnienie SSH. Sprawdź przy tym zarówno adres IPv4, jak i, w razie potrzeby, IPv6. Klucze prywatne nie powinny znajdować się ani w zgłoszeniach, ani w protokołach czatu, ani w systemie kontroli wersji.

Porównanie modeli routingu i reguł zapory sieciowej

Zapora sieciowa egzekwuje żądany model dostępu. Na interfejsie publicznym może ona akceptować określony port UDP protokołu WireGuard; port TCP 22 nie powinien natomiast pozostawać tam otwarty jako ogólny dostęp administracyjny. Zamiast tego protokół SSH jest zezwalany wyłącznie dla pakietów, których interfejsem wejściowym jest wg0 lub też używany interfejs WireGuard. Dodatkowa weryfikacja sieci źródłowej może jeszcze bardziej zawęzić dopuszczalny zakres VPN, jednak reguła oparta wyłącznie na adresie źródłowym nie jest wystarczająca.

Powiązanie z interfejsem wejściowym zapobiega sytuacji, w której pakiet przychodzący na interfejs publiczny spełniałby warunki zezwolenia SSH wyłącznie z powodu sfałszowanego adresu źródłowego pochodzącego z obszaru VPN. Kryptograficzne przyporządkowanie adresów peer i wewnętrznych przez WireGuard ma zastosowanie do uwierzytelnionych pakietów na interfejsie tunelu. Konkretna składnia zapisu w zaporze sieciowej musi być dostosowana do używanego oprogramowania i jednoznacznie uwzględniać zarówno interfejs, jak i rodzinę adresów.

Należy wyraźnie uwzględnić publiczną łączność IPv6. Jeśli usunie się jedynie zezwolenie IPv4 dla portu TCP 22, usługa SSH może nadal być dostępna z Internetu przez IPv6. Należy zatem zablokować ten port również w regułach IPv6 lub skonfigurować usługę SSH tak, aby nie nasłuchiwała na publicznym adresie IPv6. Reguły IPv4 i IPv6 należy sprawdzać oddzielnie.

W przypadku zapory sieciowej opartej na stanie nie wystarczy rozważać wyłącznie pożądanego ruchu w jedną stronę. Pakiety odpowiedzi z dozwolonego połączenia muszą również dotrzeć do klienta; w przypadku dostępu za bramą dochodzi dodatkowo ruch zwrotny z sieci docelowej. Ogólne zezwolenie na dostęp całej podsieci VPN do wszystkich usług sprawia, że sieć serwisowa staje się niepotrzebnie rozległą wewnętrzną siecią dostępową.

W przypadku konserwacji pojedynczego serwera pierwszy model jest najbardziej przejrzysty. Trasa klienta do 10.77.0.1/32 Wystarczy to, a zapora sieciowa może zezwolić na SSH wyłącznie dla pakietów przychodzących przez interfejs WireGuard. Port UDP pozostaje wprawdzie widoczny z zewnątrz, ale bez odpowiedniego klucza partnera nie umożliwia to uzyskania dostępu administracyjnego.

Drugi model wymaga wyraźnego rozdzielenia: serwer VPN pełni wówczas nie tylko rolę punktu końcowego, ale także routera. Zapora sieciowa powinna zezwalać na przykład na połączenia SSH z określonymi serwerami administracyjnymi oraz HTTPS z wewnętrzną konsolą, w każdym przypadku ograniczone do interfejsu wejściowego WireGuard, konkretnych sieci docelowych i portów. Nie należy udostępniać portów baz danych w całej sieci VPN tylko dlatego, że użytkownicy są już połączeni.

W przypadku trybu Full Tunnel serwer VPN pełni również funkcję bramy dla adresów internetowych. W tym celu musi on przesyłać pakiety IPv4 między wg0 i przekierować je przez łącze uplink; ponadto odpowiedzi wymagają drogi powrotnej do sieci VPN. W wielu konfiguracjach serwerów stosuje się w tym celu specjalną regułę Source-NAT na łączu uplink, jeśli sieć upstream nie zna trasy do prefiksu VPN. Należy świadomie planować te reguły i ograniczać je do przewidzianej sieci tunelowej.

Tryb Full Tunnel nie jest wymogiem bezpieczeństwa określonym przez WireGuard, lecz decyzją dotyczącą routingu podejmowaną po stronie klienta. Ponieważ wg-quick Ponieważ trasy domyślne z listy AllowedIPs są przetwarzane w sposób szczególny, to ustawienie powinno być stosowane wyłącznie w przypadku zaplanowanego rozpoznawania nazw, wystarczającej przepustowości bramy oraz odpowiednich reguł wychodzących. W przypadku typowego Administracja siecią VPN jest ona zazwyczaj szerzej sformułowana niż to konieczne. W przypadku IPv6 ta sama kwestia planowania rozpatrywana jest oddzielnie: ::/0 przekierowuje cały ruch IPv6 przez tunel.

Zapewnienie ukierunkowanego dostępu do sieci wewnętrznych

Jeśli administratorzy mają uzyskać dostęp do kolejnych systemów prywatnych znajdujących się za bramą VPN, zadanie to zmienia się z czystego dostępu do serwerów w zarządzanie siecią administracyjną z routingiem. Najpierw należy zaplanować sieci docelowe i usługi: na przykład SSH do serwerów w segmencie administracyjnym oraz HTTPS do konsoli wewnętrznej. Każda dodatkowa ścieżka rozszerza obszar zaufania i dlatego powinna być uzasadniona konkretnym zadaniem operacyjnym.

Pierwszym warunkiem technicznym jest to, aby brama mogła przekazywać pakiety IPv4. Ustawienie jądra net.ipv4.ip_forward włącza to zachowanie. Nie należy traktować tego jako nieistotnego, pojedynczego wiersza kodu: zgodnie z dokumentacją jądra zmiana ip_forward Pozostałe parametry konfiguracyjne IPv4 zostaną przywrócone do domyślnych wartości dla danego hosta lub routera. Dlatego przed wprowadzeniem zmian i po ich wprowadzeniu należy sprawdzić obowiązujące wytyczne dotyczące sieci i bezpieczeństwa.

Po drugie, zapora sieciowa wymaga wyraźnych Zasady tranzytu w obu kierunkach. Zasada nie powinna po prostu ograniczać całego ruchu z wg0 akceptować w sieci LAN. Zamiast tego należy ograniczyć je do sieci źródłowej VPN, przewidzianych adresów docelowych i niezbędnych protokołów, na przykład TCP 22 do serwerów administracyjnych oraz TCP 443 do konsoli. Bazy danych pozostają poza tym zezwoleniem, o ile nie ma uzasadnionego wyjątku.

Po trzecie, sieć docelowa wymaga ścieżki powrotnej do sieci VPN, na przykład trasy dla 10.77.0.0/24 poprzez wewnętrzny adres bramy. Bez tej trasy powrotnej połączenie w jedną stronę może działać, ale odpowiedzi nie dotrą z powrotem do administratora. Jeśli routing w sieci docelowej nie jest możliwy, techniczną alternatywą może być Source NAT na bramie; ukrywa on jednak pierwotny adres klienta VPN, utrudniając tym samym rejestrowanie po stronie docelowej oraz stosowanie bardziej szczegółowych reguł.

Wybierz sieć adresów VPN tak, aby nie kolidowała ani z lokalnymi sieciami administratorów, ani z istniejącymi sieciami lokalnymi, chmurowymi lub kontenerowymi. Nakładanie się sieci powoduje niejednoznaczność wyboru trasy i generuje błędy, które mogą wyglądać jak problem z WireGuardem lub zaporą sieciową. Przed odblokowaniem kolejnych peerów lub sieci docelowych należy również udokumentować stałe adresy tuneli oraz powiązane z nimi urządzenia.

Bezpieczne zarządzanie eksploatacją i wprowadzaniem zmian

Sieć serwisowa pozostaje przejrzysta tylko wtedy, gdy każde urządzenie otrzymuje własny węzeł równorzędny, własną parę kluczy oraz stały adres IP tunelu. Ewidencja powinna zatem zawierać co najmniej adres tunelu, nazwę urządzenia, osobę odpowiedzialną, przeznaczenie oraz datę wydania i kontroli. Przypisanie adresu 10.77.0.10/32 do konkretnego laptopa administracyjnego umożliwia śledzenie dostępów i zapobiega sytuacji, w której wiele urządzeń korzysta z tej samej tożsamości VPN.

Wymianę kluczy należy planować jako standardowy proces operacyjny, a nie dopiero w reakcji na incydent. W przypadku wymiany urządzenia należy utworzyć nowy węzeł (peer) z nowym adresem lub jasno udokumentowanym adresem następczym, sprawdzić dostęp, a następnie usunąć stary węzeł. Prywatne klucze WireGuard powinny znajdować się wyłącznie na danym urządzeniu końcowym; nie powinny być one zawarte ani w biletach, ani w centralnych wykazach inwentarzowych.

W przypadku utraty laptopa lub odejścia osoby z zewnątrz należy usunąć odpowiedni węzeł z konfiguracji serwera. Uniemożliwi to tej osobie dostęp do sieci administracyjnej bez konieczności wymiany kluczy innych administratorów. Odstawienie leku przez rówieśnika nie jest to jednak to samo, co unieważnienie klucza SSH: klucz WireGuard reguluje trasę sieciową, a klucz SSH – logowanie do konta docelowego.

Po usunięciu węzła WireGuard nie może już wymieniać przez ten węzeł żadnych pakietów w ramach istniejącego połączenia SSH; w związku z tym połączenie zawiesza się lub zostaje zakończone po przerwaniu lub upływie limitu czasu. Usunięcie węzła nie powoduje jednak automatycznego cofnięcia logowania SSH, które już miało miejsce na poziomie aplikacji, ani nie kończy wcześniej uruchomionych procesów. W związku z tym w przypadku takiego zdarzenia należy dodatkowo sprawdzić autoryzacje SSH, uruchomione procesy, konta oraz, w razie potrzeby, uprawnienia sudo.

Aby wprowadzić konkretne zmiany, można wg syncconf porównać istniejącą konfigurację WireGuard z wyraźnie wskazanymi różnicami; zgodnie z instrukcją powinno to w mniejszym stopniu zakłócać sesje między węzłami niż setconf. Nie zastępuje to jednak zatwierdzenia, kontroli dwuosobowej ani okna serwisowego. Przed każdą zmianą zapisz działającą konfigurację i odnotuj, w jaki sposób ją przywrócić.

Diagnoza od uzgodnienia połączenia po dostęp przez SSH

W przypadku awarii należy konsekwentnie oddzielić transport, routing i aplikację. Zanim zmienisz ustawienia SSH, zacznij od publicznie dostępnego portu UDP i procedury uzgadniania połączenia. Polecenie wg show wyświetla między innymi adresy IP z listy dozwolonych (AllowedIPs), czas ostatniego uzgodnienia połączenia oraz licznik transferów dla skonfigurowanych peerów. Brakujące lub niezmienione wartości wskazują na problem występujący przed faktycznym uzyskaniem dostępu przez SSH.

Jeśli nawiązano połączenie, sprawdzasz zarówno na kliencie, jak i na serwerze faktycznie ustawiony adres tunelu oraz trasę do celu. W przypadku czystego zarządzania bramą klient musi uzyskać dostęp do adresu docelowego 10.77.0.1 za pośrednictwem interfejsu WireGuard. W przypadku adresów docelowych wewnątrz sieci należy dodatkowo uwzględnić liczniki zapory sieciowej, dozwolony ruch zwrotny oraz trasę powrotną sieci docelowej; pomyślne nawiązanie połączenia nie potwierdza spełnienia tych warunków.

Dopiero po upewnieniu się, że ścieżka sieciowa jest prawidłowa, należy sprawdzić działanie usługi SSH. Sprawdź wpisy w pliku sshd_config, w szczególności udostępnienia dla użytkowników, takie jak AllowUsers, a następnie sprawdź stan usług oraz logi za pomocą narzędzi dostępnych w Twojej dystrybucji. Następnie sprawdź konto użytkownika oraz wpisy w authorized_keys oraz reguły sudo. Sama dokumentacja konfiguracyjna nie potwierdza ani pomyślnego zalogowania, ani dostępności usługi.

Identyczne lub pokrywające się adresy AllowedIPs nie są zwykłym błędem w dokumentacji. Podczas wysyłania WireGuard przypisuje adresy docelowe do danego węzła na podstawie tych prefiksów; podczas odbioru ograniczają one wewnętrzne adresy źródłowe uwierzytelnionego węzła. Zduplikowane lub sprzeczne prefiksy hostów nie tworzą zatem jednoznacznego, niezawodnego i możliwego do prześledzenia Przypisanie partnerów. Nie należy zakładać, jaki konkretny wynik wygeneruje narzędzie administracyjne podczas przejmowania takiej konfiguracji. Zamiast tego należy zapobiegać kolizjom już na etapie inwentaryzacji i sprawdzania konfiguracji.

Wprowadzaj poprawki w sposób kontrolowany i przeprowadzaj diagnostykę wyłącznie przy dostępnym dostępie awaryjnym. Dzięki temu błędna zmiana dotycząca połączeń równorzędnych, routingu lub zapory sieciowej nie zablokuje jednocześnie drogi powrotnej niezbędnej do naprawy. Po każdym przejęciu ponownie sprawdź uzgodnienie, licznik transferu, trasę oraz dostęp do konkretnej, udostępnionej usługi administracyjnej.

wg show
ip route

Decydujące znaczenie mają dobór narzędzi i granice bezpieczeństwa

Wybór sposobu zarządzania zależy od istniejącej struktury zarządzania serwerami, a nie od rzekomo uniwersalnej metody stosowanej w WireGuard. wg-quick nadaje się do prostych konfiguracji: skrypt pomocniczy konfiguruje interfejs, adresy oraz trasy wywodzące się z listy AllowedIPs. W przypadku złożonych sieci dokumentacja odsyła natomiast do bardziej specjalistycznych narzędzi lub do bezpośredniej konfiguracji za pomocą wg oraz narzędziami IP.

Jeśli host zarządza już swoją siecią w sposób deklaratywny za pomocą systemd-networkd, pliki .netdev i .network stanowią odpowiednią alternatywę. systemd-networkd obsługuje ustawienia specyficzne dla WireGuard i może pobierać klucze prywatne z danych uwierzytelniających; w przypadku treści poufnych dokumentacja zaleca jako środek ochronny stosowanie zaszyfrowanych danych uwierzytelniających lub co najmniej restrykcyjnych uprawnień do plików. Rozwiązanie to sprawdza się szczególnie w przypadku serwerów wdrażanych automatycznie.

Bezpośrednie wywołania z wg oraz ip zapewniają największą kontrolę nad automatyzacją, routingiem opartym na zasadach i specjalnymi procedurami zapory sieciowej, ale wymagają jasno zdefiniowanego modelu operacyjnego. Nigdy nie zarządzaj tym samym interfejsem jednocześnie za pomocą wg-quick, systemd-networkd i własnych skryptów. Wiele podmiotów zarządzających może wzajemnie nadpisywać trasy, adresy lub ustawienia peerów, co utrudnia niezawodne przywrócenie poprzedniego stanu.

Funkcja PersistentKeepalive ma sens tylko w przypadku węzłów, które znajdują się za NAT lub zaporą stanową, rzadko same wysyłają dane, a mimo to muszą pozostawać dostępne dla połączeń przychodzących. Jeśli nie podano innych ustawień, funkcja ta jest wyłączona; dokumentacja podaje 25 sekund jedynie jako możliwy interwał, a nie jako ogólną wartość domyślną. Klienci mobilni często korzystają z roamingu, ponieważ WireGuard może aktualizować punkt końcowy na podstawie poprawnie uwierzytelnionych pakietów.

Roaming i sztywne ograniczenia punktów końcowych to kwestia kompromisu: zapora sieciowa, która akceptuje protokół UDP wyłącznie ze znanych sieci źródłowych, może ograniczyć powierzchnię ataku, ale uniemożliwia elastyczne korzystanie z sieci w podróży. WireGuard zwraca również uwagę, że aktywny atakujący może przekierować zewnętrzny adres źródłowy, sprzyjając w ten sposób atakowi typu „odmowa usługi” (DoS), bez konieczności odczytywania lub modyfikowania zaszyfrowanej treści.

Tunel WireGuard nie zastępuje zarządzania tożsamością, kontroli uprawnień, aktualizacji, tworzenia kopii zapasowych ani rejestrowania. Nie maskuje on ruchu jako HTTPS i nie oferuje trybu TCP. Publiczne aplikacje internetowe nadal wymagają zatem oddzielnego zabezpieczenia TLS; wymagania i sposób wdrożenia wyjaśniono w tym artykule Bezpieczna konfiguracja protokołu HTTPS. Należy wyraźnie oddzielić tę warstwę ochronną od dostępu VPN przeznaczonego dla administracji.