Puncte:0

Sufixul DNS nu este utilizat cu numele de gazdă ale serverului Windows prin VPN

drapel it

Rețeaua noastră internă este un domeniu Windows, contoso.net. Pe plan intern, dacă un utilizator trebuie să ajungă la un server de fișiere partajat, poate naviga la \fileserver\share sau \fileserver.contoso.net\share și ambele se rezolvă fără probleme.

Am creat recent un VPN extern (Azure P2S) folosind IKEv2 care este configurat să utilizeze serverele noastre interne DNS, sufixul DNS contoso.net și este configurat pentru tunelarea divizată.

Adaptor PPP Contoso VPN - Tunel utilizator:

   Sufix DNS specific conexiunii . : contoso.net
   Descriere . . . . . . . . . . . : Contoso VPN - Tunelul utilizatorului
   Adresă fizică. . . . . . . . . :
   DHCP activat. . . . . . . . . . . : Nu
   Configurare automată activată. . . . : Da
   Adresa IPv4. . . . . . . . . . . : 172.31.1.131 (De preferat)
   Mască de rețea . . . . . . . . . . . : 255.255.255.255
   Gateway implicit . . . . . . . . . :
   Servere DNS. . . . . . . . . . . : 192.168.1.5
                                       192.168.1.6
   NetBIOS peste Tcpip. . . . . . . . : Activat

Prin VPN, utilizatorii pot folosi fqdn-ul serverelor ca înainte pentru navigare \fileserver.contoso.net dar nu pot folosi numele „necalificat”. \fileserver.

Am întâlnit o serie de postări și articole cu o situație similară, dar nu sunt sigur dacă folosesc „termenii” potriviți atunci când caut o soluție la această problemă. Din câte pot spune, această conexiune ar trebui să fie atașată sufixul specificat contoso.net automat la nume de gazdă necalificate, dar asta nu pare să se întâmple.

Folosind nslookup atât pe fqdn, cât și pe numele scurt, încerc să rezolv folosind DNS-ul meu ISP, cu excepția cazului în care specific serverul intern, caz în care ambele au succes.

Există o setare bazată pe registry sau GPO care îmi lipsește pentru a „forța” adăugarea automată a sufixului DNS specificat la numele de gazdă fără el?

ACTUALIZAȚI

Am schimbat valoarea de pe adaptorul de rețea VPN la „1”, iar acum nslookup folosește implicit serverele mele DNS interne, astfel încât atât numele scurte, cât și numele FQDN se rezolvă cu acel utilitar. Cu toate acestea, navigarea la numele scurt în exploratorul de fișiere ca și cum ar fi să acceseze o partajare de fișiere tot nu funcționează, ceea ce este în cele din urmă principala mea problemă.

Puncte:0
drapel cn

Dacă problema principală pentru moment este să rezolvi numele „necalificat”. \fileserver la adresa sa internă aveți trei opțiuni:

  1. Debifați Utilizați gateway-ul implicit în rețeaua de la distanță opțiunea în proprietățile conexiunii VPN.
  2. Utilizați o definiție pentru acel server în local LMHOSTS fișier pe computerul client.
  3. Utilizați un server WINS în rețeaua internă și utilizați-l prin conexiunea VPN.

Sper că aceste sugestii vă pot ajuta.

Puncte:0
drapel it

Am ajuns să identific problema ca fiind UseRasCredentials valoare în rasphone.pbk fişier.

Este implicit la o valoare de 1 ceea ce înseamnă să folosesc acreditările clientului VPN, care în acest caz a fost un certificat SCEPman și nu acreditările de domeniu.

Setarea valorii acestuia la 0 și repornind imediat rezoluția de nume fix VPN.

Credit la Richard Hicks pentru că m-ai ajutat să identific această problemă.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.