Որ կապն է պատասխանում. երթուղային դոմեններ split-tunnel VPN-ի DNS-ի համար

Պահեք սովորական դիտարկումը տեղական կապի վրա, մինչ ընկերության անունները լուծվում են թունելի տրամադրած DNS սերվերի միջոցով։ Անջատելով VPN-ի լռելյայն երթուղին՝ դուք ստանում եք առաջին կեսը և թողնում երկրորդը չկառուցված։ Հաջորդում են բացակայող կարգավորումը, կետադրությունը, որը փոխում է դրա իմաստը, և միակ հրամանը, որը ցույց է տալիս, թե որ կապն է իրականում պատասխանել։ Ողջ տեքստում ենթադրվում են NetworkManager-ը և systemd-resolved-ը, քանի որ հենց այդ զույգն է, որտեղ սովորաբար սկսվում է շփոթությունը։

Քայլ առաջին. առանձնացրեք երթուղին լուծիչից

ipv4.never-default-ը պատասխանում է երթուղային հարցին և թույլ չի տալիս NetworkManager-ին այս միացումը տեղադրել որպես ամբողջ IPv4 թրաֆիկի ուղի։ DNS-ի երթուղային դոմենը պատասխանում է մեկ այլ հարցի. որ կապի անվան սերվերներն են ստանում համապատասխան վերջածանցի հարցում։ Ոչ մեկը չի ենթադրում մյուսին, և պրոֆիլը կարող է տարիներ կրել մեկը՝ բացակայելով մյուսը։ Միայն երթուղին նշանակում է, որ թունելը կրում է ընկերության ենթացանցերը, և դրա լուծիչը պատասխանում է ընկերության անուններին, իսկ մնացած ամեն ինչ մնում է անփոփոխ։

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

Քայլ երկրորդ. ավելացրեք միայն-երթուղային դոմեն պրոֆիլին

Ենթադրենք՝ միացումը կոչվում է corp-vpn, ընկերության վերջածանցը internal.example-ն է, և թունելի լուծիչն արդեն հասանելի է։ Նախ կարդացեք ընթացիկ արժեքները, քանի որ ստորև բերված հրամանները փոխում են հատկություններ, որոնք կարող են արդեն գրառումներ ունենալ։

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

Սկզբի տիլդան նշում է միայն-երթուղային դոմեն, այնպես որ համապատասխան հարցումները գնում են այս կապի սերվերներին, և վերջածանցը չի ավելանում կարճ անուններին։ Հեռացրեք տիլդան, և նույն տողը նույնպես դառնում է որոնման վերջածանց, ինչը տարբեր արդյունք է, որը մարդիկ հազվադեպ են նկատի ունենում։ Վերևի երկու կարգավորումներն էլ IPv4 են, ուստի երկկույտ պրոֆիլին անհրաժեշտ են ipv6.never-default և նույն երթուղային դոմենը ipv6.dns-search-ում, հակառակ դեպքում IPv6 կողմը շարունակում է օգտագործել լռելյայն երթուղին, և ներքին անունները այնտեղ ձախողվում են։

Քայլ երրորդ. resolvectl-ից հարցրեք, թե որ կապն է պատասխանել

Գործարկեք resolvectl status-ը և կարդացեք յուրաքանչյուր կապի DNS սերվերներն ու դոմենները, ապա գործարկեք resolvectl query host.internal.example-ը իրական ներքին անվան դեմ, որը ձեզ թույլատրված է հարցնել։ Երկրորդ հրամանը միակ ուղղակի ապացույցն է, որ երթուղային դոմենն անում է իր գործը, քանի որ այն նշում է պատասխանած կապը։ Միայն կարգավիճակի ցանկը վկայում է կազմաձևումը. հարցումը վկայում է լուծումը։

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

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

Քայլ չորրորդ. երբ անունը լուծվում է, բայց ծառայությունը՝ ոչ

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

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

Քայլ հինգերորդ. մի փոխարինեք լուծիչը բացակայող դոմենը շտկելու համար

Խորհուրդը, որը վերագրում է լուծիչի ֆայլը կամ տեղադրում է այլ լուծիչի կառավարիչ, լուծում է այլ խնդիր։ Դրանք համակարգի ինտեգրման փոփոխություններ են իրենց խափանման ռեժիմներով, և դրանցից ոչ մեկը չի ավելացնում երթուղային դոմեն, որը երբեք չի կազմաձևվել։ Որոշեք, թե որ բաղադրիչն է տիրապետում անվան լուծմանը մեքենայի վրա նախքան այն փոխարինելը, քանի որ systemd-resolved-ով NetworkManager աշխատասեղանին այդ սեփականությունն արդեն սահմանված է։ Դրա դեմ պայքարելը հենց այն է, թե ինչպես աշխատող կարգավորումը դառնում է մի բան, որը ոչ ոք չի կարող կրկնել։

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