VPN-ը զավթեց DNS-ը և կոտրեց տեղական անունները. ուղղեք ցանկը

Թունելը բարձրանում է, ինտրանեթը բեռնվում է, և տպիչի անունը դադարում է լուծվել։ Կամ հակառակը՝ տեղական անունները դեռ աշխատում են, մինչ կորպորատիվ ցանցի ներսում ամեն ինչ ժամկետանց է դառնում։ Երկու ախտանիշներն էլ գալիս են նույն տեղից՝ լուծիչների ցանկից, որը VPN հաճախորդը վերագրել էր միանալիս։

Ուղղեք ցանկը դիտավորյալ, ապա push մեխանիզմով առանձին զբաղվեք։ Երթուղիները երրորդ թեման են և ոչ այն, ինչ այստեղ ուղղվում է։

Որ ցանկն են իրականում օգտագործում հավելվածները

Windows-ը լուծում է միջերեսի մակարդակի կարգավորումներով, ոչ թե նրանով, ինչ ցույց է տալիս որևէ երկխոսություն, այնպես որ սկսեք յուրաքանչյուր միջերեսի արդյունավետ ցանկերից։ Ալիասն ավելի կարևոր է, քան ցուցադրվող անունը, որովհետև ներքևի յուրաքանչյուր հրաման դիմում է միջերեսին։ Սխալ ալիասի դեպքում ուղղումը կհայտնվի սխալ ադապտերի վրա։ Թվում է, թե աշխատում է մինչև հաջորդ վերամիացումը, երբ թունելի սեփական գրառումը վերադառնա։

Հարցն այն է, թե որ սերվերներն առաջ անցան, և արդյոք դրանք եկան որպես ստատիկ գրառումներ, թե որպես DHCP վարձակալություն։ Երկու փաստերն էլ որոշում են, թե որ ուղղումն է ձեզ հասանելի։

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Կարդացեք ելքը թունելի ադապտերի և ֆիզիկական ադապտերի համար և նշեք յուրաքանչյուր հասցեն դրանցից յուրաքանչյուրի վրա։ Ստատիկ գրառումը կարելի է հեռացնել քաղաքականությամբ կամ սկրիպտով. DHCP-ով տրված գրառումը կապված է վարձակալության հետ և կվերադառնա, ինչը փոխում է ձեր ընտրելիք ուղղումը։ Հեռավոր ցանցի անունները լուծում է հայտարարված լուծիչը, տեղական LAN-ի անունները՝ ֆիզիկական ադապտերը, իսկ հարցումը գնում է այն ցանկին, որն առաջինն է դիտարկվում։

Հեռացրեք մղված սերվերները կամ դասավորեք դրանք ավելի ցածր

Ջնջեք մղված սերվերները, երբ թունելի ներսում ոչինչ դրանց կարիքը չունի, որովհետև ֆիզիկական ադապտերի սեփական լուծիչները նորից ստանձնում են։ Պահեք դրանք միայն եթե հեռավոր ցանցն ունի գոտիներ, որոնց պատասխանը միայն նրա սերվերները կարող են տալ, և այդ դեպքում դրեք տեղական լուծիչ դրանցից առաջ։ Ներքևի երկու հրամանները ծածկում են երկու ընտրությունները, այնպես որ ընտրեք իրավիճակին համապատասխանը երկուսն էլ գործարկելու փոխարեն։

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-ին ինդեքսն առաջինն է դիտարկվում, ուստի մղված հասցեները մնում են հասանելի, բայց դադարում են լինել յուրաքանչյուր հարցման լռելյայն պատասխանը։ validate=no դրոշը բաց է թողնում հասանելիության ստուգում, որը հաճախ ձախողվում է, քանի դեռ թունելը դեռ կայունանում է, ուստի հաստատեք արդյունքը show հրամանով՝ ելքի կոդին վստահելու փոխարեն։

Երկու սահմանափակում արժե իմանալ նախքան դրա վրա հենվելը։ Windows-ը չի ջնջի սերվերները, որոնք եկել են DHCP-ով netsh-ի միջոցով, և այդ արժեքները մնում են որպես DhcpNameServer միջերեսի գրանցամատյանի բանալու տակ, ուստի գրանցամատյանի խմբագրումը վերջին միջոցն է, որը պետք է նորից ստուգվի հաջորդ վարձակալությունից հետո։ Ադապտերների կապակցման կարգը նույնպես հուսալի դասակարգման մեխանիզմ չէ, որովհետև VPN հաճախորդը կարող է իր գրառումը տեղադրել ցանկի գլխին։

Որտեղ կարելի է զտել push-ը

Ավելի լավ ուղղումը հեռացնում է տարբերակը նախքան այն կիրառվելը։ Community OpenVPN հաճախորդը կարող է զտել մղված հրահանգը անունով, ինչը թողնում է սերվերի կարգավորումը անձեռնմխելի։

pull-filter ignore "dhcp-option DNS "

Վերջի բացատը պատկանում է համապատասխանությանը և զտիչը անվանում է տարբերակը, ոչ թե սերվերի հասցե։ Եթե պրոֆիլը պարունակում է նաև block-outside-dns հրահանգ, ապա դրա հեռացումը փոխում է արտահոսքի պաշտպանությունը, ոչ թե անվան լուծումը, ուստի դա որոշեք առանձին՝ երկու խմբագրումները միավորելու փոխարեն։

Մեկ համառ հոսթ անվան համար Windows hosts ֆայլում մեկ տողն ավելի կայուն է, քան ամբողջ մեքենայի լուծիչները վերադասավորելը։ Այն նաև անտեսանելի է հաջորդ մարդու համար, ուստի գրանցեք այն այնտեղ, որտեղ փաստաթղթավորվում է մեքենայի կարգավորումը։

Դարձրեք ուղղումը վերամիացման դիմացկուն

Անվան լուծումը պետք է փորձարկել երկու անգամ, մեկ անգամ ընտրված սերվերի դեմ և մեկ անգամ այն ձևով, որն օգտագործում է հավելվածը։ Այդ զույգը բաժանում է լուծիչների կարգի խնդիրը սերվերից, որը բոլորովին չի պատասխանում։ Առաջին փորձարկումը բաց թողնելը թողնում է երկու պատճառները խճճված։

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

Նորից միացրեք թունելը և կրկնեք երկու հրամանները։ Այն, ինչ ձեռքով փոխել եք, պահպանվում է միայն մինչև հաջորդ միացումը, որովհետև հաճախորդը վերակառուցում է իր լուծիչների վիճակը՝ ադապտերը բարձրացնելիս։ Տեղադրեք netsh տողերը ձեր հաճախորդի աջակցվող միացման սկրիպտում, թողեք այդ սկրիպտն ավարտվի հաջողությամբ, և ավելացրեք կարճ սպասում նախքան այն կաշխատի։ Այն հաճախորդը, որը DNS-ը կիրառում է սկրիպտից հետո, ամեն դեպքում կվերագրի արդյունքը։

Եթե հանրային անունները լուծվում են, իսկ ներքինները ուղղումից հետո դեռ ձախողվում են, լուծիչների ցանկն այլևս կասկածյալը չէ։ Հարցումը հավանաբար ընդհանրապես չի հասնում սերվերին, ինչը մատնանշում է երթուղավորում կամ firewall կանոն, ոչ թե DNS-ի մեկ այլ կարգավորում։ Գրանցեք միջերեսի ալիասը և այն հասցեները, որոնց վրա կանգ առաք, որովհետև երկուսն էլ տարբերվում են մեքենաների միջև, և ոչ մեկը ինքնուրույն չի դիմանում վերակառուցմանը։