Kto jest właścicielem adresu, trasy, DNS i zapory na Linux VPN?

Dwa skrypty walczące o tę samą trasę to typowa postać problemu z Linux VPN, który trafia do ewidencji jako błąd routingu. Jeden komponent tworzy urządzenie tunelu, drugi dodaje trasę domyślną, trzeci przepisuje konfigurację resolvera, a czwarty ponownie ładuje reguły zapory. Każdy z nich może cofnąć pracę innego, a zwycięzcą jest po prostu ten, który wykonał się ostatni. Pytanie, na które warto odpowiedzieć, nie brzmi, który pakiet zainstalować, ale który komponent jest właściwy dla każdego fragmentu stanu.

Zapisz tę mapę raz, a większość niepowodzeń ponownego połączenia przestanie być zagadkowa. Znaczenie mają cztery obiekty: urządzenie i jego adresy, trasy i reguły polityki, konfiguracja DNS oraz zapora.

Urządzenie i jego adresy

Urządzenie tunelu tworzy albo menedżer znający profil, albo demon uruchomiony ręcznie przez kogoś. Oba układy działają osobno; ich mieszanie nie. Jeśli profil należy do NetworkManagera, pozwól mu też zarządzać urządzeniem, i nie uruchamiaj niezarządzanego OpenVPN procesu przeciw tej samej nazwie tunelu.

Zapisz, kto usuwa urządzenie po zakończeniu sesji. Urządzenie, które przeżywa swoją sesję, jest najczęstszym źródłem przestarzałych adresów i idącego za nimi zamieszania.

Trasy i reguły polityki

To właśnie na trasach konflikty własności wyrządzają widoczne szkody. Menedżer połączeń instaluje trasę domyślną dla tunelu oraz bardziej szczegółową trasę do sieci zdalnej; potem ręcznie napisany skrypt dodaje własną trasę domyślną z inną metryką i po cichu wygrywa albo przegrywa w zależności od czasu. Zdecyduj, które wpisy są związane z połączeniem, które są stałą polityką i który komponent odświeża je po ponownym połączeniu. Potem trzymaj pozostałe komponenty poza tą tabelą.

Reguły polityki zasługują na tę samą jasność, bo reguła wskazująca tabelę, której nikt nie wypełnia, tworzy czarną dziurę wyglądającą dokładnie jak martwy tunel. Jeśli reguła istnieje po to, by gdzieś wpychać ruch, tabela, którą wybiera, musi być utrzymywana przez tego samego właściciela.

DNS zawsze jest osobnym właścicielem

Demon resolvera działa jako własny proces pod własną tożsamością, więc nie dziedziczy przypadkiem decyzji routingu tunelu. Gdy VPN wypycha serwery DNS, coś musi przetłumaczyć to na konfigurację dla każdego łącza, której resolver przestrzega, a coś musi ją potem usunąć.

Mit polega na tym, że wpisanie serwera nazw w profilu zmienia, dokąd trafiają zapytania. Zmienia to, co się mówi resolverowi, a nie to, którego gniazda używa resolver w górę. Testuj zapytaniem i wyszukaniem trasy zamiast ufać plikowi.

Stan zapory i kto go przywraca

Reguły zapory to obiekt najczęściej nadpisywany na hoście VPN. Menedżer może dodawać reguły NAT lub przekazywania dla każdego połączenia, podczas gdy usługa zapory przy starcie ładuje ponownie zapisany zestaw reguł i usuwa je. Wybierz jeden organ dla polityki i zrób z drugiego jej konsumenta, albo zaakceptuj, że restart po cichu zmienia zachowanie. Wyjątki związane z połączeniem należą do pliku, który ładuje ten sam właściciel, a nie do polecenia iptables wpisanego podczas rozwiązywania problemów.

Jeśli reguły mają przetrwać ponowne połączenie, powiedz to wprost. Jeśli nie mają, też powiedz, bo następny inżynier przyjmie wygodniejszą odpowiedź.

Cykl życia: rozruch, ponowne połączenie, demontaż

Daj właściciela każdemu z tych trzech momentów. Przy rozruchu zdecyduj, co przygotowuje warunki wstępne i w jakiej kolejności. Przy miękkim restarcie pamiętaj, że urządzenie może przetrwać, a stan sesji nie, więc musi działać walidator, a nie twórca. Przy demontażu usuwaj tylko to, co utworzyło to połączenie, bo resetowanie każdej trasy albo opróżnienie całej zapory nie jest tym samym co wycofanie jednego tunelu z eksploatacji.

Do obserwacji ip monitor link address route pokazuje zmiany jądra na bieżąco, ale raportuje zdarzenia, a nie intencje: usunięta trasa nie mówi nic o tym, który proces ją usunął. Połącz to z mapą własności, a mylące zamknięcie zamieni się w krótką listę kandydatów.

Wyjątki też mają swoją cenę. Oznaczenie całej klasy urządzeń jako niezarządzanej, by uniknąć konfliktu, oddaje ten stan nikomu, co jest decyzją, a nie poprawką.