Nazwa hosta w LAN nie działa przez VPN: sufiks, mDNS czy strefa?

Obok urządzenia drukarka odpowiada na krótką nazwę, a serwer plików na pseudonim. Przez tunel obie nazwy wygasają, choć ich adresy nadal działają. Trasa robi swoje; ścieżka nazewnictwa, która sprawiała, że te krótkie nazwy działały, nigdy nie przekroczyła tunelu. Trzy mechanizmy powodują takie zachowanie i każdy wymaga innej poprawki.

Zacznij od ustalenia, od którego mechanizmu zależy nazwa.

Trzy rodzaje nazw, które zachowują się inaczej

Nazwa z jedną etykietą, taka jak fileserver, zwykle opiera się na sufiksie wyszukiwania DNS dodawanym przez resolver. Ten sufiks często przychodzi z lokalną dzierżawą DHCP, więc zdalny klient pobierający adresację z VPN nie ma powodu go znać. Dodanie trasy nie dostarcza sufiksu. Krótka nazwa po prostu przestaje istnieć jako nazwa, choć adres za nią jest osiągalny.

Nazwa kończąca się na .local jest zwykle rozwiązywana przez multicast DNS w łączu lokalnym, jak opisuje RFC 6762. Multicast nie przechodzi przez trasowany tunel, chyba że coś celowo go pomostuje lub proxuje, więc nazwa przestaje się rozwiązywać w chwili, gdy opuszczasz segment.

W pełni kwalifikowana nazwa firmowa należy do strefy wewnętrznej obsługiwanej przez resolvery organizacji. Ta działa zdalnie, gdy VPN wypycha te resolvery, a klient jest skonfigurowany, by ich używać. A localhost ma przeznaczenie specjalne według RFC 6761: odnosi się do maszyny przed tobą, nigdy do zdalnej usługi.

Przeczytaj resolver, zanim zmienisz trasę

Zapytaj, który serwer nazw odpowiedział i jaki sufiks został dołączony. To samo zapytanie przez różne resolvery daje różne odpowiedzi, a ta różnica jest dowodem, którego potrzebujesz.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Jeśli w pełni kwalifikowane zapytanie się rozwiązuje, a krótkie nie, usterka jest w sufiksie, nie w serwerze. Jeśli żadne się nie rozwiązuje, a adres działa, klient w ogóle nie używa wewnętrznego resolvera. Porównaj listę resolverów z tym, co VPN powinien wypychać, bo klient, który zachowuje swój lokalny resolver dla każdego zapytania, nigdy nie zobaczy strefy wewnętrznej.

Dostarcz właściwą nazwę do klienta

Poproś administratora o udokumentowaną nazwę dostępu zdalnego, w całości, i użyj jej w profilu zamiast zgadywać sufiksy. Jeśli wdrożenie obsługuje split DNS, skonfiguruj domenę wewnętrzną tak, aby rozwiązywały ją serwery wewnętrzne, podczas gdy wszystko inne zachowa lokalny resolver. Wypychaj domenę wyszukiwania przez konfigurację VPN tam, gdzie klient to obsługuje.

Sprawdź wynik na kliencie, a nie na bramie. Ustawienie zastosowane na serwerze, które nigdy nie dociera do klienta, niczego nie zmienia.

Zachowaj tożsamość certyfikatu

Test oparty na adresie, który ignoruje błąd certyfikatu, dowodzi tylko, że gniazdo zostało otwarte. Certyfikat usługi jest wystawiony dla nazwy, a klient będzie słusznie odrzucać niezgodność. Jeśli certyfikat wymienia tylko nazwę wewnętrzną, użyj tej nazwy i napraw rozwiązywanie, albo uzyskaj certyfikat obejmujący adres, którego zamierzasz używać.

Zapisz nazwę, resolver i sufiks, które dały udane połączenie. Ten zapis oszczędza następnej osobie powtarzania obejścia opartego na adresie, które ukrywa prawdziwy problem.