Wêrom't in servernamme nei dial-in nei syn VPN-adres oplost

In kantoarblêdserver antwurdet de hiele moarns op syn LAN-adres, dan skillet in ôfstânsbrûker yn en begjint de namme ynstee nei in tunneladres op te lossen. Der is neat mei de hân yn DNS bewurke, en dat is de oanwizing: it record waard troch de masine sels publisearre. Trije betingen beslisse oft jo de registrator, it record of de werjefte fan 'e klant reparearje, en ferkearde folchoarder betsjut dat it record nei de folgjende ferbining weromkomt.

Twa adressen, ien namme, trije betingen

In Windows-server mei meardere interfaces kin in LAN-adres, ien of mear dial-in-adressen en soms in twadde netwurkkaart hawwe. Eltse interface kin syn eigen adressen yn DNS registrearje as dynamyske registraasje dêrfoar tastien is. As de PPP-adapter him registrearret, krijt deselde hostnamme in adres dêr't allinnich de tunnelpartner by komme kin, en LAN-klanten krije it as in jildich antwurd.

Trije betingen beslisse de reparaasje. Earst, is it ekstra adres berikber fan 'e klanten dy't it krije? Twad, is der noch in konsumint dy't fan dy registraasje ôfhinklik is? Tred, is it record dynamysk en dus by steat om werom te kommen, of statysk en dus in bewuste yngong?

Beäntwurdzje dat foardat jo eat oanreitsje. As it adres net berikber is fan it netwurk dat de fraach docht, helpt gjin ien kear klantcache leegje foar lang. As der wat fan ôfhinklik is, lykas in behearspaad dat de tunnelpartners sels brûke, brekt it fuortheljen dat paad ynstee. En in dynamysk record dat wiske wurdt sûnder de publisist oan te pakken, ferskynt by de folgjende registraasjegebaris wer.

Lês it record foardat jo de registrator feroarje

Freegje de krekte folsleine kwalifisearre namme op út it netwurk dat it probleem rapportearret, en fergelykje de antwurden mei de echte interfaces en harkers fan 'e server. Ien namme dy't ferskate adressen weromjout is normaal; de fraach is oft elk derfan brûkber is foar de klant dy't it krijt.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

De earste fraach brûkt de lokale oplosser, de twadde freget streekrjocht oan in beskaat DNS-server en de tredde docht itselde fan PowerShell op Windows. It fergelykjen fan dy trije skiedt in ferâldere klantcache fan in autoritatyf antwurd. As de direkte fraach al it tunneladres weromjout, is it probleem publisearre gegevens en net lokale caching.

Skriuw de tiidstempel fan it record op en oft de DNS-konsole it as dynamysk toant. Dat iene attribút fertelt jo hokker fan 'e trije betingen hjirboppe jildt, en it is it ferskil tusken in opromming fan fiif minuten en in reparaasje dy't hâldt.

Reparearje de publisist of it record, mar wyt hokker

As it record dynamysk en net winske is, is de duorsume reparaasje tefoarren komme dat dy interface him registrearret. Windows biedt registraasje-ynstellingen per interface, en de DNS-klantsjinst publisearret wer by de folgjende ferbining of adresferoaring. Registraasje foar de dial-in-adapter útskeakelje lit de registraasje fan 'e LAN-adapter ûnoantaast, wat meastentiids is wat jo wolle.

Wês foarsichtich mei skakelaars foar de hiele masine. In globale ynstelling dy't dynamyske bywurking útskeakelt, hat ynfloed op eltse interface op dy host, ek dejinge waans registraasje oare klanten fertrouwe. Op in domeinkontrôler jildt deselde foarsichtigens mei mear krêft, om't de host ek tsjinstlokaasje-records besitte kin dêr't klanten foar oanmelding fan ôfhinklik binne.

As it record statysk is, is it der mei opsetsin pleatst en it petear is mei wa't it pleatst hat. In statysk record wiskje om't it hjoed ûnhandich is, ferwideret it iennige bewiis fan wêrom't it bestiet. Yn beide gefallen wiskje it ferâldere antwurd pas neidat de publisist oanpakt is, en skriuw op wat jo feroare hawwe sadat de folgjende persoan in bewuste yngong fan in ûngelok skiede kin.

Ferifiearje fan it klantnetwurk dat mislearre

Ferifikaasje heart by it netwurk dat it symptoom rapportearre, net by de server. Meitsje de cache fan 'e klantoplosser leech fia syn stipe meganisme, en werhelje dan de oarspronklike opfrege en de oarspronklike tsjinstferbining by namme.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

It earste kommando meitset de Windows-oplossercache leech, en it twadde toant oft de namme wer yn 'e cache sit en hokker adres opslein is. In slagge ferbining fan 'e server nei himsels bewiist neat oer in LAN-klant, en it fuortheljen fan in rûte nei it net winske adres korrizjearret net wat DNS publisearret.

Werhelje úteinlik de barrens dy't it adres earder yntrodusearre: ferbynje de VPN-klant opnij of fernij de dial-in-sesje. Kontrolearje it publisearre namme nochris nei dy libbenssyklusferoaring. In reparaasje dy't allinnich oant de folgjende ferbining hâldt, wie in opromming, net in reparaasje, en witte hokker fan 'e beide jo dienen is it ferskil tusken it ticket sluten en it folgjende wike wer iepenjen.