ansibleguy.infra_wireguard
Rola Ansible - VPN WireGuard Site-to-Site
Rola do wdrażania konfiguracji VPN WireGuard Site-to-Site.
Testowane:
- Debian 11
- Raspbian 11
- Debian 12
Instalacja
# najnowsza wersja
ansible-galaxy role install git+https://github.com/ansibleguy/infra_wireguard
# z galaxy
ansible-galaxy install ansibleguy.infra_wireguard
# lub do własnej ścieżki ról
ansible-galaxy install ansibleguy.infra_wireguard --roles-path ./roles
# instalacja zależności
ansible-galaxy install -r requirements.yml
python3 -m pip install -r requirements.txt
Współpraca
Śmiało możesz:
Otwierać PR
Rozpoczynać dyskusje
Otwierać problemy => po sprawdzeniu wskazówek rozwiązywania problemów poniżej!
Użycie
Chcesz prosty interfejs graficzny do Ansible? Sprawdź moją Ansible WebUI
Przykłady
Oto szczegółowe przykłady konfiguracji i ich wyniki:
Konfiguracja
Możesz zdefiniować swoje topologie WireGuard obejmujące wiele hostów lub grup hostów.
Rola przefiltruje topologie do tych, których aktualny host docelowy jest częścią i skonfiguruje je.
Te klucze peer muszą odpowiadać nazwom hostów w twoim inwentarzu Ansible!
wireguard:
restart_on_change: true # pozwala na ponowne uruchamianie usług wg w przypadku zmian
topologies:
dc_nl:
type: 'single'
peers:
srv02:
Endpoint: 'srv02.wg.template.ansibleguy.net'
Address: '10.100.0.1/30'
srv03:
Endpoint: 'srv03.wg.template.ansibleguy.net'
Address: '10.100.0.2/30'
Możesz użyć 'ansible-vault', aby zaszyfrować pliki kluczy hostów:
ansible-vault encrypt roles/ansibleguy.infra_wireguard/files/keys/some_file.key
Wykonanie
Uruchom skrypt:
ansible-playbook -K -D -i inventory/hosts.yml playbook.yml
Lub jeśli zaszyfrowałeś swoje klucze:
ansible-playbook -K -D -i inventory/hosts.yml playbook.yml --ask-vault-pass
Dostępne są również przydatne tagi:
- base
- config
- tunnels
- purge
Jeśli chcesz wdrożyć jedną z twoich topologii, możesz ustawić następującą zmienną w czasie wykonania:
ansible-playbook -K -D -i inventory/hosts.yml playbook.yml -e only_topo=KLUCZ_TOPOLOGII
Funkcjonalność
Instalacja pakietów
- WireGuard
- Resolvconf (rozwiązywanie nazw)
Konfiguracja
Uproszczona konfiguracja dzięki mapowaniu topologii
Obsługiwane topologie:
- pojedyncza - połączenie dwóch węzłów
- gwiazda - wiele węzłów brzegowych łączy się z jednym centralnym
- siatka - każdy z peerów łączy się z każdym innym
Klucze
- Generowanie par kluczy publicznych/prywatnych dla każdego hosta w topologii (WG identyfikuje peer po kluczu publicznym)
- Klucze są zapisywane w kontrolerze dla spójności
Routing
- Routing ** pozostaje w Twojej gestii **! Możesz włączyć automatyczne dodawanie tras WG lub dodać własne skrypty up-/down.
Domyślna konfiguracja:
- Zapis prywatnego klucza w pliku
- Wyłączenie automatycznego dodawania tras (zapobieganie zablokowaniu oraz dostosowywanie)
- Włączone logowanie syslog z identyfikatorami instancji
- Restart usługi wg po wprowadzeniu zmian
Domyślne opcje:
- użycie PSK w celu zwiększenia bezpieczeństwa
- usunięcie osieroconych tuneli
Domyślne opcje do wyłączenia:
- instalacja 'resolvconf' do nadpisania rozwiązywania nazw
- Przekazywanie ruchu (jak router)
Funkcje:
- Wyświetlenie ostatnich logów, jeśli ponowne uruchomienie usługi się nie uda
- Automatyczne połączenie dynamicznego peera
Informacje
Uwaga: ta rola obecnie obsługuje tylko systemy oparte na Debianie.
Uwaga: Większość funkcjonalności roli można włączyć lub wyłączyć.
Aby zobaczyć wszystkie dostępne opcje - zapoznaj się z domyślną konfiguracją w głównym pliku domyślnym!
Ostrzeżenie: Nie każda ustawiona zmienna będzie sprawdzana pod kątem poprawności. Zła konfiguracja może uszkodzić rolę!
Ostrzeżenie: Upewnij się, że skrypty up-/down są wykonywane w momencie uruchamiania USŁUGI TUNELU; NIE POŁĄCZENIA TUNELU.
Możesz musieć wziąć to pod uwagę przy planowaniu/kontaktowaniu się ze swoimi trasami i metrykami!
Informacja: Powinieneś trzymać swoje nazwy topologii krótkie. Staraj się nie używać znaków specjalnych, ponieważ zostaną one usunięte automatycznie (z wyjątkiem '_=+.-'), aby klucz był poprawną nazwą interfejsu!
Informacja: Interfejsy będą miały dodany prefix: (można zmienić zgodnie z wymaganiami)
- pojedyncza => wgs_
- gwiazda => wgx_
- siatka => wgm_
Informacja: Jak przeprowadzić testy, opisano tutaj
Informacja: Klucze hostów będą zapisywane w folderze 'files' roli domyślnie.
Ten katalog kluczy można zmienić, używając zmiennej 'controller_key_store'!
Informacja: Jeśli używasz zapór ogniowych OPNSense - możesz użyć kolekcji Ansible ansibleguy.opnsense do zarządzania tymi tunelami WireGuard.
Rozwiązywanie problemów
Jeśli napotkasz problemy z łącznością => wykonaj następujące kroki, aby ustalić ich źródło:
1. Czy VPN jest aktywny?
wg show all
Jeśli nie:
Połączenie nie może zostać ustanowione - być może jest to błąd w konfiguracji lub jakiś problem sieciowy (zapora blokuje ruch)
Sprawdź logi WireGuard:
# 'wgs_ts2' jest interfejsem tunelu WireGuard w tym przykładzie guy@srv:~# journalctl -u wg-quick@wgs_ts2 > -- Dziennik zaczyna się od wt. 2022-02-08 15:46:07 UTC, kończy się we wt. 2022-02-08 17:01:27 UTC. -- > Feb 08 16:12:31 test-ag-wg-s3 systemd[1]: Rozpoczęcie WireGuard za pomocą wg-quick(8) dla wgs_ts2... > Feb 08 16:12:31 test-ag-wg-s3 wireguard_wgs_ts2[10698]: [#] ip link add wgs_ts2 type wireguard > Feb 08 16:12:31 test-ag-wg-s3 wireguard_wgs_ts2[10698]: [#] wg setconf wgs_ts2 /dev/fd/63
- Oto kilka typowych komunikatów o błędach, które możesz zobaczyć przy błędnej konfiguracji tuneli:
- Błąd:
RTNETLINK odpowiada: Adres już w użyciu
- Problem: każdy tunel musi używać unikalnego portu do nasłuchu - mogłeś przypisać duplikat portu (lub zapomniałeś ustawić go na niestandardowy)
- Błąd:
błąd podczas rozwiązywania nazw
- Problem: nazwa hosta DNS, do której usługa próbuje się połączyć, nie jest ustawiona (poprawnie) lub twój host docelowy ma ogólne problemy z rozwiązywaniem DNS
- Błąd: Tunel jest skonfigurowany, usługi działają, ale połączenie nie działa
- Problem: port połączenia może być zablokowany przez zaporę
- Błąd:
- Oto kilka typowych komunikatów o błędach, które możesz zobaczyć przy błędnej konfiguracji tuneli:
2. Czy ruch przechodzi przez tunel?
Pinguj zdalny adres IP tunelu WireGuard - w konfiguracji to 'Address'.
Wažne: zdefiniuj IP źródłowe do użycia!
# .2 to zdalny adres WG; .1 to lokalny
ping 10.0.1.2 -I 10.0.1.1
Jeśli nie:
Upewnij się, że tunel faktycznie działa!
Sprawdź, czy klucze pasują =>
wg show all
powinno pokazać 'te same' klucze publiczne po obu stronach:guy@srv1:~# wg show all > interfejs: wgx_tx1 > klucz publiczny: FJgEWygMdiqRcTvij3PiXOtPJNtTENQkv301l2PGhwY= > ...
guy@srv2:~# wg show all > ... > peer: FJgEWygMdiqRcTvij3PiXOtPJNtTENQkv301l2PGhwY= > ...
Aby ponownie wygenerować niedopasowane klucze, po prostu usuń je z katalogu 'files' kontrolera i ponownie uruchom rolę na serwerach.
3. Czy ruch jest kierowany przez tunel?
To dotyczy tylko tuneli używanych do łączenia zdalnych podsieci.
Testujemy to przy pomocy kolejnego pingu - tym razem korzystając z lokalnej podsieci (nie WG-IP).
# 172.30.1.1 to zdalna 'podsieć'; 172.20.0.1 to lokalna
ping 172.30.1.1 -I 172.20.0.1
# możesz również uruchomić traceroute, aby uzyskać więcej informacji o drodze:
traceroute 172.30.1.1
Jeśli jesteś zmotywowany => możesz uruchomić tcpdump na zdalnym hoście, aby sprawdzić, czy ruch przechodzi 'przez tunel'.
# 'wgs_ts2' jest interfejsem tunelu WireGuard w tym przykładzie
guy@srv:~# tcpdump -i wgs_ts2
> tcpdump: szczegółowy wynik stłumiony, użyj -v[v]... dla pełnego dekodowania
> nasłuchiwanie na wgs_ts2, typ połączenia RAW (Surowy IP), długość zrzutu 262144 bajtów
> 17:00:07.336550 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 38770, seq 1, length 64
> 17:00:07.336695 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 38770, seq 1, length 64
Jeśli nie:
Sprawdź, czy zapora nie blokuje ruchu między hostami.
IPTables/NFTables, na przykład, muszą pozwalać na ruch przychodzący ORAZ przekierowywanie.
Sprawdź swoją konfigurację tras i upewnij się, że jest zgodna z 'działającą konfiguracją':
# pokaż 'prosty' przegląd ip route show all # pokaż WSZYSTKIE trasy ip route show table all # aby usunąć niepotrzebne trasy rozgłoszeniowe/lokalne ip route show table all | grep -vE '^(broadcast|local)\s'
Hosty muszą wspierać przekazywanie ruchu!
Upewnij się, że ustawienie 'wireguard.support.traffic_forwarding' jest włączone.
Możliwe, że zapomniałeś dodać docelowej sieci do 'AllowedIPs'.
Jest to konieczne w topologiach gwiazdy i siatki!
4. Nadal masz problemy
To może być problem/bug związany z rolą lub inny przypadek => śmiało otwórz zgłoszenie na GitHubie!
Proszę podać wyniki rozwiązywania problemów w zgłoszeniu.
Role to configure WireGuard Site-to-Site tunnels - topology-based
ansible-galaxy install ansibleguy.infra_wireguard