LAN resursdatora nosaukums nedarbojas caur VPN: sufikss, mDNS vai zona?
Īss nosaukums var balstīties uz meklēšanas sufiksi, .local nosaukums uz multicast, bet uzņēmuma nosaukums uz privātu zonu. Tikai maršruts nesniedz nekādu nosaukumu pakalpojumu.
Blakus ierīcei printeris atbild uz īsu nosaukumu, bet failu serveris uz iesauku. Caur tuneli abi nosaukumi beidzas ar taimautu, kamēr to adreses joprojām darbojas. Maršruts dara savu darbu; nosaukumu ceļš, kas lika šiem īsajiem nosaukumiem darboties, tuneli nekad nešķērsoja. Šo uzvedību rada trīs mehānismi, un katram nepieciešams cits labojums.
Sāciet ar to, no kura mehānisma nosaukums ir atkarīgs.
Trīs nosaukumu veidi, kas uzvedas atšķirīgi
Viena apzīmējuma nosaukums, piemēram, fileserver, parasti balstās uz DNS meklēšanas sufiksi, ko pievieno risinātājs. Šis sufikss bieži nāk kopā ar vietējo DHCP nomu, tāpēc attālinātam klientam, kas saņem adresāciju no VPN, nav pamata to zināt. Maršruta pievienošana sufiksi nepiegādā. Īsais nosaukums vienkārši pārstāj pastāvēt kā nosaukums, lai gan adrese aiz tā ir sasniedzama.
Nosaukums, kas beidzas ar .local, parasti tiek atrisināts ar multicast DNS vietējā saitē, kā apraksta RFC 6762. Multicast nešķērso maršrutētu tuneli, ja vien kaut kas to apzināti nesavieno tiltā vai neproksē, tāpēc nosaukums pārstāj risināties tajā brīdī, kad pametat segmentu.
Pilnībā kvalificēts uzņēmuma nosaukums pieder iekšējai zonai, kuru apkalpo organizācijas risinātāji. Tas darbojas attālināti, kad VPN virza šos risinātājus un klients ir konfigurēts tos izmantot. Un localhost saskaņā ar RFC 6761 ir īpaša lietojuma: tas attiecas uz mašīnu jūsu priekšā, nekad uz attālinātu pakalpojumu.
Izlasiet risinātāju pirms maršruta maiņas
Jautājiet, kurš nosaukumu serveris atbildēja un kurš sufikss tika pievienots. Viens un tas pats vaicājums caur dažādiem risinātājiem dod dažādas atbildes, un šī atšķirība ir jums nepieciešamais pierādījums.
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
Ja pilnībā kvalificētais vaicājums tiek atrisināts, bet īsais ne, kļūme ir sufiksā, nevis serverī. Ja neviens netiek atrisināts un adrese darbojas, klients vispār neizmanto iekšējo risinātāju. Salīdziniet risinātāju sarakstu ar to, ko VPN būtu jāvirza, jo klients, kas katram vaicājumam patur savu vietējo risinātāju, nekad neredzēs iekšējo zonu.
Nogādājiet pareizo nosaukumu klientam
Palūdziet administratoram dokumentēto attālinātās piekļuves nosaukumu pilnībā un izmantojiet to profilā, nevis miniet sufiksus. Ja izvietojums atbalsta split DNS, konfigurējiet iekšējo domēnu, lai to atrisinātu iekšējie serveri, kamēr viss pārējais saglabā vietējo risinātāju. Virziet meklēšanas domēnu caur VPN konfigurāciju tur, kur klients to atbalsta.
Pārbaudiet rezultātu klientā, nevis vārtejā. Serverī piemērots iestatījums, kas nekad nesasniedz klientu, neko nemaina.
Saglabājiet sertifikāta identitāti neskartu
Uz adresi balstīts tests, kas ignorē sertifikāta kļūdu, pierāda tikai to, ka ligzda tika atvērta. Pakalpojuma sertifikāts tiek izsniegts nosaukumam, un klients turpinās pamatoti atteikties no neatbilstības. Ja sertifikātā norādīts tikai iekšējais nosaukums, izmantojiet šo nosaukumu un izlabojiet risināšanu, vai iegūstiet sertifikātu, kas aptver adresi, kuru plānojat izmantot.
Pierakstiet nosaukumu, risinātāju un sufiksi, kas deva veiksmīgu savienojumu. Šis ieraksts ietaupa nākamajam cilvēkam atkārtot uz adresi balstīto apiešanu, kas slēpj īsto problēmu.