Wg-easy – serwer WireGuard w kilku kliknięciach

avlab.pl 15 godzin temu
Zdjęcie: wg-easy – serwer WireGuard w kilku kliknięciach


Usługi VPN są absolutną podstawą w kontekście zapewniania bezpiecznego dostępu zdalnego do hostów działających w zewnętrznej sieci lokalnej. Dzięki zastosowaniu VPN nie ma potrzeby udostępniania „wrażliwych” usług (takich jak SSH, RDP, bazy danych) w sieci publicznej, aby przykładowo zewnętrzny administrator mógł wykonać swoją pracę. Wystarczy otwarty port danego VPN, a cała komunikacja będzie szyfrowana. Zaawansowane usługi VPN mogą dodatkowo weryfikować zabezpieczenia po stronie systemu zdalnego użytkownika, natomiast są to już rozwiązania dostępne w ramach droższych urządzeń sieciowych klasy enterprise.

Zalety VPN mogą być widoczne także w mniejszych sieciach domowych. Coraz popularniejsze są tzw. inteligentne domy czy wszelkie urządzenia IoT, którymi można zarządzać poprzez panele we wbudowanych aplikacjach. jeżeli przebywamy w domu, to oczywiście dostęp jest „bezpośredni”, ale przykładowo wyjazd na wakacje będzie się wiązał z wiadomym utrudnieniem w tym zakresie. Aby uniknąć bardzo ryzykownego wystawiania portów tych urządzeń w sieci publicznej, również sprawdzi się VPN. Wymagany jest publiczny adres IP i możliwość dostosowania konfiguracji własnego routera.

Trzeba też wspomnieć o pewnej „różnicy” w działaniu VPN. Istnieje opcja tunelowania całego ruchu sieciowego (co oznacza, iż dla docelowego serwera będziemy widoczni pod adresem IP dostawcy konkretnego VPN) bądź też do określonych sieci/hostów dostępnych w ramach danej sieci wewnętrznej. Z tej pierwszej korzystają wszyscy dostawcy publicznych usług VPN, z których można wymienić NordVPN, ExpressVPN czy ProtonVPN.

W przypadku, gdy VPN jest użyty w celu zdalnego dostępu do hostów w innej sieci, to takie podejście nie jest szczególnie rozsądne – można sobie wyobrazić, iż użytkownik odwiedza pewne specyficzne serwisy internetowe „przedstawiając się” adresem IP z naszej sieci firmowej/ASN. Z tego powodu usługi VPN mają dodane wybrane trasy do adresów, do których to użytkownik może uzyskiwać dostęp. Dla komercyjnych VPN zawsze jest to konfiguracja na poziomie administratora sieci i użytkownik samodzielnie nie będzie miał możliwości jej zmiany – klient VPN doda „w tle” trasy pobrane z serwera VPN do systemu użytkownika. Warto od razu wspomnieć o serwerach DNS, które też mogą zostać zastąpione adresami z sieci VPN (aby umożliwić dostęp poprzez lokalne nazwy domenowe) i wtedy administrator usługi DNS może mieć wgląd w domeny, z którymi użytkownik nawiązywał połączenie.

Serwery VPN - WireGuard

Dla typowych zastosowań dostępne są dwa rozwiązania – OpenVPN i WireGuard. w tej chwili są uznawane za sprawdzone i powszechnie stosowane. WireGuard jest znacznie nowszym protokołem i można powiedzieć, iż gwałtownie zdobył popularność, a choćby trwa pewien „hype” na to rozwiązanie. Wykorzystuje wyłącznie UDP (dla porównania OpenVPN może działać zarówno po UDP, jak i TCP), co ma wpływ na wydajność działania. Znaczenie ma również łatwość konfiguracji serwera – poniżej opisano uruchomienie serwera WireGuard z użyciem gotowego obrazu wg-easy, natomiast wystarczy porównać ilość linii w plikach konfiguracyjnych klienta OpenVPN i WireGuard. Po więcej informacji o rozwoju i historii WireGuard odsyłam do artykułu w Wikipedii.

