Dlaczego klient VPN w sieci biurowej traci każdą odpowiedź

Laptop siedzi w /24 biura przez Ethernet i jednocześnie dołącza do serwera OpenVPN, który mieszka w tym samym /24. Kolega pinguje adres tunelu; żądanie wyraźnie dociera, a nic nie wraca. Dziennik tunelu jest czysty, a przeglądanie nadal działa, więc tunel jest niewłaściwym podejrzanym. Walidacja źródła IPv4 na maszynie odbierającej wyrzuca pakiet, zanim cokolwiek go odczyta.

Odrzucenie następuje, zanim cokolwiek odczyta pakiet

Walidacja źródła zadaje jedno pytanie o każdy pakiet przychodzący: gdyby ten host odpowiedział temu źródłu, czy odpowiedź wyszłaby przez interfejs, na który pakiet właśnie przyszedł? Gdy odpowiedź brzmi nie, jądro wyrzuca pakiet przy nadejściu. Ani gniazdo, ani ścieżka przekazywania nigdy tego nie widzą, dlatego zrzut na tunelu wciąż zapisuje żądanie, którego aplikacja nigdy nie otrzymuje.

Klient tutaj trzyma 10.66.0.9 na swoim tunelu, a serwer OpenVPN odpowiada pod 192.168.80.10 wewnątrz prefiksu biura. Kolega pod 192.168.80.25 pinguje adres tunelu, więc żądanie przechodzi przez sieć lokalną, serwer kieruje je do tunelu, i trafia ono na interfejs tunelu klienta z adresem źródłowym biura. W tablicy routingu tej maszyny prefiks biura należy do urządzenia Ethernet, a nie do tunelu. Walidacja porównuje interfejs nadejścia z trasą, znajduje niezgodność i odrzuca pakiet, więc kolega widzi całkowitą utratę, podczas gdy oba końce raportują zdrowy tunel.

Kierunek lustrzany ma ten sam kształt: gdy klient zaczyna w stronę biura, odpowiedzi mogą zostać odrzucone po stronie biura z dokładnie tego samego powodu. Poprawka sprawdzona tylko w jednym kierunku zwykle wraca jako drugie zgłoszenie.

Udowodnij obowiązujący tryb, zanim dotkniesz jakiegokolwiek sysctl

Czytaj wartości efektywne zamiast ufać domyślnej dystrybucji, bo ustawienie dla interfejsu to tylko połowa decyzji. Obowiązujący tryb to wyższa z wartości interfejsu i wartości all, więc zero na interfejsie tunelu nic nie znaczy, dopóki all wynosi jeden. Decyzja trybu ścisłego jest decyzją routingu, więc uruchom wyszukiwanie, które uruchamia jądro, i porównaj jego odpowiedź z interfejsem, przez który pakiet naprawdę przyszedł.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Następnie powtórz ping, obserwując licznik błędów. Rosnący licznik obok żądania, które zrzut już pokazuje, jest sygnaturą tego odrzucenia, a nie brakującej trasy. Włącz rejestrowanie pakietów marsjańskich, póki tam jesteś, aby jądro nazwało odrzucone źródło i interfejs. Razem wykluczają szyfr, zaporę i brakujący iroute jako wyjaśnienia.

Zapisz stan wyjściowy, zanim cokolwiek zmienisz: obie wartości, urządzenie wybrane przez wyszukiwanie i licznik, który obserwowałeś. To ten zapis powie ci później, czy zmiana zrobiła to, co myślisz.

Co naprawdę akceptuje każdy tryb rp_filter

Jądro pokazuje trzy wartości na interfejs, i nie są to trzy odcienie jednej reguły. Zero wyłącza sprawdzanie. Jeden jest ścisły i wymaga, aby źródło było routowane z powrotem przez interfejs nadejścia. Dwa jest luźny i wymaga tylko, aby w tablicy istniała jakakolwiek trasa do źródła, gdziekolwiek wskazuje.

Wiersz, który tu ma znaczenie, to ten luźny, i to, czego nadal odmawia. Fałszywe źródło, które da się routować gdziekolwiek w twojej tablicy, przechodzi, podczas gdy źródło bez żadnej trasy wciąż jest odrzucane. Na laptopie to wąska ustępstwo; na routerze przekazującym ruch innych ludzi jest szerokie. Tryb należy do hosta, więc ta sama liczba ma inną wagę w dwóch miejscach.

Który wiersz jest potrzebny tej topologii, wynika z tablicy, a nie z nawyku. Pakiet jest legalny, a jego źródło jest routowalne, więc luźny go akceptuje, a ścisły nie. Nic w tej sprawie nie wymaga zera, a wybór zera usunąłby sprawdzenie, które tu nic nie kosztuje.

Wybierz najmniejszą zmianę, która usuwa niejednoznaczność

Tryb luźny jest najmniejszą pasującą zmianą i jest realnym obniżeniem rygoru, a nie nieszkodliwym przełącznikiem. Lepsza opcja istnieje zawsze, gdy topologia na to pozwala: usuń nakładanie się, a niejednoznaczność znika.

Tam, gdzie prefiks biura jest potrzebny tylko przez Ethernet, usuń go z tras, które ciągnie profil, i adres staje się osiągalny jedną ścieżką. Gdy obie ścieżki naprawdę muszą współistnieć, przypnij źródło i urządzenie regułą polityki zamiast poluzowywać walidację na każdym interfejsie. To zachowuje ścisłe filtrowanie dla wszystkiego innego na maszynie i dokumentuje wyjątek tam, gdzie następny inżynier będzie go szukał.

Którąkolwiek ścieżkę wybierzesz, zapisz ją w drop-inie sysctl, a nie w żywej komendzie. Ustaw klucze all i default razem, aby ponowne połączenie nie mogło po cichu przywrócić trybu ścisłego.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Czego luźny tryb się zrzeka, i gdzie

Tryb luźny wciąż odrzuca źródło, do którego nie dotarłaby żadna trasa, i przestaje odrzucać fałszywe źródło, które przypadkiem jest routowalne. Na laptopie to wąska ustępstwo. Na urządzeniu przekazującym ruch, który nie jest jego, ten sam wybór jest znacznie szerszy. Dlatego to samo ustawienie ma dwa bardzo różne znaczenia w zależności od tego, gdzie działa.

Wyłączenie sprawdzania całkowicie na hoście przekazującym ruch za innych ludzi to jedyna naprawa, której należy unikać. Zero wyrzuca walidację, którą tryb luźny starannie zachowuje. Jeśli host przekazuje za innych, argumentuj zamiast tego za opcją reguły polityki z poprzedniej sekcji.

Zostaw notatkę, która nazywa oba interfejsy, nakładający się prefiks i dokładny test, który teraz się udaje. To jest bardziej przydatne następnemu inżynierowi niż wiersz, że filtrowanie zostało dostrojone.