Kto powinien posiadać trasy i DNS, gdy openfortivpn się łączy?

W działającej sesji openfortivpn cztery etapy nakładają się na siebie. Klient uwierzytelnia się przy bramie i rozpoczyna połączenie TLS, następnie uruchamia PPP wewnątrz tego połączenia, potem otrzymuje adres i informacje DNS, a na końcu stosuje trasy hosta i ustawienia resolwera. Każdy etap może żyć, gdy następny nie, i dlatego „połączono” to takie śliskie słowo w wątkach pomocy.

Decyzja, która usuwa większość zamieszania, to kto posiada ostatni etap. Albo klient VPN sam stosuje zmiany hosta, albo robi to inny komponent, a mieszanie obu do połowy sprawia, że trasy i pliki resolwera opisują różne sesje.

Cztery etapy, które wyglądają jak jedno połączenie

Pierwszy etap to wpuszczenie. nazwana domena uwierzytelniania lub kod jednorazowy, i otrzymuje parametry potrzebne do kontynuacji. Gdy klient wypisuje, że jest połączony z bramą, oznacza to, że transport TLS działa. Nie oznacza to, że PPP wynegocjował, i z pewnością nie oznacza, że aplikacja wewnętrzna jest osiągalna.

Drugi etap to łącze PPP. Klient uruchamia proces PPP wobec urządzenia tunelowego, a obie strony negocjują opcje łącza i adresy. Dopiero potem host wie, jakich adresów lokalnych i zdalnych używa sesja, i dopiero wtedy trasa prowadząca do tunelu ma sens.

Trzeci etap to zastosowanie tych informacji na hoście, i tu liczy się własność. Klient może dodać trasy i przepisać konfigurację resolwera, albo można mu kazać ustąpić i zostawić oba temu, co inaczej zarządza siecią na tej maszynie. README projektu opisuje je jako odrębne obowiązki, a nie jedno automatyczne zachowanie.

Kto edytuje tablicę routingu

Domyślnie właścicielem jest klient. Dodaje trasę do bramy przez interfejs fizyczny, trasę dla peera tunelu i trasy dla sieci, których sesja może używać, a następnie usuwa je, gdy proces kończy działanie. Ta domyślna wartość jest wygodna na laptopie z jednym menedżerem sieci i bez innego oprogramowania VPN.

Wybierz przekazanie tylko wtedy, gdy coś innego naprawdę posiada routing. Integracja z menedżerem sieci, przestrzeń nazw sieci kontenera lub agent routingu dla całej witryny mogą już wiedzieć, jak instalować i usuwać te same prefiksy. Przekazanie opcji no-routes zapobiega wtedy walce dwóch pisarzy o tę samą tablicę, co jest wyścigiem objawiającym się jako okresowa utrata jednej podsieci, a nie jako czysty błąd.

Nakładanie się to drugi powód przekazania. Jeśli wypychane trasy zawierają prefiks, którego sieć lokalna już używa, klient nie może rozwiązać konfliktu za Ciebie. Ktoś musi zdecydować, czy ten prefiks jest osiągalny przez tunel, przez łącze fizyczne, czy przez bardziej szczegółową trasę, i ta decyzja należy do właściciela topologii.

Sprzątanie jest trzecie. Klient, który zawiesi się przed usunięciem swoich tras, zostawia czarną dziurę, która przeżywa sesję, a następne połączenie może dodać na niej duplikat. Kto posiada routing, ten posiada też sprawdzenie, że stare wpisy zniknęły. Uczyń ten test częścią ścieżki startu, a nie opcjonalnym krokiem sprzątania.

Kto posiada DNS i plik resolwera

DNS to ta sama decyzja z ostrzejszymi krawędziami. Klient może przyjąć serwery DNS zgłaszane przez bramę lub peera PPP i zapisać je w konfiguracji resolwera hosta. Na prostej maszynie to dokładnie to, czego chcesz, ponieważ nazwy wewnętrzne rozwiązują się wtedy tylko tak długo, jak tunel działa.

Na nowoczesnym hoście Linux resolwerem może zarządzać lokalny stub, a przepisywanie pliku resolwera za plecami tego stubu daje konfigurację, która wygląda poprawnie i zachowuje się niespójnie. Jeśli host już uruchamia menedżer resolwera, pozwól mu posiadać DNS i podawaj mu serwery tunelu przez jego obsługiwany interfejs. Opcja no-dns klienta jest tam właściwym wyborem, a nie obejściem.

Rozdzielony DNS to osobne pytanie od tego, kto pisze plik. Wysyłanie każdego zapytania przez tunel jest proste i wolne; wysyłanie przez niego tylko stref wewnętrznych wymaga konfiguracji dla każdej domeny, której większość prostych klientów nie oferuje. Zdecyduj, jakiego zachowania potrzebuje host, zanim włączysz zmiany resolwera klienta. Zły wybór tutaj wygląda jak awaria rozwiązywania nazw, nawet gdy sam tunel jest w porządku.

Uprawnienia, gotowość i przekazanie

Utworzenie urządzenia tunelowego i edycja tras hosta lub stanu resolwera wymaga podniesionych uprawnień sieciowych. Częstym błędem jest wniosek, że dlatego wszystko musi działać jako root, łącznie z przeglądarką lub aplikacją korzystającą z tunelu. Utrzymuj uprzywilejowaną część małą: klient i jego plik konfiguracji, należące do administratora, podczas gdy aplikacje użytkownika zachowują zwykłe konto.

Gotowość powinna być definiowana dla każdego odbiorcy. Nadzorca może uznać usługę za uruchomioną, gdy proces klienta działa i urządzenie tunelowe istnieje. Zadanie kopii zapasowej powinno uznawać VPN za użyteczny tylko wtedy, gdy jego punkt końcowy przechowywania odpowiada przez tunel. To różne testy, a użycie słabszego do silniejszego celu daje zadania, które startują zbyt wcześnie i okresowo zawodzą. Zapisz wybraną definicję, ponieważ nadzorca i zadanie, które nie zgadzają się co do gotowości, to zgłoszenie do pomocy czekające na wystąpienie.

Przetestuj umowę czterema obserwacjami: faza bramy się kończy, PPP przydziela adresy, zamierzona trasa jest obecna i żądanie do hosta wewnętrznego się udaje. Następnie zatrzymaj klienta i potwierdź, że każdy z tych elementów został usunięty lub przywrócony. Jeśli host nadal rozwiązuje nazwy wewnętrzne lub nadal trzyma trasę po zamknięciu tunelu, przekazanie własności jest niekompletne.