LAN-isäntänimi ei toimi VPN:n yli: suffiksi, mDNS vai vyöhyke?
Lyhyt nimi voi nojata hakusuffiksiin, .local-nimi multicastiin ja yrityksen nimi yksityiseen vyöhykkeeseen. Pelkkä reitti ei tarjoa mitään nimipalvelua.
Laitteen vieressä tulostin vastaa lyhyeen nimeen ja tiedostopalvelin lempinimeen. Tunnelista molemmat nimet vanhenevat, vaikka niiden osoitteet toimivat edelleen. Reitti tekee tehtävänsä; nimipolku, joka sai nuo lyhyet nimet toimimaan, ei koskaan ylittänyt tunnelia. Kolme mekanismia tuottaa tämän käyttäytymisen, ja jokainen niistä vaatii erilaisen korjauksen.
Aloita selvittämällä, mistä mekanismista nimi riippuu.
Kolme eri tavalla käyttäytyvää nimeä
Yhden tunnisteen nimi, kuten fileserver, nojaa yleensä DNS-hakusuffiksiin, jonka resolveri lisää. Tämä suffiksi tulee usein paikallisen DHCP-vuokrasopimuksen mukana, joten VPN:ltä osoitteen saavalla etäasiakkaalla ei ole mitään syytä tuntea sitä. Reitin lisääminen ei toimita suffiksia. Lyhyt nimi yksinkertaisesti lakkaa olemasta nimenä, vaikka sen takana oleva osoite on tavoitettavissa.
Nimi, joka päättyy .local, selvitetään yleensä multicast-DNS:llä paikallisessa linkissä, kuten RFC 6762 kuvaa. Multicast ei ylitä reititettyä tunnelia, ellei jokin tarkoituksella sillata tai välitä sitä, joten nimi lakkaa selvittämästä heti, kun poistut segmentistä.
Täysin kvalifioitu yrityksen nimi kuuluu sisäiseen vyöhykkeeseen, jota organisaation resolverit palvelevat. Se toimii etänä, kun VPN työntää nämä resolverit ja asiakas on määritetty käyttämään niitä. Ja localhost on RFC 6761:n mukaan erityiskäyttöön tarkoitettu: se viittaa edessäsi olevaan koneeseen, ei koskaan etäpalveluun.
Lue resolveri ennen kuin muutat reittiä
Kysy, mikä nimipalvelin vastasi ja mikä suffiksi lisättiin. Sama kysely eri resolvereiden kautta antaa erilaisia vastauksia, ja tämä ero on se todiste, jonka tarvitset.
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
Jos täysin kvalifioitu kysely selvittää mutta lyhyt ei, vika on suffiksissa, ei palvelimessa. Jos kumpikaan ei selvittä ja osoite toimii, asiakas ei käytä sisäistä resolveria lainkaan. Vertaa resolveriluetteloa siihen, mitä VPN:n pitäisi työntää, sillä asiakas, joka pitää paikallisen resolverinsa jokaisessa kyselyssä, ei koskaan näe sisäistä vyöhykettä.
Tuo oikea nimi asiakkaalle
Pyydä ylläpitäjältä dokumentoitu etäkäyttönimi kokonaisuudessaan ja käytä sitä profiilissa sen sijaan, että arvaisit suffikseja. Jos käyttöönotto tukee split DNS:ää, määritä sisäinen toimialue sisäisten palvelimien selvitettäväksi, kun kaikki muu säilyttää paikallisen resolverin. Työnnä hakutoimialue VPN-määrityksen kautta siellä, missä asiakas tukee sitä.
Vahvista tulos asiakkaalla eikä yhdyskäytävällä. Palvelimelle sovitettu asetus, joka ei koskaan saavuta asiakasta, ei muuta mitään.
Säilytä varmenteen identiteetti ehjänä
Osoitteeseen perustuva testi, joka jättää varmenteen virheen huomiotta, todistaa vain, että socket avattiin. Palvelun varmenne on myönnetty nimelle, ja asiakas jatkaa eroavuuden hylkäämistä hyvästä syystä. Jos varmenne luettelee vain sisäisen nimen, käytä tuota nimeä ja korjaa selvitys, tai hanki varmenne, joka kattaa käyttää aikomasi osoitteen.
Kirjaa nimi, resolveri ja suffiksi, jotka johtivat onnistuneeseen yhteyteen. Tämä kirjaus säästää seuraavan henkilön toistamasta osoitteeseen perustuvaa kiertotietä, joka kätkee varsinaisen ongelman.