Бөлінген туннель маршруттары қабаттасқанда: қай префикс жеңеді

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

1. Межені және бастауды жазып алыңыз

Сәтсіз сұрау баратын нақты мекенжайдан бастаңыз, хост атынан емес және қолданба атынан емес. Атауды бір рет шешіңіз, әр жауапты жазып алыңыз және сәтсіз ағын шынымен қолданатын жауапты таңдаңыз. Содан кейін сол ағынның жергілікті мекенжайын жазып алыңыз, өйткені бастау мекенжайы қай саясат ережесінің сәйкес келетінін және сол арқылы қай кестеге қаралатынын өзгертуі мүмкін.

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

2. Ядродан қай маршрутты таңдағанын сұраңыз

Маршруттар кестесін оқып, жауапты болжамаңыз. Стек қоятын сұрақтың өзін сол бастау мекенжайымен қойыңыз: Linux-та ip route get 10.20.4.10 from 10.8.0.2 немесе PowerShell-де Find-NetRoute -RemoteIPAddress 10.20.4.10. Шығыс шынымен қолданылатын маршрутты атайды, және ол кестені оқығанда күткеніңізден жиі өзгеше болады.

Сәйкес келетін маршруттардың ішінде әдетте нақтырақ префикс жеңеді: екеуінің ішінде жатқан мекенжай үшін /24 /16-дан басым. Ұзындығы бірдей сәйкестіктер арасында төменірек метрика жеңеді, ал өшірілген байланысқа орнатылған маршрут өткізіліп жіберіледі. Бірдей /24-ті бірдей метрикамен тарататын екі туннель басқа жағдай: ядро екі маршрутты да сақтайды және олардың арасынан таңдайды, сондықтан нәтиже клиенттердің қосылу тәртібін бағындырмай, кезектесіп өзгеруі мүмкін. Дәл осы жағдай дүйсенбіде-жұмыс-істейді-сейсенбіде-істен-шығады үлгісін тудырады, және басқа тәртіппен қайта қосылу оны өзгертпейді.

3. Саясат ережесі іздеуді басқа жаққа бұрды ма, соны тексеріңіз

Маршруттар кестесіне қарамас бұрын ядро өзінің саясат ережелерінен өтеді. Ереже белгілі бір бастаудан, пайдаланушыдан немесе өрт қабырғасы белгісінен келетін трафикті мүлдем басқа кестеге жібере алады, сондықтан негізгі кестедегі жеңетін префикс сол ағын үшін ешқашан қаралмауы мүмкін. ip rule show оларды бағалау ретімен тізіп береді, ал ip route show table 100 таңдалған кестеде шынымен не бар екенін көрсетеді.

Мұнда екі тұзақ бар. Бос кестеге сілтейтін ереже келесі ережеге құлайтын іздеу тудырады, сондықтан ереже ештеңе істемейтін сияқты көрінеді. Екіншісі — басымдық нөмірінің өзі: ережелер өсу ретімен оқылады, ал кірістірілген мәндер 0 local, 32766 main және 32767 default болып табылады. Нөмірі 32767-ден төмен ереже бәрін ұстайтын әдепкі ережеден бұрын қаралады. Нөмірі 32767-ден жоғары ереже оның артында тұрады және оған тек бұрынғы ешбір кесте жауап бермегенде ғана жетеді, бұған main-дегі қалыпты әдепкі маршрут кедергі жасайды, сондықтан іс жүзінде оған ешқашан жетпейді және орнатылған болып көрінгенімен үнсіз ештеңе істемейді. Егер клиент ереже мен маршрутты жазса, екеуін де тексеріңіз және қайта қосылғаннан кейін тағы тексеріңіз, өйткені қайта жазылған профиль басқа басымдықпен екінші ереже қосуы мүмкін.

4. Маршруттық теңдікті қайталанған мекенжай жоспарынан ажыратыңыз

Кейде префикс мүлдем мәселе емес. Екі орынның екеуі де 192.168.1.0/24 қолданса, бұл бір мекенжай екі түрлі хостты білдіреді және ешбір маршрут оларды ажырата алмайды. Екі жауаптың біріне арналған хост маршруты екінші орын сол атауға жауап бергенше ғана жұмыс істейді, содан кейін ерекшелік үнсіз ақауға айналады.

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

5. Шешушінің маршрутпен келісетінін растаңыз

Дұрыс емес жеке мекенжайға шешілетін атау маршруттау қақтығысының барлық симптомдарын тудырады және оның бірде-бір себебін тудырмайды. Хост алатын жауапты меже шынымен қолданатын мекенжаймен салыстырыңыз және қай шешуші жауап бергенін тексеріңіз. Егер туннель шешушіні итермелесе, клиент оны туннельді қолданатын ағындар үшін орнатуы керек; егер олай болмаса, хост жергілікті шешушіден сұрауды жалғастырады, ол іздеу доменінен немесе кэштелген жазбадан жауап беруі мүмкін.

Шешушіден тікелей сұраңыз және жауап берген серверді жазып алыңыз. Қысқа TTL-мен кэштелген жауап қайта қосылғаннан кейінгі бірінші сұраудың бесіншіден несімен өзгеше болатынын да түсіндіре алады.

6. Қайта қосылыңыз, қолданылған күйді қарап шығыңыз, содан кейін екі ағынды да сынап көріңіз

Түзетуден кейін қайта қосылыңыз және профиль редакторына сенудің орнына клиенттің шынымен нені орнатқанын қарап шығыңыз. Ережелерді, кестелерді және одан шығатын ip route get жауабын қайта оқыңыз. Екінші клиент қосылу кезінде өз маршрутын қайта орнатып, қақтығысты қайта жасауы мүмкін, сондықтан күй тексерісі соңғы клиент қосылғаннан кейін жасалуы керек, оған дейін емес.

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