BIND przez VPN: przekazywanie warunkowe czy strefa stub?

Trzy sposoby rozwiązania jednej prywatnej strefy przez VPN i kiedy który pasuje: forward, stub lub secondary, plus kontrola adresu źródłowego, która decyduje.

Twój resolver biurowy odpowiada na wszystko oprócz jednej przestrzeni nazw firmy, a firmowy serwer DNS, który ją zna, stoi za VPN. BIND może przekazać tę jedną strefę do upstreamu na trzy różne sposoby i każdy zawodzi inaczej. Przekazywanie warunkowe to najmniejsze zobowiązanie, strefa stub zachowuje dane delegacji, a secondary zachowuje pełną kopię. Wybieraj według tego, na co pozwoli upstream i co chcesz, żeby resolver trzymał, a nie według tego, który fragment znalazłeś pierwszy.

Trzy układy dla jednej przestrzeni nazw

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Przekazywanie warunkowe: najmniejsze zobowiązanie

Załóżmy resolver biurowy pod 192.168.10.53 i serwer firmowy pod 10.40.0.53 osiągalny przez zatwierdzony tunel. Deklaracja to trzy linie, a ciekawa jest forward only, bo zmienia zachowanie przy awarii, a nie ścieżkę.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Z forward only nieosiągalny upstream zwraca SERVFAIL dla tej strefy zamiast powrotu do rozwiązywania iteracyjnego. Zwykle tego właśnie chcesz dla prywatnej przestrzeni nazw, bo powrót wysłałby prywatne nazwy do publicznego resolvera i przyniósł bezużyteczną odpowiedź z internetu. Dokumentacja BIND opisuje obie polityki, a różnica jest ważniejsza, niż sugeruje fragment. Włącz strefę do istniejącej konfiguracji, zamiast zastępować strefę, która już istnieje dla tej samej nazwy.

Stub czy secondary: kiedy delegacja ma znaczenie

Strefa stub pyta serwer firmowy o rekordy NS strefy, a następnie odpytuje serwery autorytatywne bezpośrednio. Wybierz ją, gdy region upstreamu jest duży lub podzielony i chcesz, aby resolver szedł za delegacją, zamiast przypinać wszystko do jednego adresu. Kosztem jest zależność od aktualności danych NS oraz od osiągalności każdego wymienionego serwera nazw z adresu źródłowego resolvera.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Secondary odpowiada z danych lokalnych i przetrwa awarię upstreamu, i to jest powód, by zaakceptować zależność od transferu. Oznacza to też, że resolver trzyma teraz kopię strefy, której nie posiada, więc ścieżka pliku, ACL transferu na serwerze podstawowym i liczniki odświeżania stają się częścią Twojej powierzchni operacyjnej.

Kontrola, która rozstrzyga między nimi

BIND sam generuje swoje zapytanie wychodzące, więc pytanie nie brzmi, czy laptop dotrze do 10.40.0.53, ale czy dotrze host resolvera, z adresu źródłowego, który zobaczy serwer firmowy. Zapytaj jądro, potem zapytaj serwer, w tej kolejności.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Zezwól na UDP i TCP na ścieżce: skrócona odpowiedź wymusza TCP, a polityka dopuszczająca tylko UDP powoduje okresowe awarie wyglądające jak utrata pakietów. Strona firmowa potrzebuje zarówno reguły akceptacji dla źródła resolvera, jak i trasy powrotnej do niego; tym źródłem może być adres routowany resolvera lub adres jawnie tłumaczony, i rzadko jest to adres puli klientów. Jeśli zapytanie NS zawiedzie, strefa stub nie może działać, niezależnie od zachowania strefy forward.

Sprawdzaj odpowiedź, nie tunel

Zapytaj przez resolver biurowy o nazwę, o którą nigdy nie pytałeś, i sprawdź sekcję authority odpowiedzi, czy przyszła ze strefy firmowej. Odpowiedź z pamięci podręcznej niczego nie dowodzi o bieżącej ścieżce, a udane bezpośrednie zapytanie do upstreamu nie dowodzi, że resolver wybrał tę strefę. Powtórz to samo zapytanie przez TCP, aby potwierdzić, że ścieżka znosi skracanie.

Trzymaj klientów skierowanych na resolver biurowy, i pozostaw włączoną walidację DNSSEC. Przeglądarka skonfigurowana z niezależnym szyfrowanym resolverem całkowicie omija ten układ, a wyłączanie walidacji, by nieoczekiwana odpowiedź wyglądała poprawnie, zamienia widoczną awarię na niewidoczną.

Zapisz, który z trzech typów wybrałeś i dlaczego. Następna osoba, która zobaczy awarię strefy, będzie potrzebować tego zdania bardziej niż pliku konfiguracji.

Powiązane artykuły