Serwery OpenVPN i WireGuard można uruchomić na wybranych routerach, jeżeli te usługi są wbudowane (choć często to własne implementacje). Wtedy praktycznie całą konfigurację wykonuje się w panelu. Przykładem jest RouterOS od MikroTik, który obsługuje oba protokoły. Alternatywna opcja to uruchomienie własnego serwera i przekierowanie portu – tutaj trzeba pamiętać, iż nie w każdej sieci (będąc na lotnisku itd.) domyślne porty VPN będą odblokowane, stąd być może warto skorzystać z portu 443.

wg-easy

wg-easy jest rozwiązaniem pozwalającym na sprawne uruchomienie serwera WireGuard zarządzanego w pełnym stopniu poprzez panel w przeglądarce. Użytkownik nie instaluje serwera czy aplikacji do zarządzania – wszystko zostało zawarte w jednym obrazie Docker. Po stronie użytkownika pozostaje jednak konfiguracja serwera reverse proxy z obsługą HTTPS do panelu wg-easy (możliwe jest działanie bez SSL, ale nie jest zalecane) oraz przekierowanie portu na urządzeniu brzegowym – routerze.

Jako reverse proxy można zastosować dowolny serwer, z czego te najbardziej popularne to nginx i HAProxy. W naszym przypadku będzie to HAProxy. W systemie wystarczy zainstalować Docker, bo zarówno wg-easy jak i HAProxy będą skonteneryzowane. Nie ma konkretnych zaleceń co do systemu operacyjnego, natomiast konfiguracja reguł firewalla jest różna dla RHEL – trzeba zmienić domyślne reguły dostosowane do iptables. Istotny pozostaje fakt, iż nie są wymagane żadne modyfikacje po stronie systemu (sysctl itp.). Pełna konfiguracja pozostaje wyłącznie w kontenerze.

Konfiguracja kontenerów

Po zainstalowaniu Docker można przystąpić do dalszych prac. Dla zachowania porządku konfiguracji najlepiej utworzyć dedykowany katalog przeznaczony dla pliku docker-compose.yml i mount bind kontenera wg-easy. Pobieramy plik poleceniem

sudo curl -o docker-compose.yml https://raw.githubusercontent.com/wg-easy/wg-easy/master/docker-compose.yml

Musimy dostosować niektóre ustawienia. Zamiast Docker volume użyjemy mount bind do lokalnego katalogu z konfiguracjami WireGuard. Usuwamy więc fragment

volumes: etc_wireguard:

a oprócz tego wykonujemy zmianę w sekcji volumes.

volumes: - ./etc_wireguard:/etc/wireguard - /lib/modules:/lib/modules:ro

Dalej dodajemy zmienną PORT, która spowoduje wystawienie panelu na wskazanym porcie wewnątrz kontenera.

wg-easy: environment: - PORT=80

Pozostaje dodanie network, aby drugi kontener z HAProxy miał dostęp do portu w kontenerze wg-easy. W sekcji networks w defincji kontenera dodajemy wyłącznie nazwę sieci, a na samym końcu pliku docker-compose.yml umieszczamy ustawienia (external oznacza, iż sieć będzie musiała zostać wcześniej manualnie dodana).

networks: wg: ipv4_address: 10.42.42.42 ipv6_address: fdcc:ad94:bacf:61a3::2a haproxy:
haproxy: external: true

Tworzymy kolejny katalog do przechowywania definicji usługi haproxy. Aby kontenery uruchomiły się poprawnie, należy od razu dodać sieć.

sudo docker network create haproxy

Zapisujemy kolejny plik docker-compose.yml o następującej zawartości.

services: haproxy: image: haproxy container_name: haproxy restart: unless-stopped ports: - 80:80 - 443:443 networks: - haproxy volumes: - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg - ./ssl:/ssl networks: haproxy: external: true

