VPN naam DNS oer en briek lokale nammen: reparearje de list

De tunnel komt omheech, it intranet laden en de namme fan 'e printer hâldt op mei oplossen. Of oarsom: lokale nammen wurkje noch wylst alles yn it bedriuwsnetwurk ferrint. Beide symptomen komme fan itselde plak, in list fan resolvers dy't de VPN-klient wer skreau doe't er ferbûn.

Reparearje de list bewust en behannelje dêrnei it push-meganisme apart. Rûtes binne in tredde ûnderwerp en net dat wat hjir reparearre wurdt.

Hokker list applikaasjes eins brûke

Windows lost op fia ynstellings op ynterfacenivo en net fia wat in dialooch docht, sadat jo begjinne mei de effektive listen per ynterface. De alias is wichtiger as de werjûn namme, omdat elk kommando hjirûnder him ta in ynterface rjochtet. Ferkeard alias en de reparaasje lânet op 'e ferkearde adapter. It sil lykje te wurkjen oant de folgjende werferbining, as de eigen ynfier fan 'e tunnel weromkomt.

De fraach is hokker servers foaroan kamen en oft se as statyske ynfier of as DHCP-hierder oankamen. Beide feiten beslisse hokker reparaasje jo beskikber is.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lês de útfier foar de tunneladapter en foar de fysike, en notearje elk adres op elk. In statyske ynfier kin troch belied of skript fuorthelle wurde; in troch DHCP levere ynfier is oan 'e hierder bûn en komt werom, wat de reparaasje feroaret dy't jo kieze moatte. Nammen yn it fiere netwurk wurde troch de oankundige resolver oplost, nammen op it lokale LAN troch de fysike adapter, en de fraach giet nei de list dy't earst rieplachte wurdt.

Ferwiderje de pushte servers, of set se leger

Wiskje de pushte servers as neat yn 'e tunnel se nedich hat, omdat de eigen resolvers fan 'e fysike adapter wer oernimme. Hâld se allinne as it fiere netwurk sônes hat dêr't allinne syn servers antwurd op jaan kinne, en set yn dat gefal in lokale resolver foar se. De twa kommando's hjirûnder dekke beide karren, kies dus dyjinge dy't by de situaasje past ynstee fan beide.

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

Yndeks 1 wurdt earst rieplachte, sadat de pushte adressen beskikber bliuwe mar net mear it standertantwurd op elke fraach binne. De flagge validate=no slacht in berikberensproef oer dy't faak mislearret wylst de tunnel noch setelt, befêstigje it resultaat dus mei it kommando show ynstee fan op 'e útgongskoad te fertrouwen.

Twa grinzen binne wittensweardich foardat jo hjir op fertrouwe. Windows wisket gjin servers dy't oer DHCP fia netsh kamen, en dy wearden bliuwe as DhcpNameServer ûnder de registerkaai fan 'e ynterface, sadat in registerwiziging in lêste útwei is dy't nei de folgjende hierder op 'e nij kontrolearre wurde moat. Ek de biningsoarder fan adapters is gjin betrouber rangearringsmechanisme, omdat in VPN-klient syn eigen ynfier boppe-oan de list ynfoegje kin.

Wêr't de push filtere wurde kin

In bettere reparaasje hellet de opsje fuort foardat dy tapast wurdt. De Community OpenVPN-klient kin in pusht rjochtlin by namme filterje, wat de konfiguraasje fan 'e server ûnoantaat lit.

pull-filter ignore "dhcp-option DNS "

De spaasje oan 'e ein heart by de oerienkomst en it filter neamt de opsje, net in serveradres. As it profyl ek in rjochtlin block-outside-dns befettet, feroaret it fuortheljen dêrfan lekbeskerming, net namme-oplossing, beslút dat dus apart ynstee fan de twa bewurkings te bondeljen.

Foar ien koppige hostnamme is ien rigel yn it Windows hosts-triemdbestân stiger as it op 'e nij oarderjen fan resolvers foar de hiele masine. It is ek ûnsichtber foar de folgjende persoan, notearje it dus dêr't de konfiguraasje fan 'e masine dokumintearre wurdt.

Meitsje de reparaasje in werferbining oerlibje

Namme-oplossing moat twa kear test wurde, ien kear tsjin in keazen server en ien kear yn 'e foarm dy't in applikaasje brûkt. Dat pear skiedt in resolver-oarderprobleem fan in server dy't hielendal net antwurdet. It earste test oerslaan lit de twa oarsaken ferstrûpe.

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

Ferbin de tunnel op 'e nij en werhelje beide kommando's. Wat jo mei de hân feroare hawwe, hâldt allinne oant de folgjende ferbining, omdat de klient syn resolverstân wer opbouwt wylst er de adapter omheech bringt. Set de rigels netsh yn it stipe ferbiningsskript fan jo klient, lit dat skript mei súkses einigje en foegje in koarte wachttiid ta foardat it rint. In klient dy't DNS nei it skript tapast, oerskriuwt it resultaat dochs.

As publike nammen oplosse en ynterne nei de reparaasje noch mislearje, is de resolverslist net mear de fertochte. De fraach berikt de server wierskynlik hielendal net, wat op rûtes of in firewallregel wiist en net op noch in DNS-ynstelling. Notearje de alias fan 'e ynterface en de adressen dêr't jo op útkaam binne, omdat beide tusken masines ferskille en gjinien allinne in weropbou oerlibbet.