Zachowaj trasy prywatne i porzuć przekierowanie: tunel dzielony OpenVPN

Tunel wstaje, aplikacja się ładuje, a potem wszystko inne na laptopie zaczyna zachowywać się dziwnie. To zwykły kształt polityki tylko dla sieci prywatnych wdrożonej przez usunięcie jednej linii. Usunięcie wypchniętej trasy domyślnej rzeczywiście zmienia to, dokąd trafia ruch, ale nie mówi, dokąd ruch powinien trafić zamiast tego, i w ogóle nie dotyka rozwiązywania nazw. Polityka potrzebuje dwóch pozytywnych połówek, zanim można ją przetestować.

Usunięcie przekierowania to tylko połowa zmiany

Przekierowanie całego tunelu i polityka tylko dla sieci prywatnych różnią się tym, co twierdzą o świecie. Przekierowanie rości sobie prawo do każdego celu, a polityka prywatna rości sobie prawo do listy i zostawia resztę w spokoju. Usunięcie roszczenia bez napisania listy daje klienta, który nie dociera nigdzie poza sieć lokalną, co wygląda na awarię routingu, a nie na lukę w polityce. Napisz listę, zanim usuniesz roszczenie, a wtedy kolejność tych dwóch kroków przestanie mieć znaczenie.

Obie połówki są wymaganiami, a nie wartościami domyślnymi. Prefiksy prywatne muszą wejść do tunelu, a zwykłe cele muszą zachować ścieżkę, którą miały przed połączeniem.

Jeśli organizacja wymaga pełnego tunelu, nic z tego nie obowiązuje. Projekt tylko dla sieci prywatnych należy do wdrożeń, w których routing dzielony jest zatwierdzony.

pull-filter to dopasowanie, a nie przełącznik

Dyrektywa pull-filter usuwa wypchnięte opcje, których nazwy pasują do prefiksu, i to wszystko, co robi. Zignorowanie przekierowania zostawia każdą inną wypchniętą opcję na miejscu, co zwykle jest tym, czego chcesz: trasy, ustawienia DNS i wartość bramy trasy wciąż docierają. Nie może też usunąć dyrektywy zapisanej w profilu lokalnym, ponieważ filtrowanie dotyczy tego, co wypycha serwer.

Oprzyj się pokusie ignorowania każdej opcji zaczynającej się od route. Ten wzorzec odrzuca także trasy prywatne potrzebne połączeniu i może zgubić informacje o bramie, od których zależy tunel.

route-nopull to szersza decyzja, niż się wydaje. Powstrzymuje klienta przed przyjmowaniem wypchniętych tras i opcji w stylu DHCP jako grupy, co jest inną polityką niż odfiltrowanie jednej opcji.

Napisz listę tras od aplikacji na zewnątrz

Zacznij od tego, co użytkownik naprawdę otwiera, a potem dodaj części wspierające. Aplikacja pod 10.60.20.15 implikuje swoją podsieć 10.60.0.0/16, a nazwa prywatna implikuje resolver, który na nią odpowiada. Użytkownik, który poprosił o jedną aplikację, potrzebuje więc dwóch celów i jednej decyzji DNS. Wszystko poza tą listą jest z założenia poza zakresem i właśnie to utrzymuje politykę weryfikowalną.

Na współpracującym serwerze stają się one dwiema wypchniętymi trasami i żadna z nich nie jest przekierowaniem. Zachowaj topologię tunelu i wartości bramy trasy, które dostarcza istniejąca usługa.

Gdy tylko niektórzy użytkownicy potrzebują tej polityki, zastosuj ją dla klienta lub grupy. Zmiana routingu wszystkim, aby naprawić wymaganie jednego zespołu, to droga, na której tunel dzielony staje się awarią.

Niech DNS podąża tą samą ścieżką

Trasa do resolvera nie jest polityką resolvera. Na kliencie systemd-resolved wynikiem semantycznym jest domena routingu dla prywatnej przestrzeni nazw wskazująca na wewnętrzny resolver, i to sprawia, że tylko te nazwy go używają. Klient Windows potrzebuje zamiast tego własnego mechanizmu polityki przestrzeni nazw. Linia serwera DNS w profilu nie instaluje żadnego z nich sama z siebie.

Sprawdź, co wybrał system operacyjny, a nie czego zażądał profil. W Linuksie resolvectl status pokazuje domenę i serwer dla każdego łącza; w Windowsie tabela polityki przestrzeni nazw jest równoważnym dowodem.

Utrzymuj resolver osiągalny przez tunel, inaczej polityka wskazuje adres, o który nie można zapytać. Adres resolvera, do którego tunel nie dociera, zamienia działającą politykę w przekroczenie limitu czasu.

Zweryfikuj obie połówki przy ponownym połączeniu

Połącz klienta ponownie po zmianie i sprawdź efektywną trasę do adresu prywatnego i do publicznego. Następnie rozwiąż nazwę prywatną i publiczną i potwierdź, że każda użyła zamierzonego resolvera. Załadowanie publicznej witryny dowodzi tylko drugiej połowy i to ta połowa zwykle działa przypadkiem.

Zapisz gotową politykę w jednym zdaniu: te prefiksy i nazwy używają tego połączenia, wszystko inne idzie ścieżką lokalną. Potem trzymaj ją w profilu, zamiast naprawiać ustawienia karty po każdym logowaniu.