W pliku haproxy.cfg można zastosować domyślną konfigurację HAProxy pamiętając o dodaniu ścieżki do pliku PEM (certyfikat+klucz) z katalogu /ssl. Można użyć własnej lokalnej domeny bądź zwyczajnie wykorzystać adres IP serwera. Konfiguracja backend będzie w tym wypadku całkowicie standardowa.

backend wireguard http-request redirect scheme https unless { ssl_fc } http-request set-header Host 172.20.0.5 server wg wg-easy:80 check

Uruchamiamy oba kontenery zaczynając od wg-easy (HAProxy musi „widzieć” serwer backend, aby usługa wystartowała).

sudo docker compose up -d

Zarządzanie wg-easy

Teraz można otworzyć w przeglądarce panel logowania podając ustawioną domenę/adres IP hosta z WireGuard. Powinien wyświetlić się poniższy ekran.

Panel wg-easy przed rozpoczęciem konfiguracji

Wybieramy Kontynuuj i w kolejnym kroku ustawiamy nazwę i hasło użytkownika do zarządzania serwerem. Dalej przy pytaniu o istniejącą konfigurację wybieramy Nie, po czym wskazujemy publiczny adres IP i port (można pozostawić domyślny 51820), na którym nasłuchiwać będzie WireGuard.

Na zakończenie tej prostej konfiguracji logujemy się do panelu podając ustawione poświadczenia.

Formularz logowania do panelu

Po udanym logowaniu zobaczymy wręcz okrojony widok z kilkoma przyciskami do wyboru, z czego większość odpowiada za dostosowanie wyglądu i języka interfejsu. Prostota jest niewątpliwą zaletą wg-easy. Musimy jednak zmienić kilka opcji w konfiguracji dostępnej po wybraniu nazwy Administrator i Panel administracyjny.

W przypadku systemów RHEL zmiany wszystkich podanych niżej parametrów będą wiązały się z pojawieniem błędu – zostaną jednak wprowadzone. Spowodowane jest to niedostosowaniem konfiguracji zapory do systemów RHEL. Najpierw jednak zajmiemy się zmianami w zakresie samego serwera. Przechodzimy do zakładki Konfiguracja.

Jeśli zależy nam na rozwiązywaniu nazw obsługiwanych przez lokalny serwer, to w sekcji DNS podajemy jego adres. Tutaj akurat konfigurujemy serwer mający zapewniać dostęp do wewnętrznych zasobów spoza sieci, więc zostały usunięte domyślne wpisy wskazujące na Cloudflare, a zamiast tego podano adres lokalny.

Dodanie serwera DNS do globalnej konfiguracji WireGuard

Inna istotna opcja to w polskim tłumaczeniu Dozwolone adresy IP. Nazwa może być myląca, bo w kontekście WireGuard oznacza adresy, do których ruch ma być kierowany poprzez VPN. Pozostawienie opcji 0.0.0.0/0 i ::/0 spowoduje, iż cała komunikacja będzie obsługiwana przez VPN. Jako iż zależy nam przede wszystkim na dostępie do sieci lokalnej, to najprościej będzie podać jej adres.

Określenie adresów do obsługi przez VPN

Klikamy Zapisz. najważniejsze pozostaje sprawdzenie interfejsu, przez który kontener kieruje ruch. Można zweryfikować to poleceniem

sudo docker exec wg-easy ip r get

W zakładce Interfejs podane jest urządzenie eth0, które niekoniecznie może być poprawne. Należy zmienić na interfejs widoczny w wyniku polecenia.

Sprawdzenie nazwy interfejsu wychodzącego
Podanie nazwy interfejsu w wg-easy

Rozwiązanie problemu występującego na systemach RHEL sprowadza się do zastąpienia istniejących wpisów PostUp i PostDown z zakładki Hooki zawartością przedstawioną na stronie https://wg-easy.github.io/wg-easy/latest/examples/tutorials/podman-nft/#edit-hooks.

Edycja hooków w wg-easy

Pozostaje zrestartować kontener.

