Dwie grupy klientów, jeden serwer: gdzie egzekwować politykę

Umieszczenie dwóch grup klientów w różnych podsieciach wygląda jak izolacja, ale nią nie jest. Adresy opisują, skąd pakiet zdaje się pochodzić, natomiast zezwolenie jest decyzją podejmowaną przez to, co go przekazuje. Na to pytanie odpowiada konfiguracja, a nie maska, więc zdecyduj, który komponent przekazuje ruch między równorzędnymi, zanim napiszesz jakąkolwiek regułę.

Podsieć to etykieta, nie reguła

Przydzielenie jednej puli na grupę daje czytelne adresy i nic więcej. Klient, który akceptuje dodatkową trasę, zyskał osiągalność, a osiągalność nie jest autoryzacją. Zezwolenie na rozmowę tkwi w decyzji o przekazywaniu, która może żyć w demonie lub w jądrze w zależności od konfiguracji serwera.

Własność adresu jest tym, co czyni prefiks użytecznym jako selektor grupy. Każda uwierzytelniona tożsamość musi odpowiadać przewidywalnemu adresowi lub zakresowi, a to mapowanie zawodzi, gdy tylko kilka urządzeń dzieli jedno poświadczenie i jedno przypisanie. Rozwiąż tożsamość i współbieżność, zanim zaufasz prefiksowi źródła, ponieważ polityka, która zgaduje, która maszyna dzwoni, autoryzuje niewłaściwą w najgorszym momencie.

Wybierz ścieżkę, która przenosi ruch między równorzędnymi

Gdy demon przekazuje pakiety równorzędnych we własnym procesie, te pakiety nigdy nie docierają do haka przekazywania hosta, więc reguła jądra nie może ich zobaczyć. Wyłącz to wewnętrzne przekazywanie, a jądro staje się punktem przekazywania, gdzie obowiązują zwykłe reguły przekazywania.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

Odciążone kanały danych i serwery zarządzane przez produkt publikują własne modele egzekwowania, więc potwierdź, który z nich uruchamiasz, zamiast zakładać zachowanie społeczności. Błąd, którego warto uniknąć, to reguła, która wygląda poprawnie w przeglądzie i nigdy nie jest sprawdzana w czasie działania.

Napisz macierz, zanim napiszesz reguły

Krótka macierz jest łatwiejsza do przeglądu niż zestaw reguł i jest kontraktem, który implementacja musi spełnić: równorzędni z tej samej grupy dozwoleni, równorzędni między grupami odrzuceni, obie grupy mają dostęp do jednej nazwanej usługi współdzielonej, wszystko inne odrzucone. Zapisz te cztery linie, zanim otworzysz edytor zapory. Recenzent, który nie czyta składni reguł, nadal może sprawdzić macierz. Implementacja musi potem tylko pasować do linii.

Podczas pisania trzymaj trzy klasy miejsc docelowych osobno. Usługa na hoście VPN to wejście lokalne, inny klient to tranzyt równorzędnych, a maszyna za bramą to inna ścieżka przekazywania. Jedna hojna reguła może przypadkowo przyznać wszystkie trzy, i tak polityka grupowa zmienia się w płaską sieć z dodatkowymi krokami. Zapisz klasę obok każdego wiersza, aby intencja przetrwała następną edycję.

Umieść reguły tam, gdzie przetrwają

Dodaj decyzje w tym samym miejscu, w którym utrzymywana jest reszta zapory, przed każdą regułą zezwalającą, która w przeciwnym razie by je połknęła. Kolejność reguł jest częścią polityki, a poprawna reguła umieszczona po szerokim zezwoleniu nie egzekwuje niczego. Zanotuj numery reguł przed zmianą i po niej. Polityka, która istnieje w edytorze, ale nie w działającym zestawie reguł, jest planem, nie kontrolą.

Zdecyduj, co dzieje się z już istniejącymi przepływami, gdy polityka się zmienia, ponieważ sesja otwarta przed zmianą może trwać dalej. Jeśli odchodzący członek musi natychmiast stracić dostęp, zestaw reguł potrzebuje sposobu na zakończenie tego stanu, zamiast czekać, aż połączenie samo się zamknie.

Uczyń reguły trwałymi poprzez mechanizm, który posiada resztę zapory, i zapisz macierz obok nich. Niezapisana polityka jest ponownie wyprowadzana z pamięci podczas następnego incydentu, zwykle przez kogoś w pośpiechu.

Udowodnij to z obu stron

Przetestuj osiągalność w tej samej grupie, niepowodzenie między grupami i usługę współdzieloną z jednego klienta w każdej grupie. Pojedynczy test z jednego klienta dowodzi połowy macierzy, a połowa, którą pomija, jest zwykle tą błędną. Powtórz kierunek odmowy dwa razy, ponieważ sesja w pamięci podręcznej może ukryć błąd egzekwowania. Zanotuj, którą parę testowałeś, aby następna osoba jej nie powtarzała.

Powtórz sprawdzenie na IPv6, jeśli tunel go przenosi, i zachowaj zwykłe uwierzytelnianie aplikacji. Prefiks źródła nie jest kontem, więc przejście polityki sieciowej nie oznacza, że usługa powinna ufać wywołującemu.