Trasa IP odpowiada prefiksowi adresu, a jądro stosuje ją bez zadawania dalszych pytań. Reguła VPN oparta na domenie odpowiada nazwie, co oznacza, że coś w stosie musi zdecydować, jakie adresy ta nazwa obecnie oznacza, i utrzymywać tę decyzję aktualną. To różne mechanizmy o różnych trybach awarii, a dostawcy używają tego samego słowa dla obu. Porównywanie ich na listach funkcji mija się z celem; porównuj je pod kątem tego, co się dzieje, gdy odpowiedź się zmienia.

Użyteczny podział przebiega między regułą, która rozwiązuje, a regułą, która tego nie robi.

Z czym każda reguła faktycznie się zgadza

Reguła prefiksu dopasowuje adresy docelowe w tabeli routingu. Nic się nie rozwiązuje, nic nie wygasa, a dopasowanie jest dokładne dla każdego pakietu. Reguła domeny dopasowuje żądanie aplikacji o nazwę, którą RFC 1034 definiuje jako drzewo etykiet, a nie adres. Niektóre produkty rozwiązują nazwę raz i instalują wynikowe adresy jako trasy, co czyni regułę regułą IP z dołączonym licznikiem odświeżania.

Zanim zaczniesz debugować, ustal, którą z tych dwóch masz, bo awaria wygląda zupełnie inaczej w każdym przypadku.

Gdzie w stosie mieszka reguła domeny

Jeśli produkt implementuje reguły domenowe przez lokalne proxy, ruch musi dotrzeć do tego proxy, a aplikacje ignorujące proxy systemowe całkowicie omijają regułę. Jeśli implementuje je przez rozwiązywanie nazw i dodawanie tras, adresy są tak świeże jak ostatnie odświeżenie. Jeśli podłącza się do resolvera, zachowanie DNS staje się częścią polityki routingu, a zapasowy resolver może to po cichu cofnąć.

Czytaj model dostawcy, a nie etykietę ustawienia. Dwaj klienci z polem o nazwie Split Tunnel mogą robić trzy różne rzeczy.

Porównaj, co się psuje

Trzy rzeczy psują się różnie. Zmiana adresów: nazwa hosta CDN może w ciągu kilku minut rozwiązać się na inny zestaw adresów, więc skopiowana lista szybko się starzeje. Zasięg subdomen: reguła dla example.com może obejmować api.example.com albo nie, a dokumentacja zwykle jasno mówi, który przypadek zachodzi. Błąd rozwiązywania: gdy resolver zawiedzie, klient rozwiązujący może przejść na tunelowanie ruchu albo na wysyłanie go bezpośrednio.

Tylko drugie jest kwestią konfiguracji. Pozostałe dwa to kwestie projektowe dotyczące tego, ile produkt jest gotów zgadywać.

BehaviourPrefix ruleDomain rule
Match basisdestination addressrequested name or resolved addresses
Stalenessnonedepends on refresh policy
Subdomain scopenot applicableproduct-defined
Resolver outageunaffectedproduct-defined fallback
Where to debugrouting tableclient log plus resolver state

Kiedy prefiks jest lepszą odpowiedzią

Dla stabilnej podsieci prywatnej jawny prefiks jest jaśniejszy, szybszy i łatwiejszy do audytu. Przetrwa też awarię resolvera, bo nic nie musi być rozwiązywane. Sięgaj po regułę domeny, gdy usługa jest hostowana, gdy adresy rotują albo gdy naprawdę nie potrafisz wyliczyć zestawu miejsc docelowych. Nie sięgaj po nią tylko dlatego, że nazwa hosta to jedyna rzecz, którą przypadkiem znasz.

Zgadywana lista statyczna jest najgorsza z obu: wygląda na utrzymywaną i po cichu pomija ruch w dniu, w którym dostawca doda hosta.

Zweryfikuj świeżym żądaniem

Przetestuj zimnym żądaniem po normalnym ponownym połączeniu, ponieważ strona z pamięci podręcznej może nigdy nie dotknąć reguły. Rozwiąż nazwę, a następnie sprawdź, dokąd połączenie faktycznie poszło. dig +short app.example.com podaje bieżący zestaw adresów, a lista połączeń klienta mówi, które interfejsy przeniosły przepływ.

Powtórz po interwale odświeżania, który dokumentuje produkt. Jeśli zestaw adresów się przesuwa, a reguła za nim nie podąża, znalazłeś rzeczywiste zachowanie.

Trzymaj też politykę resolvera osobno. Reguła domeny potrzebuje poprawnych danych o nazwach, ale sama nie decyduje, który resolver odpowiada na zapytanie.

Powiązane artykuły