VPNak DNSa bereganatu eta tokiko izenak hautsi zituen: konpondu zerrenda

Tunela altxatzen da, intraneta kargatzen da, eta inprimagailuaren izenak ebazteari uzten dio. Edo alderantziz: tokiko izenek oraindik funtzionatzen dute enpresa sarearen barruan dena iraungitzen den bitartean. Bi sintomak toki beretik datoz, VPN bezeroak konektatzean berridatzitako resolutzaile zerrenda batetik.

Konpondu zerrenda nahita, eta gero landu push mekanismoa bereizita. Ibilbideak hirugarren gai bat dira, eta ez da hemen konpontzen dena.

Zein zerrenda erabiltzen dute aplikazioek benetan

Windowsek interfaze mailako ezarpenen bidez ebazten du, eta ez edozein elkarrizketa-koadrok erakusten duenaren bidez, beraz hasi interfaze bakoitzeko zerrenda eraginkorrekin. Aliasak garrantzi handiagoa du erakutsitako izenak baino, beheko komando bakoitzak interfaze bati zuzentzen baitzaio. Aliasa gaizki hartzen baduzu, konponketak adapter okerrean lurreratuko du. Funtzionatzen duela emango du hurrengo berriz konektatu arte, tuneleko sarrera propioa itzultzen denean.

Galdera da zein zerbitzarik amaitu zuten aurrealdean, eta ea sarrera estatiko gisa edo DHCP errentamendu gisa iritsi ziren. Bi egitateek erabakitzen dute zein konponketa duzun eskuragarri.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Irakurri irteera tunelaren adapterrerako eta fisikoarentzako, eta idatzi bakoitzean dagoen helbide bakoitza. Sarrera estatikoa politika edo script baten bidez ken daiteke; DHCP bidezkoa errentamenduari lotuta dago eta itzuliko da, eta horrek hautatu behar duzun konponketa aldatzen du. Urruneko sareko izenak iragarritako resolutzaileak ebazten ditu, tokiko LANeko izenak adapter fisikoak, eta kontsulta lehenengo kontsultatzen den zerrendara doaz.

Kendu bultzatutako zerbitzariak edo jarri beherago

Ezabatu bultzatutako zerbitzariak tuneleko ezerk behar ez dituenean, adapter fisikoaren resolutzaile propioek berriro hartzen baitute ardura. Mantendu itzazu urruneko sareak bere zerbitzariek soilik erantzun ditzaketen eremuak baditu, eta kasu horretan jarri tokiko resolutzaile bat haien aurretik. Beheko bi komandoek bi aukerak estaltzen dituzte, beraz hautatu egoerari dagokiona, biak exekutatu ordez.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

1 indizea kontsultatzen da lehenengo, beraz bultzatutako helbideak eskuragarri jarraitzen dute baina kontsulta bakoitzeko erantzun lehenetsia izateari uzten diote. validate=no banderak sarritan huts egiten duen irisgarritasun proba bat saltatzen du tuneleko egoera finkatu bitartean, beraz berretsi emaitza show komandoarekin, irteera-kodean fidatu ordez.

Bi muga ezagutzea merezi du honetan fidatu aurretik. Windowsek ez ditu ezabatuko DHCP bidez netsh zehar iritsitako zerbitzariak, eta balio horiek DhcpNameServer gisa irauten dute interfazearen erregistro gakoaren azpian, beraz erregistroaren aldaketa azken baliabidea da eta hurrengo errentamenduaren ondoren berriro egiaztatu behar da. Adapterren lotura ordena ere ez da sailkapen mekanismo fidagarria, VPN bezero batek bere sarrera zerrendaren goialdean txerta baitezake.

Non iragaz daitekeen push-a

Konponketa hobe batek aukera kentzen du aplikatu aurretik. Community OpenVPN bezeroak bultzatutako direktiba bat izenez iragaz dezake, eta horrek zerbitzariaren konfigurazioa ukitu gabe uzten du.

pull-filter ignore "dhcp-option DNS "

Amaierako zuriunea bat-etortzearena da eta iragazkiak aukera izendatzen du, ez zerbitzari helbide bat. Profilak block-outside-dns direktiba ere badu, haren kentzeak ihesen aurkako babesa aldatzen du, ez izenen ebazpena, beraz erabaki hori bereizita, bi aldaketak bateratu ordez.

Ostinatu temati bakarrerako, Windowseko hosts fitxategiko lerro batek sendoagoa da makina osorako resolutzaileak berrordenatzea baino. Hurrengo pertsonarentzat ikusezina ere bada, beraz idatzi han, makinaren konfigurazioa dokumentatzen den lekuan.

Egin konponketak berriz konektatzea gaindi dezan

Ebazpena birritan probatu behar da, behin hautatutako zerbitzari baten aurka eta behin aplikazio batek erabiltzen duen forman. Bikote horrek resolutzaileen ordena arazoa eta batere erantzuten ez duen zerbitzaria bereizten ditu. Lehen proba saltzeak bi kausak nahasita uzten ditu.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Konektatu tunela berriro eta errepikatu bi komandoak. Eskuz aldatu duzunak hurrengo konexiora arte baino ez du irauten, bezeroak bere resolutzaile egoera berreraikitzen baitu adapterra altxatzean. Jarri netsh lerroak zure bezeroaren konexio script onartuan, utzi script horri arrakastaz amaitzen, eta gehitu itxaronaldi labur bat exekutatu aurretik. Scriptaren ondoren DNS aplikatzen duen bezero batek emaitza gainidatziko du edozein kasutan.

Izen publikoak ebazten badira eta barnekoek konponketaren ondoren huts egiten badute, resolutzaile zerrenda ez da susmagarria jada. Kontsultak seguruenik ez dio zerbitzariari batere iristen, eta horrek bideratze edo suebaki arau batera eramaten gaitu, ez beste DNS ezarpen batera. Idatzi interfazearen aliasa eta erabaki zenituen helbideak, biak makinen artean desberdinak baitira eta batek ere ez baitu berreraikitze bat gainditzen bere kasa.