Жауап туннельмен емес, LAN арқылы шығады: себебі мен жолы

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

Шығыс пакетті шын мәнінде не анықтайды

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

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

Жергілікті қосымша желі неге жеңеді

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

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

Әріптестердің қамтуы орнатылған маршруттармен бірдей емес

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

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

Кестені көз мекенжайы бойынша таңдаңыз

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

Алдымен жолды, содан кейін қызметті растаңыз

Түсірілімнен болжам жасаудың орнына ядродан не істейтінін сұраңыз, қызмет мекенжайын көз селекторы ретінде қолданып. Мұндағы дұрыс жауап бүкіл пакет ізін үнемдейді.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

Бұл нені түзетпейді

Шлюздегі қайта жіберуді, брандмауэр ережелерін және ICMPv6 әрекетін бұрынғыдай қалдырыңыз, өйткені көз маршруты олардың ешқайсысын алмастырмайды. Жоқ Packet Too Big хабарламасы қай кесте іздеуде жеңсе де үлкен жауаптарды бұзады. Маршруттау ережелерін қоспас бұрын соны түзетіңіз, әйтпесе симптом өзгерістерден кейін де қалады.

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

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