LAN-ի հոսթի անունը VPN-ով չի աշխատում՝ վերջածանց, mDNS թե՞ գոտի։

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

Սկսեք պարզելով, թե անունը որ մեխանիզմից է կախված։

Անունների երեք տեսակ, որոնք տարբեր կերպ են վարվում

Մեկ պիտակով անունը, ինչպիսին է fileserver-ը, սովորաբար հենվում է DNS որոնման վերջածանցի վրա, որը ավելացնում է լուծիչը։ Այդ վերջածանցը հաճախ գալիս է տեղական DHCP վարձակալության հետ, ուստի VPN-ից հասցեավորում ստացող հեռավոր հաճախորդը պատճառ չունի այն իմանալու։ Երթուղի ավելացնելը վերջածանցը չի հասցնում։ Կարճ անունը պարզապես դադարում է անուն լինելուց, թեև դրա հետևում եղած հասցեն հասանելի է։

.local-ով ավարտվող անունը սովորաբար լուծվում է multicast DNS-ով տեղական կապում, ինչպես նկարագրում է RFC 6762-ը։ Multicast-ը չի անցնում երթուղավորված թունելով, եթե ինչ-որ բան դիտավորյալ չկամրջի կամ չփրոքսի այն, ուստի անունը դադարում է լուծվել այն պահին, երբ լքում եք սեգմենտը։

Լիովին որակավորված ընկերության անունը պատկանում է ներքին գոտու, որը սպասարկում են կազմակերպության լուծիչները։ Այն աշխատում է հեռվից, երբ VPN-ը մղում է այդ լուծիչներին, և հաճախորդը կարգավորված է դրանք օգտագործելու։ Իսկ localhost հատուկ օգտագործման է ըստ RFC 6761-ի. այն վերաբերում է ձեր առջևի մեքենային, երբեք հեռավոր ծառայության։

Կարդացեք լուծիչը նախքան երթուղին փոխելը

Հարցրեք, թե որ անվան սերվերն է պատասխանել և որ վերջածանցն է ավելացվել։ Նույն հարցումը տարբեր լուծիչների միջոցով տալիս է տարբեր պատասխաններ, և այդ տարբերությունն այն ապացույցն է, որ ձեզ պետք է։

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

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

Բերեք ճիշտ անունը հաճախորդին

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

Ստուգեք արդյունքը հաճախորդի վրա, ոչ թե դարպասի։ Սերվերի վրա կիրառված կարգավորումը, որը երբեք չի հասնում հաճախորդին, ոչինչ չի փոխում։

Պահեք վկայագրի ինքնությունը անփոփոխ

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

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