Znikają odpowiedzi Linux VPN? Sprawdź rp_filter i trasę

Żądania opuszczają maszynę, peer VPN odpowiada, a odpowiedź nigdy nie dociera do gniazda. Tunel jest podniesiony, logi peera pokazują wysyłkę pakietu, i nic w aplikacji nie wyjaśnia ciszy. W Linuksie jednym z typowych podejrzanych jest filtrowanie trasy powrotnej: przychodzący pakiet IPv4 może zostać odrzucony, gdy walidacja źródła nie zgadza się z trasą, której jądro oczekuje dla tego źródła. Przejście tego po kolei mówi, czy to przyczyna, czy zbieg okoliczności. Chroni też przed wyłączeniem kontroli bezpieczeństwa, żeby naprawić brakującą trasę.

Co rozstrzyga walidacja źródła

Jądro sprawdza, czy adres źródłowy pakietu jest wiarygodny dla interfejsu, przez który przyszedł, zaglądając do tablicy routingu po trasę z powrotem do tego źródła. Jeśli trasa powrotna wskazuje gdzie indziej, pakiet może zostać odrzucony, zanim zobaczy go jakakolwiek reguła firewalla lub gniazdo aplikacji. Ta kontrola istnieje po to, by utrudnić pewne wzorce podszywania się, i dlatego projekty asymetryczne oraz routowane politycznie na nią trafiają, podczas gdy każdy zwykły klient w tej samej sieci działa dobrze. Zwykli klienci mają routing symetryczny, i dokładnie to zakłada kontrola.

Ważne słowo to wiarygodny. Pakiet może być całkowicie legalny i mimo to nie przejść kontroli, bo bada się nie legalność.

Czytaj faktyczny tryb, nie jedno pole

Istnieją trzy tryby: wyłączony, ścisły i luźny. Ścisły narzuca inne oczekiwanie trasy niż luźny, a ustawienie globalne współdziała z tymi dla każdego interfejsu, więc czytanie jednego pliku może błędnie opisać to, co naprawdę obowiązuje. Czytaj oba i czytaj je na interfejsie, który odbiera odpowiedź, a nie na interfejsie trasy domyślnej.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Wyszukanie trasy w trzeciej linii to część, którą ludzie pomijają. Mówi, co jądro sądzi o źródle, i to jest dokładnie wejście kontroli.

Znajdź niezgodność, zanim zmienisz kontrolę

Ustal, dlaczego odpowiedź przychodzi na ten interfejs i czy jej trasa powrotna powinna być inna. Reguła polityki, która wysyła żądania jedną drogą, a zwraca odpowiedzi inną, jest legalnym projektem, i właśnie ten projekt odrzuca ścisła walidacja. Znaczniki używane w routingu politycznym też mogą tu mieć znaczenie, bo zmieniają to, co zwraca wyszukanie wsteczne.

Jeśli trasy powrotnej po prostu brakuje, dodanie jej naprawia przyczynę, zamiast wyłączać kontrolę. Brakująca trasa, odmowa firewalla i zły selektor ruchu dają ten sam widoczny objaw, a tylko jeden z nich dotyczy walidacji źródła.

Nie wyłączaj kontroli źródła globalnie jako pierwszej reakcji. To zamienia konkretną diagnozę na szeroką zmianę zachowania, którą trzeba będzie później pamiętać.

Selektywne dostosowanie, którego można bronić

Jeśli wąskie dostosowanie jest naprawdę konieczne, ogranicz je do interfejsu, który go potrzebuje, zapisz dlaczego i umieść w konfiguracji, która jest właścicielem tego interfejsu, aby przetrwało restart. Potem przetestuj ponownie dokładnie ten przepływ, który zawiódł, z tego samego źródła do tego samego celu, zamiast pingu do czegoś wygodnego.

Uwzględnij przypadek, który nadal powinien być odrzucany. Jeśli ten przypadek teraz się udaje, dostosowanie osłabiło więcej niż jedną ścieżkę, którą chciałeś naprawić.

Trzymaj IPv4 i IPv6 osobno

Znajomo wyglądający sysctl nie jest polityką dla każdej rodziny adresów. IPv6 ma własne zachowanie i własne ustawienia, a maszyna może być ścisła w jednej rodzinie i pobłażliwa w drugiej, nikt tego nie zauważy, dopóki nie zawiedzie konkretny cel. Sprawdź oba, jeśli obciążenie używa obu.

Zapisz tryb, interfejs, wynik wyszukania trasy i powód zmiany w jednym miejscu. Następna osoba znajdzie ustawienie i żadnego wyjaśnienia, i albo je usunie, albo skopiuje tam, gdzie nie należy.