mDNS przez WireGuard: trzy bramy, zanim peer odpowie

Ustawienie flagi multicast na urządzeniu WireGuard czyni interfejs odpowiednim dla oprogramowania odkrywającego, i na tym działanie flagi się kończy. Nie mówi protokołowi, dokąd ma trafić pakiet grupowy, a na urządzeniu z kilkoma peerami nie ma jednej oczywistej odpowiedzi. Między działającym demonem a odkrytą usługą stoją trzy osobne bramy.

Testuj je po kolei, bo przejście jednej nic nie mówi o następnej.

Pierwsza brama: flaga i polityka demona

Urządzenie WireGuard w Linuksie powstaje jako łącze punkt-punkt bez ARP i domyślnie nie nosi flagi multicast. Dodanie flagi to lokalna zmiana interfejsu, wykonywana przez cokolwiek zarządza urządzeniem. Avahi ma nad tym własny obraz świata, a jego domyślna polityka całkowicie pomija interfejsy punkt-punkt. Przed ruszeniem choćby jednego pakietu obowiązują więc dwa niezależne testy odpowiedniości.

Demon potrzebuje więc wyraźnej decyzji, a nie tylko działającego procesu. Jego udokumentowane elementy sterujące obejmują allow-interfaces, deny-interfaces i allow-point-to-point, a ostatni jest ustawieniem, które ludzie pomijają.

Poniższe kontrole raportują flagi łącza, trasę multicast oraz to, czy konfiguracja demona jest w ogóle analizowana:

ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check

Demon, który uruchomił się pomyślnie, niekoniecznie otworzył gniazda na interfejsie, który cię interesuje. Czytaj jego efektywną konfigurację, zamiast zakładać, że status usługi równa się pokryciu.

Druga brama: trasa do grupy

Druga brama to zwykłe trasowanie. Pakiet zaadresowany do 224.0.0.251 podąża za tabelą przekazywania jak wszystko inne, a jeśli tabela wysyła go przez fizyczny interfejs LAN, żadna konfiguracja WireGuard tego nie zmieni. Najpierw napraw trasę, a reszta śledztwa się skróci. Sprawdź, co jądro raportuje dla adresu grupy, zanim dotkniesz jakichkolwiek kluczy peera.

Bez konkretnej trasy jądro wraca do własnej obsługi multicast łącza, dlatego domyślne zachowanie wygląda poprawnie w płaskim LAN-ie i błędnie, gdy tylko ten sam ruch grupowy ma wyjść przez tunel. Awaria jest cicha po stronie nadawcy: zapytanie gdzieś idzie, a odpowiedź nigdy nie nadchodzi.

Trzecia brama: WireGuard wybiera jednego peera na pakiet

WireGuard wybiera peera wychodzącego, wyszukując cel w zbiorach dozwolonych adresów, a ścieżka wysyłania Linuksa wykonuje to wyszukiwanie raz na pakiet. Wynik jest jeden, a pakiet jest szyfrowany dla tego peera. Ten sam prefiks grupy w dozwolonych listach kilku peerów nie tworzy członkostwa ani replikacji; tworzy niejednoznaczne wyszukiwanie, które rozstrzyga się na jednym z nich.

Na dedykowanym łączu dwukońcowym to jest dokładnie to, czego chcesz, bo istnieje jeden zamierzony odbiorca celowo przenoszonego ruchu grupowego. Na interfejsie z pięcioma peerami to ograniczenie, nie cecha, a poprawka należy do projektu, a nie do konfiguracji któregokolwiek peera.

Projekt z rozgałęzianiem wymaga jawnego przekaźnika, osobnych łącz lub zupełnie innego mechanizmu odkrywania. Publikowanie przepisu dwukońcowego jako rozwiązania dla wielu klientów, bo każdy klient może pingować bramę, to sposób, w jaki wdraża się to źle.

Kierunek przychodzący sprawdza się inaczej: źródło odebranego pakietu musi mieścić się w dozwolonej liście uwierzytelnionego peera. Dodanie tam celu multicast nie zastępuje rzeczywistego władania źródłem przez nadawcę.

Odbicie to granica, nie most

Reflektor Avahi odtwarza komunikaty mDNS między wybranymi interfejsami na warstwie aplikacji. To granica odkrywania między sieciami, nie most Ethernet i nie ogólny router multicast. Dwa reflektory podłączone do tych samych sieci ochoczo stworzą pętlę powtarzanych ogłoszeń.

Odbicie przekazuje też nazwy usług i ich metadane do innej sieci, co jest decyzją o prywatności tak samo jak decyzją o trasowaniu. Ogranicz wybrane interfejsy i używaj filtrów usług tam, gdzie zainstalowana wersja je obsługuje, aby granicę przekraczały tylko ogłoszenia potrzebne upoważnionemu użytkownikowi.

Odkrywanie i używanie pozostają osobnymi wynikami. Klient może zobaczyć ogłoszenie usługi, której ogłaszany adres jest nieosiągalny z miejsca, w którym znajduje się klient, albo której port jest odrzucany przez jego politykę dostępu. Potwierdź połączenie z usługą po pojawieniu się ogłoszenia, a jeśli aplikacja obsługuje stabilną nazwę DNS lub jawny adres serwera, preferuj to zamiast rozszerzania lokalnego odkrywania łącza. Opis trasowania kluczem kryptograficznym obejmuje wybór peera oparty na celu, od którego to wszystko zależy.