Reguła domeny VPN psuje się, gdy CDN zmienia swoje adresy

Kopiujesz adres z jednego zapytania do swojej reguły routingu, strona działa, a tydzień później już nie. W regule nic się nie zmieniło. Usługa przeniosła się na inny adres brzegowy, klient rozwiązał inną nazwę hosta albo sesja przeszła na IPv6. Decyzja przed tobą to, czy reguła oparta na nazwie, czy jawny zakres jest właściwym narzędziem dla tej usługi, i trzy warunki to rozstrzygają. To, co dalej, oddziela nazwę od adresu, ponieważ tylko jedno z nich jest stabilne.

Dlaczego jedno zapytanie nie jest inwentarzem

Sieć dostarczania treści odpowiada adresem wybranym dla resolvera, regionu i chwili. Zapytaj dwa razy z różnych sieci, a możesz otrzymać różne odpowiedzi. Zapytaj raz i potraktuj odpowiedź jako listę adresów usługi, a reguła, którą napiszesz, będzie migawką, nie regułą. To cały problem z traktowaniem odpowiedzi DNS jako konfiguracji.

Jest druga luka. Jedna widoczna nazwa hosta rzadko obejmuje całą aplikację, bo logowanie, media i ruch API często używają osobnych nazw. Reguła zbudowana z nazwy hosta w pasku adresu może objąć stronę i pominąć wideo, co czyta się jako częściową awarię, a nie błąd routingu.

Trzecia luka to rodzina adresów. Reguła tylko dla v4 nic nie mówi o rekordzie AAAA, który klient może preferować.

Trzy warunki, które rozstrzygają regułę domeny lub zakresy

Po pierwsze, czy usługa publikuje stabilny zestaw prefiksów, które możesz posiadać i dokumentować? Jeśli tak, jawne zakresy są uczciwe i tanie. Jeśli nie, reguła domeny jest jedynym mechanizmem, który może podążać za usługą.

Po drugie, czy mechanizm domeny twojego klienta się odświeża? Reguła, która rozwiązuje się raz przy połączeniu i nigdy potem, jest migawką z lepszym brandingiem. Po trzecie, czy mechanizm obejmuje subdomeny i obie rodziny adresów, czy tylko nazwy, które wpisałeś?

Odpowiedz na te trzy, a wybór zwykle jest oczywisty. Zgadywanie daje regułę, która działa w teście i zawodzi w produkcji.

Testuj sesję, nie stronę

Wczytaj stronę, a potem wykonaj operację, która ma znaczenie: zaloguj się, rozpocznij odtwarzanie, wyślij plik. Każda z nich może trafić na inny host, a ta, która zawodzi, jest tą, którą twoja reguła pominęła.

Wypisz, z czym sesja faktycznie się łączy, a nie co pokazuje strona:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Trzymaj resolver widoczny podczas porównania, bo reguła, która działa z jednego resolvera i zawodzi z innego, mówi ci o odpowiedzi CDN, nie o tunelu. Krótki TTL oznacza też, że zapisana odpowiedź ma termin ważności.

Co naprawdę obejmuje każdy mechanizm

Oba mechanizmy wyglądają na stronie ustawień na wymienne, a pod spodem zachowują się inaczej.

Trasa adresu w jądrze dopasowuje prefiksy. Nie ma pojęcia, czym jest nazwa hosta, więc nie może podążać za usługą, która zmienia adresy. Reguła domeny rozwiązuje nazwy i routuje wynik; podąża za usługą, ale zależy od resolvera, zachowania odświeżania i obsługi subdomen przez klienta, więc regułę podążającą za nazwami trzeba testować z resolverem, którego klient naprawdę używa.

Żadna nie jest nadzbiorem drugiej, dlatego mieszanie ich bez notatki powoduje później zamieszanie.

Sprawdź ponownie po zmianie usługi

Po aktualizacji klienta lub zmianie usługi uruchom ponownie ten sam test sesji. Lista adresów, która wcześniej działała, jest dowodem na tamten okres, nie stałym inwentarzem infrastruktury usługi.

Zapisz, który mechanizm obejmuje którą nazwę hosta, oraz datę ostatniej weryfikacji.

Ta notatka to różnica między regułą, której możesz bronić, a regułą, której nikt nie ośmiela się dotknąć. Jeśli usługa publikuje własną listę prefiksów, użyj jej i podaj datę. Jeśli nie, powiedz to i trzymaj regułę domeny z jej zachowaniem odświeżania zapisanym obok.