Krótkie nazwy wewnętrzne nie działają w VPN: sufiks, którego nigdy nie widzisz
Krótka nazwa działa tylko dlatego, że sufiks wyszukiwania ją uzupełnia. Porównaj nazwę pełną i krótką, aby odróżnić brak sufiksu od awarii resolvera.
Krótka nazwa działała w biurze, a w VPN zawodzi, podczas gdy pełna nazwa rozwiązuje się bez problemu. Nic nie jest zepsute. Goła nazwa, taka jak intranet, nie jest pełną nazwą; klient dołącza sufiks ze swojej listy wyszukiwania i pyta o wynik. Jeśli profil VPN nie dostarcza tego sufiksu, znana krótka forma przestaje istnieć.
To cały mit. DNS się nie zepsuł, zmieniła się polityka wyszukiwania.
Goła nazwa nie jest nazwą
Gdy wpisujesz jedną etykietę, resolver musi zdecydować, o co zapytać. Próbuje nazwy takiej, jak podano, a następnie dodaje wpisy z listy wyszukiwania po jednym, aż coś odpowie. W systemie Linux resolv.conf kontroluje tę kolejność ustawieniami search i ndots. W systemie Windows lista sufiksów i polityka rozwiązywania nazw robią to samo. Usuń sufiks, a resolver nie będzie miał czego dodać.
Działająca krótka nazwa jest więc dowodem polityki, a nie dowodem zdrowego serwera DNS.
Co robią lista sufiksów i adres resolvera
Te dwie rzeczy są stale mylone. Adres resolvera mówi, kogo zapytać; lista sufiksów mówi, o którą nazwę zapytać. VPN może dać prywatny resolver bez sufiksu albo sufiks z niewłaściwym resolverem. Tylko jedna z tych awarii wygląda jak awaria DNS.
Sprawdzaj je osobno, bo naprawianie niewłaściwej spala okno wsparcia.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Trzy objawy, trzech różnych właścicieli.
Najpierw przetestuj pełną nazwę
Poproś o udokumentowaną przez administratora pełną nazwę kwalifikowaną, a nie o domysł. Działający FQDN dowodzi, że resolver jest osiągalny i że rekord istnieje, co jednym zapytaniem usuwa połowę możliwych przyczyn. Użyj narzędzia, które pokazuje, który serwer odpowiedział, aby nie czytać wyniku z pamięci podręcznej.
Zachowaj test w prywatności. Wysyłanie wewnętrznych wariantów do publicznego resolvera ujawnia nazwy i testuje politykę, której nikt nie zamierzał.
Gdzie należy poprawka
Popraw profil właścicielski lub system zarządzania, który go generuje. Ręczna zmiana lokalnej konfiguracji resolvera zwykle znika przy ponownym połączeniu albo dotyczy każdej sieci, do której dołącza maszyna, co jest gorsze.
W systemie Windows sprawdź obowiązującą politykę, a nie pole wyboru, które pamiętasz. Get-DnsClientNrptPolicy pokazuje reguły rozwiązywania nazw, które naprawdę obowiązują.
W systemie macOS scutil --dns wypisuje konfigurację resolvera dla każdego interfejsu w zakresie, łącznie z domenami wyszukiwania wypchniętymi przez VPN.
W systemie Linux odczytaj wiersz search w /etc/resolv.conf, ale sprawdź, czy klient VPN go nie przepisał. Jeśli plik jest zarządzany, edytuj źródło prawdy, a nie plik wyrenderowany. Nieaktualny wiersz search pozostały po poprzedniej sieci to częsta przyczyna.
Co zachować razem z profilem
Zachowaj poprawioną pełną nazwę, listę sufiksów i adres resolvera obok profilu klienta. Następna osoba, która zgłosi, że witryna intranet nie działa, będzie mogła porównać trzy znane wartości zamiast zaczynać od pustej strony.
A jeśli zawodzi tylko krótka forma, napisz to w zgłoszeniu. To zdanie oszczędza zespołowi resolverów całe popołudnie.