Туннель қосулы, сонда неге жеке атау әлі де сәтсіз?

Жұмыс істеп тұрған туннель клиент дұрыс шешушіден сұрады дегенді білдірмейді. Қайсысы жауап бергенін тексеріңіз, содан кейін тек қажет аймақты ғана жіберіңіз.

Қосылымның барлығы дұрыс көрінеді: туннель қосулы және консоль жеке соңғы нүктені көрсетеді, бірақ әр сұрау атауларды шешуде сәтсіз аяқталады. Табиғи әрекет — туннельді кінәлау, ол әдетте кінәсіз болып шығады. Сұрау жеке аймақ туралы ештеңе білмейтін серверге жіберіледі. Ешбір маршрут өзгерісі бұл жауапты өзгертпейді, себебі мәселе кімнен сұралғанында.

Сұрау қай шешушіге жетті?

Туннельге қарамас бұрын әр біріктіруге тіркелген шешушіні табыңыз. Linux әр біріктірудің серверлерін шешуші күйі командасымен көрсетеді, ал macOS DNS конфигурациясының шығарылымында ауқымды шешушілерді көрсетеді. Егер жауап әлі де үй маршрутизаторынан келсе, туннель біріктіруі ешқашан сұралмаған.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Мұнда екі кезең араласады: шешуші мекенжайын итеретін сервер және оны белсенді біріктіруге орнататын клиент. Профильде параметр болуы мүмкін және журнал оның келуін көрсетуі мүмкін, ал операциялық жүйе ескі серверді пайдалануды жалғастырады. Журналды біріктіру хабарлағанмен салыстырыңыз және біріктіруге сеніңіз.

Бұлттық желі шынымен жауап беретін мекенжайды пайдаланыңыз

Бұлттық желілер жеке атауларға әдетте ауқым негізінен екі позиция әрі тұрған резервтелген мекенжай арқылы жауап береді, сондықтан 10.0.0.0-ден басталатын желі 10.0.0.2-де жауап береді. Кейбір провайдерлер ауқымды білмей-ақ жұмыс істейтін жергілікті шешушіні де жариялайды, бұл желіні басқа біреу құрғанда көмектеседі. Кандидат мекенжайды біреуге итермес бұрын одан тікелей сұраңыз. Шешуші болып табылмайтын мекенжай өрт қабырғасының тастауына дәл ұқсайды, өйткені сұрау ешқашан жауап алмайды.

Егер тікелей сұрау желінің ішінен жауап беріп, туннель арқылы бермесе, шешуші дұрыс, ал екі нүкте арасындағы жол дұрыс емес. Бұл нәтиже тергеуді клиент профиліне емес, маршруттарға, қайта жіберуге және рұқсат ережелеріне ауыстырады.

Туннель атау кеңістігін тасымалдамайды

Пакеттер өтеді; атаулар өтпейді. Әр тарапқа қай атау кеңістігі екіншісіне тиесілі екенін айту керек, және бұл аймақты ұстаған адамға тиесілі жеке нысан. Кәдімгі нысан — бір атау кеңістігі үшін туннель арқылы қолжетімді шешушіге бағытталған қайта жіберу.

Іс жүзінде әр бағытқа өз ережесі керек, өйткені аймақты иеленетін тарап сұрауды әрі жіберуі керек. Екі бағыт та сұрау көзін маршруттауды және рұқсат етуді талап етеді, ал жауап беретін тарап жауаптарды интернетке емес, туннель арқылы қайтаруы керек. Қайта жіберуді тар ұстаңыз, сонда тек жеке атау кеңістігі біріктіруге тәуелді болады. Әр сұрауды ол арқылы жіберу кішкене тәуелділікті туннель құлаған сәтте толық үзіліске айналдырады.

Шекараларды ретімен өтіңіз

Белсенді біріктіруге орнатылған шешушіні, содан кейін сол шешушіге тікелей сұрауды, содан кейін сол сұрауды алыс жақтан, соңында сол атауды пайдаланатын қолданбаны сынаңыз. Әр қадам бір шекараны оқшаулайды, сондықтан сәтсіздік тергеуді қайта бастаудың орнына қайда қарау керектігін айтады. Қолданба сәтсіз болғанда жұмыс істейтін жауап DNS-ке емес, сертификат сеніміне немесе API саясатына нұсқайды. Бұл ақаулар нақты және ешбір шешуші өзгерісі оларды түзетпейді.

Қай қадам сәтсіз болғанын жазыңыз. Сол бір жол — келесі адамға керек нәрсе, және оны жазу он секунд алады.

Шынжырды келесі адам табатын жерде ұстаңыз

Итерілген шешушіні, қайта жіберу ережесін, рұқсат етілген сұрау көзін және жауап беретін соңғы нүктені бір жерге жазыңыз. Жеке атау қайта сәтсіз болғанда, жазба туннель жылжыды ма, шешуші мекенжайы өзгерді ме әлде ереже тарылды ма соны көрсетеді. Онсыз әр оқиға нөлден басталып, сол үш болжаммен аяқталады.

Жазбаны дәл болып қалуы үшін жеткілікті қысқа ұстаңыз: төрт жол, күн және әр бөліктің иесінің аты. Ескірген жазба жоғынан жаман, өйткені ол қате болса да беделді көрінеді.

Қатысты мақалалар