LAN-hostnaam werkt niet via VPN: suffix, mDNS of zone?

Naast het apparaat antwoordt de printer op een korte naam en de fileserver op een bijnaam. Door de tunnel verlopen beide namen terwijl hun adressen nog werken. De route doet zijn werk; het naampad dat die korte namen liet werken, is nooit door de tunnel gegaan. Drie mechanismen veroorzaken dat gedrag, en elk ervan vraagt een andere correctie.

Begin met vast te stellen van welk mechanisme de naam afhangt.

Drie soorten namen die zich anders gedragen

Een naam met één label zoals fileserver leunt meestal op een DNS-zoeksuffix dat de resolver toevoegt. Dat suffix komt vaak mee met de lokale DHCP-lease, dus een externe client die adressering van de VPN krijgt, heeft geen reden om het te kennen. Een route toevoegen levert het suffix niet. De korte naam houdt simpelweg op te bestaan als naam, ook al is het adres erachter bereikbaar.

Een naam die op .local eindigt, wordt normaal opgelost via multicast-DNS op de lokale link, zoals RFC 6762 beschrijft. Multicast gaat niet door een gerouteerde tunnel tenzij iets die bewust overbrugt of proxyt, dus de naam houdt op met oplossen op het moment dat je het segment verlaat.

Een volledig gekwalificeerde bedrijfsnaam hoort bij een interne zone die door de resolvers van de organisatie wordt bediend. Die werkt op afstand wanneer de VPN die resolvers pusht en de client is geconfigureerd om ze te gebruiken. En localhost is volgens RFC 6761 voor speciaal gebruik: het verwijst naar de machine voor je, nooit naar een externe dienst.

Lees de resolver voordat je de route wijzigt

Vraag welke naamserver heeft geantwoord en welk suffix is toegevoegd. Dezelfde query via verschillende resolvers geeft verschillende antwoorden, en dat verschil is het bewijs dat je nodig hebt.

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

Als de volledig gekwalificeerde query wel oplost maar de korte niet, zit de fout in het suffix, niet in de server. Als geen van beide oplost en het adres werkt, gebruikt de client de interne resolver helemaal niet. Vergelijk de resolverlijst met wat de VPN hoort te pushen, want een client die zijn lokale resolver voor elke query houdt, zal de interne zone nooit zien.

Breng de juiste naam naar de client

Vraag de beheerder om de gedocumenteerde naam voor toegang op afstand, volledig, en gebruik die in het profiel in plaats van suffixen te raden. Als de uitrol split DNS ondersteunt, configureer dan het interne domein zodat het door de interne servers wordt opgelost terwijl al het andere de lokale resolver houdt. Push het zoekdomein via de VPN-configuratie waar de client dat ondersteunt.

Verifieer het resultaat op de client in plaats van op de gateway. Een instelling die op de server wordt toegepast en de client nooit bereikt, verandert niets.

Houd de identiteit van het certificaat intact

Een op adres gebaseerde test die de certificaatfout negeert, bewijst alleen dat de socket is geopend. Het certificaat van de dienst is uitgegeven voor een naam, en de client zal de afwijking met goede reden blijven weigeren. Als het certificaat alleen de interne naam vermeldt, gebruik die naam en herstel de resolutie, of haal een certificaat dat het adres dekt dat je wilt gebruiken.

Noteer de naam, de resolver en het suffix die een geslaagde verbinding opleverden. Die notitie bespaart de volgende persoon het herhalen van de op adres gebaseerde omweg die het echte probleem verbergt.