Ինչու է սերվերի անունը հավաքումից հետո լուծվում նրա VPN հասցեով

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

Երկու հասցե, մեկ անուն, երեք պայման

Բազմաինտերֆեյս Windows սերվերը կարող է ունենալ LAN հասցե, մեկ կամ մի քանի հավաքման հասցե և երբեմն երկրորդ ցանցային քարտ։ Յուրաքանչյուր ինտերֆեյս կարող է գրանցել իր հասցեները DNS-ում, եթե նրա համար թույլատրված է դինամիկ գրանցում։ Երբ PPP ադապտերը գրանցվում է, նույն հոսթի անունը ստանում է հասցե, որին կարող է հասնել միայն թունելի գործընկերը, և LAN հաճախորդները ստանում են այն որպես վավեր պատասխան։

Վերանորոգումը որոշում են երեք պայման։ Առաջին՝ արդյո՞ք լրացուցիչ հասցեն հասանելի է այն հաճախորդներից, որոնք ստանում են այն Երկրորդ՝ արդյո՞ք որևէ սպառող դեռ կախված է այդ գրանցումից Երրորդ՝ արդյո՞ք գրառումը դինամիկ է և հետևաբար կարող է վերադառնալ, թե ստատիկ է և հետևաբար դիտավորյալ գրառում

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

Կարդացեք գրառումը նախքան գրանցողին փոխելը

Հարցրեք ճշգրիտ ամբողջական որակավորված անունը այն ցանցից, որը հաղորդում է խնդրի մասին, և համեմատեք պատասխանները սերվերի իրական ինտերֆեյսների և լսողների հետ։ Մեկ անվան կողմից մի քանի հասցե վերադարձնելը նորմալ է, հարցն այն է, թե արդյոք դրանցից յուրաքանչյուրը օգտագործելի է այն ստացող հաճախորդի համար։

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

Առաջին հարցումն օգտագործում է տեղական լուծիչը, երկրորդը ուղղակիորեն հարցնում է կոնկրետ DNS սերվերի, իսկ երրորդը նույնն անում է PowerShell-ից Windows-ում։ Դրանց համեմատությունը առանձնացնում է հնացած հաճախորդի քեշը հեղինակավոր պատասխանից։ Եթե ուղղակի հարցումն արդեն վերադարձնում է թունելի հասցեն, խնդիրը հրապարակված տվյալների մեջ է, այլ ոչ թե տեղական քեշավորման։

Գրեք գրառման ժամանակի դրոշմը և այն, թե արդյոք DNS վահանակը ցույց է տալիս այն որպես դինամիկ։ Այդ մեկ հատկանիշը ձեզ ասում է, թե վերը նշված երեք պայմաններից որն է կիրառելի, և դա հինգ րոպեանոց մաքրման ու տևական վերանորոգման տարբերությունն է։

Ուղղեք հրապարակողին կամ գրառումը, բայց իմացեք որը

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

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

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

Ստուգեք այն հաճախորդի ցանցից, որը ձախողվել է

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

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

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

Վերջապես, կրկնեք այն իրադարձությունը, որը նախկինում ներմուծում էր հասցեն՝ նորից միացրեք VPN հաճախորդին կամ թարմացրեք հավաքման նստաշրջանը։ Ստուգեք հրապարակված անունը կրկին այդ կենսացիկլի փոփոխությունից հետո։ Վերանորոգումը, որը պահպանվում է միայն մինչև հաջորդ միացումը, մաքրում էր, ոչ թե վերանորոգում, և իմանալը, թե որն եք կատարել, տոմսը փակելու և այն հաջորդ շաբաթ նորից բացելու տարբերությունն է։