resolvectl шығысынан әрбір байланыс үшін VPN DNS маршруттауын қалай оқу керек
resolvectl status әр байланыс үшін серверлерді, домендерді және әдепкі маршрутты көрсетеді. Оларды бірге оқыңыз, содан кейін атауды сұрап, қай байланыс жауап бергенін белгілеңіз.
resolvectl status іске қосыңыз және әр байланыс үшін блоктар қабырғасын аласыз, әрқайсысының өз серверлері мен өз домен жолы бар. Маршруттауды шешетін жол — домендер тізімі, ат серверінің мекенжайы емес, өйткені жергілікті stub әр сұранысты атауды талап ететін байланысқа жібереді. Жауапты оқымас бұрын осы талаптарды оқыңыз, содан кейін атауды сұрап, оны қай байланыс жасағанын тексеріңіз. Дұрыс байланыстан қате жауап қате байланыстан дұрыс жауаптан өзге мәселе.
Әр байланыс блогы сізге не айтады
Әр блок шешуші сол интерфейс үшін қолданатын серверлерді, домендер тізімін және байланыстың әдепкі маршрут екенін тізімдейді. Домендер тізімі — талаптар жиыны, ал шешуші ең ұзын жұрнақтың сәйкестігін қолданады: host.corp.example-ке сұранысты corp.example бар байланыс тек әдепкі маршрутты бар байланыстан бұрын талап етеді. Бір жұрнақты талап ететін екі байланыс нәтижені басымдық пен ретке қалдырады, сондықтан көшірмелер бірінші кезекте назарға лайық. Ағымдағы сервер жолы тізімделген серверлердің қайсысы сол сәтте қолданылып жатқанын көрсетеді.
/etc/resolv.conf ішіндегі 127.0.0.53 сияқты stub мекенжайы тек stub алда екенін айтады. Ол жауап берген жоғарғы ағынды атамайды, сондықтан тек resolv.conf-қа сүйенген диагностика тұрып қалады.
Домен жазбасының үш түрін дұрыс оқыңыз
| Жазба | Нені талап етеді | Жиі кездесетін қате |
|---|---|---|
| corp.example | маршруттау домені және іздеу жұрнағы: оның астындағы атаулар осы байланысқа барады және жол жалаң атауларға қосылады | жойылған, өйткені маршруттау бәрібір жұмыс істеп тұрғандай көрінеді |
| ~corp.example | тек маршрут: оның астындағы атаулар осы байланысқа барады, бірақ жұрнақ қосылмайды | маршруттау үшін қажет деп болжанған |
| ~. | әдепкі маршрут: ешбір басқа байланыс қамтымайтын сұраныстарды талап етеді | бөлінген профильде белсенді қалдырылған, сондықтан жария атаулар туннельді ұстанады |
Тильда іздеу мінез-құлқын өзгертеді, маршруттауды емес. Тильдасыз жазба — маршруттау домені де, іздеу домені де, сондықтан оның астындағы атаулар сол байланысқа жіберіледі және бір белгілі атауларға жұрнақ қосылады. Тильдалы жазба сол жұрнақты маршруттайды, бірақ оны іздеу тізімінен тыс ұстайды. Сондықтан тильданы алып тастау қай жалаң атаулардың шешілетінін өзгертеді және сондықтан тильданың жоқтығы бөлінген DNS ақауы емес, іздеу мәселесі.
Әдепкі маршрут жазбасы басқа ешбір байланыс қамтымайтынның бәрін талап етеді. Толық туннель профилі әдетте оны қалайды, ал бөлінген профиль әдетте қаламайды, өйткені жария атаулар сонда жеке шешушіге барады және сонда сәтсіз болуы мүмкін. Кестені профильдер арасында жалаушаларды көшірудің орнына профиль ниетіне қарсы оқыңыз. Екі байланыс бір жұрнақты талап етсе, басқа нәрсені өңдеуден бұрын басымдық мәселесін шешіңіз.
Атауды сұрап, қай байланыс жауап бергенін көріңіз
query қосымша командасы мекенжайды, хаттаманы және жауапты жасаған байланысты немесе аяны басып шығарады. Жеке жұрнақ талап етуі тиіс бір атауды және бір қарапайым жария атауды сынап көріңіз, содан кейін хабарланған көздерді салыстырыңыз. Егер жеке атау сымсыз байланыстан жауап берсе, талап жоқ немесе туннель өшкен; егер бөлінген профильде жария атау туннельден жауап берсе, әдепкі маршрут тым кең. Бұл екі ақау браузерде бірдей, ал бұл шығыста керісінше көрінеді.
resolvectl status
resolvectl query host.corp.exampleХабарланған хаттамаға да назар аударыңыз, өйткені кэштен немесе hosts файлынан жауап ешбір жоғарғы ағынды сұрамай-ақ келуі мүмкін. Кэштен келген жауап атаудың бір кезде шешілгенін дәлелдейді, ал ағымдағы саясаттың оны дұрыс маршруттайтынын емес.
Атауларды маршруттауды пакеттерді маршруттаудан бөлек ұстаңыз
Шешушінің шешімі жол жасамайды. Таңдалған серверге әлі де өз мекенжайына маршрут керек, ал қайтарылған мекенжайға әлі де жеке желіге маршрут керек, сондықтан дұрыс DNS саясаты ешқашан ашылмайтын қосылыммен қатар өмір сүре алады. Атау шешіліп, қолданба сәтсіз болса, DNS-ті қайта өзгертудің орнына мекенжай мен маршрутты тексеріңіз. Атауларды шешу және қолжетімділік — екі түрлі иесі бар екі сұрақ.
Қолданбалар жүйелік шешушіні өздерінің қауіпсіз DNS параметрі немесе кіріктірілген шешуші арқылы толығымен айналып өте алады. resolvectl нәтижесі жүйе жолын сипаттайды, ал оны елемейтін браузер сіз жасаған әрбір тестке қайшы келеді. Саясат бұзылды деп қорытынды жасамас бұрын сол параметрді тексеріңіз.
Атау шешілген мекенжайды байланыспен қатар жазып алыңыз. Қате мекенжайға нұсқайтын дұрыс атау — маршруттау емес, жазба мәселесі.
Байланыс өзгергеннен кейін қайта тексеріңіз
Қайта қосылу немесе сымсыз желінің ауысуы байланыс күйін қайта құрады, ал желі менеджері қолмен орнатылғанның бәрінің үстінен өз домендері мен серверлерін қайта орнатуы мүмкін. Содан кейін сол екі атауды сұрап, жазылған базалық сызықпен салыстырыңыз. Егер қолмен жасалған өзгеріс жоғалса, түзету қосылым профилінде болуы керек shell командасында емес. Алдын және кейін жазып алу мұны көрнекі етеді.
Есепке қажет атаулар мен сервер контекстін ғана бөлісіңіз, өйткені ішкі жұрнақтар топологияны ашады. Домендерді маршруттау туралы systemd-resolved құжаттамасы ең ұзын сәйкестік ережесін және тильда мінез-құлқын қамтиды, ал бір рет оқу жоғарыдағы кесте қателерінің көбін болдырмайды: systemd-resolved ішіндегі сұраныстарды маршруттау.