Dlaczego wieloznacznik w dyrektywie route OpenVPN nie może działać

trasa instaluje prefiksy adresów, więc wzorzec nazwy hosta nie ma z czym się dopasować. Użyj prefiksu dla sieci i serwera proxy lub pliku PAC, gdy decydują domeny.

Zamiar jest rozsądny: wysłać wszystko dla jednej domeny firmowej przez tunel, a resztę zostawić w spokoju. Edytowana dyrektywa instaluje trasy, a trasa nie ma pojęcia nazwy hosta, z którą można by się dopasować. Każda próba wpisania tam wieloznacznika daje albo błąd analizy, albo, co gorsza, trasę, która dziś działa przypadkiem, ponieważ nazwa została rozwiązana na jeden adres. Dwa różne mechanizmy są proszone o wykonywanie pracy jeden za drugi.

Co instaluje trasa i czego nigdy nie czyta

Wpis trasy mówi, że prefiks miejsca docelowego jest osiągalny przez interfejs. Jądro dopasowuje pakiety do tych prefiksów, więc jedynymi zaangażowanymi identyfikatorami są adresy i maski. Nazwa hosta nigdy nie pojawia się w decyzji o przekazywaniu, dlatego nie można tam dopasować wzorca.

OpenVPN może zaakceptować rozwiązywalną nazwę w niektórych parametrach trasy, a ta tolerancja jest źródłem zamieszania. Nazwa jest rozwiązywana podczas stosowania konfiguracji, dając jeden lub więcej adresów, które stają się zwykłymi trasami. Potem nazwa znika całkowicie z obrazu.

Tak więc trasa zbudowana z nazwy jest migawką, a nie regułą. Obejmuje to, na co ta nazwa została rozwiązana w momencie uruchomienia tunelu, i to jest dokładnie to zachowanie, którego nie chcesz dla zmieniającej się rodziny hostów. Wpis, który przeniesie się jutro, pozostawia trasę wskazującą na wczoraj.

Kiedy miejscem docelowym jest naprawdę prefiks

Jeśli celem jest znana sieć prywatna, wpisz prefiks. Dla przykładu z przestrzeni dokumentacji pojedynczy host i jedna podsieć wyglądają tak:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Oba wpisy nazywają adresy i maski, i oba przetrwają zmiany DNS, ponieważ nic w nich nie zależy od nazwy. Na tym polega cała zaleta: trasa jest twierdzeniem o topologii, a nie o wyszukiwaniu, które zdarzyło się raz.

Nie wyprowadzaj dużego prefiksu z jednej odpowiedzi DNS. Jedna nazwa hosta rozwiązana na jeden adres nic ci nie mówi o rozmiarze sieci za nią, a zgadywany prefiks jest sposobem, w jaki tunel w końcu przechwytuje ruch, którego nikt nie zamierzał przez niego wysyłać. Zapytaj właściciela sieci o rzeczywisty prefiks, zamiast wyciągać go z wyszukiwania.

Kiedy jednostką pracy jest nazwa hosta

Wybieranie według domeny wymaga czegoś, co czyta domenę, czyli komponentu warstwy aplikacji. Zwykłą odpowiedzią jest serwer proxy HTTP, który mieszka po drugiej stronie tunelu, a klient wybiera, które żądania mu wysłać.

Plik konfiguracji serwera proxy może wyrazić ten wybór. Ilustracyjne reguły poniżej wysyłają jedną domenę i jej subdomeny do serwera proxy, a wszystko inne bezpośrednio:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

Porównanie dokładnej nazwy obejmuje samą domenę, a porównanie sufiksu obejmuje jej dzieci, nie dopasowując nazwy, która po prostu kończy się podobnymi znakami. Oba są potrzebne, a pominięcie jednego daje regułę, która wygląda poprawnie i pomija wierzchołek lub oszusta.

Te reguły wybierają serwer proxy; nie tworzą go i nie zmieniają żadnej trasy systemu operacyjnego. Adres serwera proxy nadal potrzebuje własnej ścieżki przez tunel, a żądania oznaczone jako bezpośrednie nadal podlegają polityce routingu, którą maszyna już ma.

Czego opcja serwera proxy nie obejmuje

Programy, które ignorują konfigurację serwera proxy przeglądarki, nie odczują niczego z tego. Narzędzia wiersza poleceń, aktualizatory i aplikacje z własnym stosem sieciowym biorą tablicę tras, a nie plik PAC, więc te przypadki wymagają obsługiwanego mechanizmu dla pojedynczej aplikacji lub innego projektu. Zinwentaryzuj klientów, którzy mają znaczenie, zanim obiecasz, że reguła przeglądarki obejmuje przepływ pracy.

Powrót bezpośredni też nie jest drogą ucieczki. Jeśli polityka routingu maszyny już wysyła wszystko do tunelu, żądanie oznaczone jako bezpośrednie pozostaje w nim, ponieważ wybór serwera proxy i tablica tras to różne decyzje podejmowane na różnych warstwach.

Rozwiązywanie nazw to trzecie, osobne pytanie. Wybór, które żądania idą do serwera proxy, nic nie mówi o tym, który resolver na nie odpowiada, a traktowanie obu jako jednego ustawienia daje wycieki, które są niewidoczne, dopóki ktoś nie przetestuje z zewnątrz. Zdecyduj, gdzie odpowiada się na każde zapytanie, i zapisz tę decyzję obok reguły serwera proxy. Resolver, który zmienia się, bo tunel się podniósł, po cichu przeniesie odpowiedź.

Testować obie ścieżki, nie tylko szczęśliwą

Przetestuj nazwę hosta, która powinna pasować, nazwę hosta, która nie powinna, oraz wierzchołek domeny, ponieważ wierzchołek to przypadek najczęściej pomijany przez regułę opartą tylko na sufiksie. Następnie potwierdź, którą ścieżką każde żądanie faktycznie poszło, zamiast wnioskować to z tego, czy strona się załadowała.

Na koniec przetestuj gałąź awarii. Nieosiągalny serwer proxy powinien zawieść w sposób, który wcześniej ustaliłeś, zamiast po cichu wracać do połączenia bezpośredniego. Dokumentacja opcji sieciowych precyzyjnie opisuje parametry trasy; domenowa połowa tego projektu żyje całkowicie poza nią.

Powiązane artykuły