Prywatny DNS działa w VPC, ale nie przez VPN
Prywatna nazwa, która rozwiązuje się w EC2, ale nie przez VPN, to problem ścieżki resolvera. Przeczytaj kształt awarii, zanim zmienisz rekord strefy.
Prywatna nazwa rozwiązuje się z instancji EC2, ale nie z laptopa połączonego przez VPN, a strefa wygląda poprawnie w konsoli. Odruch każe edytować rekord, co prawie nigdy nie jest problemem. Rekord odpowiada komuś; po prostu nie odpowiada twojemu laptopowi. To, co różni obu wywołujących, to który resolver pytają i czy ten resolver ma obsługiwaną ścieżkę do widoku DNS w VPC.
Zaczynam od udowodnienia, że rekord istnieje, a resztę czasu poświęcam ścieżce zapytania. To osobne systemy i zawodzą w różny sposób.
Przeczytaj kształt awarii, zanim cokolwiek zmienisz
Trzy wyniki oznaczają trzy różne rzeczy, a jedno zapytanie je rozróżnia: uruchom dig dla nazwy względem resolvera, którego klient faktycznie używa.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Przekroczenie czasu to stwierdzenie o sieci. NXDOMAIN to stwierdzenie o widoku DNS. Publiczna odpowiedź to stwierdzenie o polityce. Edycja rekordu strefy, gdy trwa przekroczenie czasu, wyrzuca jedyny użyteczny dowód w sprawie.
Dlaczego adres plus dwa w VPC nie jest zdalnym resolverem
Adres CIDR plus dwa to usługa lokalna dla zasobów wewnątrz VPC. AWS dokumentuje, że przekazywanie zapytań z sieci lokalnych albo z serwerów DNS innego VPC bezpośrednio na ten adres nie jest obsługiwane i może dawać niestabilne wyniki.
To nie znaczy, że eksperyment nigdy nie wydaje się działać. To znaczy, że zachowanie nie jest kontraktem, który można wpisać w skrypt pomocy technicznej. Obsługiwany kierunek to przychodzący punkt końcowy Resolver: para adresów wewnątrz twojego VPC, osiągalna z sieci, którą kontrolujesz, przyjmująca zapytania przychodzące spoza AWS.
Zbuduj ścieżkę w kolejności, w której zawodzi czysto
Muszą istnieć trzy przeskoki, a każdy ma własny sposób zawodzenia.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesPrzekazywacz potrzebuje trasy do adresów punktu końcowego przez VPN, a ścieżka powrotna też musi działać. Dla klasycznego DNS na porcie 53 punkt końcowy odpowiada przez UDP i TCP, więc oba protokoły muszą być dozwolone i oba muszą przetrwać każdą inspekcję stanową po drodze.
Potem sprawdź osobno widok DNS. Prywatna strefa hostowana jest widoczna tylko dla VPC, z którymi jest powiązana, albo przez świadomą umowę udostępniania. Osiągalny punkt końcowy sam z siebie nie czyni każdej prywatnej strefy rozwiązywalnej w jej kontekście rozwiązywania.
Punkt końcowy wychodzący obsługuje przeciwny kierunek i nie odpowie na zapytanie przychodzące z twojego laptopa.
Sprawdź z obu stron
Zapytaj z klienta do przekazywacza, a potem z przekazywacza do punktu końcowego. Jeśli klient zawodzi, a przekazywacz działa, luka jest między tymi dwoma.
Jeśli oba zawodzą, przyjrzyj się polityce bezpieczeństwa punktu końcowego i adresowi źródłowemu, który on faktycznie widzi. Przekazywacz za NAT przedstawia adres NAT zamiast adresu VPN laptopa, i sama ta różnica wystarcza, by odrzucić zapytanie. Jeśli oba działają, a aplikacja nadal zawodzi, możliwe, że aplikacja używa innego resolvera niż ten, który testowałeś.
Trzymaj publiczne i prywatne przestrzenie nazw celowo osobno. Split DNS to polityka, którą konfigurujesz, a nie efekt uboczny tego, że jedno zapytanie przypadkiem zwróciło dane.
Czego bym nie zrobił
Nie dodałbym reguły NAT, która sprawiła, że jedno zapytanie zadziałało, i nie nazwałbym tego projektem.
Nie skierowałbym każdego zdalnego klienta na adres plus dwa tylko dlatego, że jeden test raz zwrócił rekord. I nie rozszerzyłbym polityki bezpieczeństwa punktu końcowego na całą pulę VPN, gdy dostęp potrzebny jest jednemu przekazywaczowi. Jeśli organizacja już prowadzi zatwierdzony przekazywacz wewnątrz VPC, przeczytaj najpierw ten projekt, bo drugi punkt końcowy, który dodasz, jest tym, którego nikt nie dokumentuje.