Fout 868 met een IP-adres? Wat Windows eerst opzoekt

De dialoog meldt dat de servernaam niet kon worden opgelost, en het profielveld waar je naar staart is een adres. Die combinatie is geen tegenspraak: de client lost iets anders op dan de waarde waarvan je denkt dat hij die leest. Zoek uit waar hij werkelijk naartoe belt voordat je concludeert dat DNS stuk is. De volgorde van de eigen stappen van de client laat je zien waar je moet kijken.

De client lost een naam op voordat hij belt

Een native Windows-VPN-verbinding leest het profiel, lost het serveradres op, start de tunnel en verifieert pas daarna. Fout 868 hoort bij de tweede stap. Omdat de latere stappen nooit lopen, kan de dialoog op een inlogprobleem lijken terwijl de opzoeking als eerste mislukte.

Die volgorde is nuttig, want ze vernauwt de laag die je moet onderzoeken. Als hetzelfde profiel vanuit het ene netwerk werkt en vanuit het andere mislukt, is het verschil meestal naamresolutie en niet het tunneltype of het account. Test de opzoeking waar de fout optreedt, niet waar het profiel is gemaakt.

Welke naam, als het veld een adres toont

Lees de opgeslagen waarde in plaats van de weergavenaam. Het label van een verbinding is niet het serveradres, en twee vermeldingen met vergelijkbare labels sturen je achter de verkeerde aan:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

Als het profiel voor alle gebruikers is ingericht, bevraag dan ook die scope met -AllUserConnection. Los vervolgens precies de waarde op die de opdracht heeft afgedrukt, vanaf het netwerk waar de fout optreedt. Gebruik de gedocumenteerde gateway van de provider, niet de interne applicatienaam die pas wordt opgelost als de tunnel staat. Die tweede query mislukt om een verwachte reden en zegt je niets over het bellen:

Resolve-DnsName vpn.example.com

Als de opgeslagen waarde echt numeriek is, zoek dan een tweede plek waar de client een naam leest. Een EAP-configuratie kan naar een server verwijzen, een profiel dat uit een ander hulpmiddel is geïmporteerd kan zijn eigen waarde dragen, en een eerdere installer kan een dubbele vermelding achterlaten. Het veld in de dialoog is niet altijd de enige invoer.

Het herverbindingspatroon van Windows 7

De thread achter deze fout beschrijft machines die één keer verbonden en daarna bij een latere poging faalden met 868, zonder dat er iets in het profiel veranderde. Bijdragers meldden dat het herstarten van de service Remote Access Connection Manager of uit- en weer inloggen de verbinding tijdelijk herstelde. Dat zijn omwegen, geen aangetoonde grondoorzaak.

Behandel dat patroon als een aparte hypothese. Een herstart reset de clientstatus, dus een tijdelijk succes daarna bewijst niet dat de DNS-record fout was:

Lees de tabel als een reeks onderscheidende observaties, niet als een diagnose. De eerste rij is een naamprobleem, de tweede clientstatus en de derde een profiel dat nooit juist was. Elk leidt tot een andere persoon en een andere oplossing.

Wat je voor de beheerder moet verzamelen

Noteer de profielnaam, het opgeslagen adres, het tunneltype, het netwerk waarop de client zat en of de fout na een verbreking kwam. Dat verslag scheidt een echte opzoekfout van het historische herverbindingsgedrag zonder dat iemand hoeft te gissen. Bewaar ook het gebeurtenislog van de client rond de poging.

De omweg uit oudere builds is bewijs dat het gedrag bestond, geen belofte dat dezelfde herstart van de service een huidige machine repareert. Een gedocumenteerde hostnaam vervangen door een letterlijk adres is ook geen reparatie.

Sommige profielen verwachten een serveridentiteit die bij de geconfigureerde naam past, dus een numerieke omweg kan de ene fout voor de andere ruilen. Als de naam moet blijven, repareer dan het resolutiepad en niet de profieltekst. Noteer hoe dan ook wat je hebt gewijzigd en waarom.