Dlaczego reguła blokowania klienta OpenVPN nigdy nie trafia w FORWARD

Dwaj klienci na tym samym serwerze OpenVPN mogą się wzajemnie osiągnąć, mimo że dodano regułę DROP dla ich puli. Reguła siedzi w łańcuchu FORWARD, ruch wyraźnie płynie, a licznik tej reguły pozostaje na zerze. Naturalny wniosek jest taki, że zapora jest zepsuta. Częściej pakiet w ogóle nie wszedł do łańcucha.

Istnieją dwie ścieżki, którymi pakiet peera może przejść przez serwer OpenVPN, i decyduje o nich konfiguracja, a nie zapora. Wiedza o tym, która ścieżka jest używana, mówi, czy reguła hosta jest w ogóle we właściwym miejscu.

Dwie ścieżki, którymi może przejść pakiet peera

Gdy opcja wewnętrznego przekazywania jest wyłączona, pakiet od klienta A przychodzi na interfejs tunelu z celem wewnątrz przypisanego adresu klienta B. Tablica routingu serwera odsyła go tą samą ścieżką przez interfejs tunelu, ponieważ trasa do adresu B należy do serwera. To przepływ do środka i na zewnątrz przez hosta, i ocenia go ścieżka przekazywania IPv4.

Gdy opcja wewnętrznego przekazywania jest włączona, proces serwera dopasowuje pakiet do połączonego klienta i zapisuje go z powrotem bezpośrednio do tego klienta. Pakiet jest obsługiwany wewnątrz demona i nigdy nie wraca do urządzenia tunelu, więc ścieżka przekazywania hosta jest całkowicie pomijana. Podręcznik OpenVPN 2.6 opisuje tę opcję jako wewnętrzne przekazywanie od klienta do klienta, i właśnie dlatego reguła zapory hosta nie może jej zobaczyć.

Istnieje trzeci wariant w instalacjach, które przenoszą kanał danych do modułu jądra. Decyzja o przekazywaniu i szyfrowanie wychodzą z przestrzeni użytkownika, a to, czy netfilter widzi przepływ, zależy od tego, jak zbudowana jest ścieżka przenoszenia. Nigdy nie zakładaj, że stary zestaw reguł zachowuje się na serwerze z przenoszeniem tak samo jak na serwerze w przestrzeni użytkownika. Potwierdź tryb z działającej konfiguracji, a nie z wersji pakietu.

Gdy licznik nigdy się nie rusza

Zerowy licznik oznacza, że pakiet nie pasował do tej reguły w tym punkcie, a przyczyn jest kilka. Pierwsza to opisane wyżej obejście: ruch nigdy nie dotarł do łańcucha. Druga to niezgodność interfejsu, kierunku, źródła lub celu, co jest częste, gdy pula została przenumerowana, a reguła wciąż wymienia stary prefiks.

Trzecia to pozycja. Reguła wcześniej w łańcuchu może zaakceptować przepływ, zanim twoja DROP zostanie oceniona, a reguła później może być tą, która faktycznie rozstrzyga wynik. Czytaj łańcuch po kolei z widocznymi licznikami, a następnie sprawdź, który licznik rośnie, gdy powtórzysz test.

Wykonaj jedną kontrolowaną wymianę między dwoma klientami, których rzeczywiste adresy potwierdziłeś na podstawie stanu samego serwera, a nie z dzierżawy, którą pamiętasz. Jeśli odpowiedni licznik nadal się nie rusza, podejrzewaj ścieżkę, zanim przepiszesz dopasowanie. Jeśli się rusza, ale połączenie nadal się udaje, drop jest później nadpisywany i problemem jest kolejność. Ta odpowiedź decyduje, czy naprawa jest zmianą reguły, czy zmianą topologii, więc zdobądź ją przed edycją czegokolwiek.

Wybór granicy, która potrafi filtrować

Jeśli polityka musi mieszkać w zaporze hosta, umieść ruch tam, gdzie zapora go widzi. Wyłączenie wewnętrznego przekazywania to wspierany sposób, aby ruch peerów przechodził przez interfejs tunelu i ścieżkę przekazywania, za cenę przepuszczania każdego pakietu peera przez stos hosta.

Następnie dopasuj przepływ precyzyjnie. Ruch przychodzi na interfejs tunelu i wychodzi z interfejsu tunelu, w obu kierunkach, więc reguły, które biorą pod uwagę tylko interfejs fizyczny, nie dopasują. Reguły oparte na adresach potrzebują bieżącej puli i muszą uwzględniać kierunek powrotny tak samo jak kierunek w przód.

Wielu instalacjom lepiej służy filtrowanie na poziomie klienta lub grupy, gdzie tożsamość jest znana, a polityka podąża za użytkownikiem, a nie za adresem, który zmienia się przy ponownym połączeniu. To inny mechanizm niż łańcuch hosta i tych dwóch nie należy mieszać bez jasnego powodu.

Nie przenoś zestawu reguł starej topologii przez migrację bez zmian. Pule adresów, nazwy interfejsów i tryby przekazywania wpływają na to, czy reguła pasuje, a skopiowana reguła, która kiedyś działała, jest najbardziej mylącym rodzajem dowodu. Zacznij od przepływu, który chcesz dopuścić, i napisz regułę, która do niego pasuje.

Testowanie izolacji zamiast zaufania do reguły

Przetestuj przypadek zabroniony i przypadek dozwolony w tym samym uruchomieniu. Rozpocznij nowe połączenie z jednego klienta do drugiego i potwierdź, że zawodzi, a następnie potwierdź, że połączenie, które powinno być dozwolone, nadal działa. Jeśli testuje się tylko pierwsze, zapora blokująca wszystko wygląda jak sukces.

Powtórz po ponownym wczytaniu konfiguracji serwera i po ponownym połączeniu klienta, ponieważ wewnętrzne przekazywanie i przypisania puli są stanem czasu wykonania. Sprawdzaj liczniki w obu kierunkach, ponieważ reguła dopasowująca jeden kierunek, a nie odpowiedź, daje częściową izolację, którą trudno zauważyć w szybkim teście.

Izolacja to zaobserwowany wynik na granicy, która naprawdę niesie przepływ. Reguła DROP gdzieś w hoście nie jest dowodem; nieudane połączenie plus przesunięty licznik reguły, która je spowodowała, jest dowodem.