Numele de gazdă din LAN eșuează prin VPN: sufix, mDNS sau zonă?

Lângă dispozitiv, imprimanta răspunde la un nume scurt, iar serverul de fișiere la o poreclă. Prin tunel, ambele nume expiră în timp ce adresele lor încă funcționează. Ruta își face treaba; calea de numire care făcea acele nume scurte să funcționeze nu a traversat niciodată tunelul. Trei mecanisme produc acest comportament și fiecare necesită o corecție diferită.

Începeți prin a stabili de care mecanism depinde numele.

Trei tipuri de nume care se comportă diferit

Un nume cu o singură etichetă precum fileserver se bazează de obicei pe un sufix de căutare DNS adăugat de resolver. Acel sufix vine adesea cu închirierea DHCP locală, așa că un client la distanță care obține adresare de la VPN nu are niciun motiv să îl cunoască. Adăugarea unei rute nu livrează sufixul. Numele scurt pur și simplu încetează să existe ca nume, deși adresa din spatele lui este accesibilă.

Un nume care se termină în .local este de obicei rezolvat prin DNS multicast pe legătura locală, așa cum descrie RFC 6762. Multicast nu traversează un tunel rutat decât dacă ceva îl puntează sau îl proxează în mod deliberat, așa că numele încetează să se rezolve în momentul în care părăsiți segmentul.

Un nume de companie complet calificat aparține unei zone interne deservite de resolverele organizației. Acela funcționează de la distanță când VPN-ul împinge acele resolveruri și clientul este configurat să le folosească. Iar localhost este de uz special conform RFC 6761: se referă la mașina din fața dumneavoastră, niciodată la un serviciu la distanță.

Citiți resolverul înainte de a schimba ruta

Întrebați ce server de nume a răspuns și ce sufix a fost adăugat. Aceeași interogare prin resolvere diferite dă răspunsuri diferite, iar acea diferență este dovada de care aveți nevoie.

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

Dacă interogarea complet calificată se rezolvă dar cea scurtă nu, defecțiunea este în sufix, nu în server. Dacă niciuna nu se rezolvă și adresa funcționează, clientul nu folosește deloc resolverul intern. Comparați lista de resolvere cu ceea ce ar trebui să împingă VPN-ul, deoarece un client care își păstrează resolverul local pentru fiecare interogare nu va vedea niciodată zona internă.

Aduceți numele corect la client

Cereți administratorului numele documentat de acces la distanță, complet, și folosiți-l în profil în loc să ghiciți sufixe. Dacă implementarea acceptă split DNS, configurați domeniul intern pentru a fi rezolvat de serverele interne în timp ce tot restul păstrează resolverul local. Împingeți domeniul de căutare prin configurația VPN unde clientul îl acceptă.

Verificați rezultatul pe client, nu pe gateway. O setare aplicată pe server care nu ajunge niciodată la client nu schimbă nimic.

Păstrați intactă identitatea certificatului

Un test bazat pe adresă care ignoră eroarea certificatului dovedește doar că socketul s-a deschis. Certificatul serviciului este emis pentru un nume, iar clientul va continua să respingă nepotrivirea pe bună dreptate. Dacă certificatul listează doar numele intern, folosiți acel nume și corectați rezolvarea, sau obțineți un certificat care acoperă adresa pe care intenționați să o folosiți.

Notați numele, resolverul și sufixul care au produs o conexiune reușită. Acea notă scutește următoarea persoană de a repeta ocolirea bazată pe adresă care ascunde problema reală.