Peer VPN pinguje inne interfejsy, bo są lokalne

Klient WireGuard łączy się i pinguje adres na zupełnie innym interfejsie, a odpowiedź przychodzi. Zrzuty pokazują żądanie tylko na tunelu. Nic nie jest zepsute, a starannie wyłączone ustawienie przekazywania nie ma z tym nic wspólnego. To porównanie dwóch ścieżek, które na schemacie wyglądają podobnie, a w jądrze są zupełnie różne.

Jedna ścieżka przekazuje pakiety za kogoś innego; druga dostarcza je samemu hostowi.

Pakiet zaadresowany do hosta zostaje w hoście

Zdalny klient wysyła pakiet IP na adres, który posiada host. Routing zadaje jedno pytanie o ten pakiet: czy ten cel jest lokalny? Każdy adres, który ma host, pojawia się w lokalnej tablicy routingu, i ta tablica jest sprawdzana przed główną, więc pakiet trafia do własnego stosu hosta, zamiast wychodzić przez inny interfejs. Odpowiedź jest generowana lokalnie i wraca przez tunel, bo stamtąd przyszło zapytanie.

To cały mechanizm. Nie zachodzi żadne przekazywanie, nie uczestniczy żadna zmiana stanu interfejsu, a omawiany adres nie musi być osiągalny znikąd indziej.

Dlaczego ip_forward nie ma zastosowania

Przekazywanie rządzi pakietami, które muszą wyjść przez inny interfejs niż ten, na którym przybyły. Ping do samego hosta nigdy nie idzie tą ścieżką: pakiet jest zużywany lokalnie, a odpowiedź generowana lokalnie. Dlatego ustawienie net.ipv4.ip_forward=0 nic tu nie zmienia, a reguła w łańcuchu przekazywania nigdy nie widzi tego ruchu. Właściwa kontrola znajduje się na ścieżce wejściowej, ograniczona przez interfejs wejściowy lub źródło.

Dlatego wyłączenie przekazywania i założenie, że host jest odizolowany, daje fałszywe poczucie bezpieczeństwa.

Przeczytaj lokalną tablicę, która zdecydowała

ip rule show zwykle zgłasza regułę o priorytecie zero, która wysyła wszystkie wyszukiwania najpierw do tablicy lokalnej, a ip route show table local wymienia własne adresy hosta z lokalnym zasięgiem. Ta tablica obejmuje adresy na interfejsach administracyjnie wyłączonych, ale wciąż skonfigurowanych. Statycznie przypisane adresy IPv4 zwykle przeżywają zerwanie łącza i właśnie dlatego ping do wyłączonego mostu może nadal się udać i zaskoczyć operatora.

IPv6 nie zgadza się dokładnie w tym punkcie. Jego adresy są zwykle wycofywane, gdy łącze spada, chyba że ustawiono keep_addr_on_down. Porównuj rodziny, zamiast zakładać, że jedna reguła obejmuje obie.

Do czego peer rzeczywiście dociera

Odpowiedź z własnego adresu routera w segmencie nic nie mówi o maszynach za tym segmentem. Peer nie może dotrzeć do hosta za drugim interfejsem tą ścieżką; dociera tylko do adresów, które posiada sam router. Testowanie usługi na osobnym hoście LAN, zamiast pingowania adresu routera, jest tym, co ustala, czy przekazywanie jest w ogóle dozwolone.

Ograniczenie peera do usług powiązanych z adresem tunelu to kwestia polityki wejściowej. Zezwól na żądaną usługę na interfejsie tunelu i ogranicz źródła, które mogą jej używać, bo pakiet naprawdę tam dociera.

Sprawdź także adresy, które zamierzałeś wycofać. Usunięcie adresu z interfejsu jest pewniejsze niż piętrzenie reguł zapory na nieaktualnym adresie.