sudo docker compose down sudo docker compose up -d
Stop/start kontenera

Port forwarding

Przed dodaniem klienta (konfiguracji do połączenia) należy wystawić serwer WireGuard „na zewnątrz”. Sposób jest całkowicie zależny od dostawcy systemu konkretnego routera. Trzeba pamiętać, iż adres IP musi być publicznie osiągalny. W celu prezentacji użyłem adresu z sieci LAN (192.168.1.0/24), kierującego ruch do sieci wewnętrznej hypervisora (172.20.0.0/24). WireGuard, jak zostało wspomniane, używa protokołu UDP.

Dodawanie reguły port forwarding w routerze MikroTik

Dodawanie klienta VPN

Po zakończeniu tej konfiguracji wystarczy już tylko dodać pierwszego klienta poprzez wybór przycisku Nowy w głównym widoku panelu. Wymagane jest wyłącznie podanie jego nazwy.

Dodawanie nowego klienta w wg-easy

Po tej czynności dodany klient będzie widoczny wraz z przypisanym stałym adresem IPv4 i IPv4 oraz kilkoma opcjami. Można przeprowadzić edycję ustawień specyficznych dla danego klienta (przykładowo ustawić inny zakres dozwolonych adresów), pobrać plik konfiguracyjny, utworzyć tymczasowy adres do pobierania pliku czy wygenerować kod QR do użycia przez mobilnego klienta WireGuard.

Niestety w przypadku WireGuard użytkownik może dowolnie modyfikować swoją konfigurację – zmienić przypisany adres IP czy zakres sieci. jeżeli docelowo powinien mieć ograniczony dostęp, to pozostaje zastosowanie wybranego rodzaju blokady na poziomie naszej sieci.

Widok kont

Pobraną konfigurację należy udostępnić uprawnionej osobie i przechowywać w bezpieczny sposób.

Instalacja klienta i połączenie z VPN

Instalacja klienta WireGuard również nie powinna sprawić trudności. Instalatory i opisane metody instalacji dla wszystkich systemu operacyjnego znajdują się na stronie https://www.wireguard.com/install/. Dla Windows wystarczy jedynie pobrać i uruchomić instalator, który działa „bezobsługowo”. Po zakończonym procesie powinniśmy zobaczyć niżej widoczne okno aplikacji.

Okno klienta WireGuard

Wybieramy widoczną opcję Importuj tunel (tunele) z pliku i wskazujemy zapisany plik konfiguracyjny. W celu zestawienia połączenia wystarczy już tylko kliknąć Aktywuj. Niestety status Aktywny nie oznacza, iż tunel VPN „działa” (może choćby nie być komunikacji z serwerem i nie zostaniemy o tym poinformowani) – to pozostaje do weryfikacji po stronie użytkownika. Należy przetestować połączenia do hostów w zdalnej sieci.

Połączony klient VPN

Natomiast osoba zarządzająca serwerem może w każdej chwili sprawdzić połączonych klientów. Po wejściu w edycję poszczególnych klientów widoczny będzie ich wychodzący adres IP.

Klient połączony do serwera WireGuard
Adres IP i port połączonego klienta

Jak widać na zrzucie ekranu, klient z sieci 192.168.1.0/24 uzyskuje dostęp SSH do serwera działającego w sieci VPN.

Połączenie SSH do hosta w sieci VPN

Podsumowanie

Znajomość metod konfiguracji serwerów VPN może okazać się niezwykle przydatna, a powiązana tematyka jest po prostu interesująca. wg-easy jest narzędziem łatwym w obsłudze i umożliwia wytworzenie działającego serwera WireGuard w krótkim czasie. Zdecydowanie warto spróbować przeprowadzić analogiczną konfigurację – skonfigurować router, zainstalować system operacyjny i Docker, uruchomić wg-easy i wykonać połączenie z innej sieci. Można także skupić się na alternatywnym rozwiązaniu, jakim jest OpenVPN.

Idź do oryginalnego materiału