Неге сіздің жалпыға қолжетімді Linux қызметіңіз VPN арқылы жауап береді

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

Қате түсінік: жауаптар келген интерфейсті ұстанады

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

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

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

Ядро шын мәнісінде нені маршруттайды: көз мекенжайы

Сізге қажет тұтқа — қызметтің жауаптар үшін пайдаланатын жергілікті мекенжайы. eth0 мекенжайы мысал ретінде 192.0.2.10/24 және шлюзі 192.0.2.1 болатын хостта бұл мекенжай интерфейсте бар. Бұлттық VM-де жария мекенжай жоғарыда аударылып, қонақта болмауы мүмкін, сондықтан хост шын мәнісінде иеленетін мекенжайды пайдаланыңыз.

Кесте нөмірін немесе ереже басымдығын брондамас бұрын ағымдағы күйді тексеріңіз. Қолданыстағы саясат ережелері жаңасын көлеңкелеуі мүмкін, ал сол нөмірлі ескі кестеде қатысы жоқ маршруттар болуы мүмкін:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Содан кейін көз бойынша кесте таңдаңыз. Ереже 192.0.2.10-ды әлдеқашан тасымалдайтын жауаптарға сәйкес келеді, яғни сіз босатуды қалайтын жергілікті аяқталған трафикке. Жөнелтілген трафик пен басқа жергілікті мекенжайлардан келген пакеттер сәйкес келмейді.

Жарты әдепкі емес, толық қайтару кестесін құрыңыз

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Мысалды көшірудің орнына нақты префикс пен шлюзді пайдаланыңыз. On-link шлюзімен /32 ретінде конфигурацияланған бұлттық интерфейс басқа қосылған маршрутты қажет етеді, ал қате префикстен құрылған кесте бірінші секірісте сәтсіздікке ұшырайды. src атрибуты сол маршрут үшін қалаулы көзді көрсетеді; ол көз ережесін алмастырмайды.

Реттілік те маңызды. Басымдық нөмірі төмен кең ереже бірінші бағаланады, сондықтан осы трафикті негізгі кестеге қайтаратын кез келген ережеден бұрын көз ережесіне жету керек. Басымдықтарды қосқаннан кейін ip rule show арқылы тексеріңіз, тек жүктелуде емес.

Көзбен сараланған іздеумен тексеріңіз

Ядродан қызмет мекенжайынан сынақ межелі орынға маршруттауды сұраңыз. Жауап туннельді емес, eth0 мен WAN шлюзін атауы керек:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

Соңғы маршруттар мен ережені интерфейске ие желі менеджерінің астына қойыңыз. Мекенжай өзгерістері, DHCP жаңартуы және VPN қайта қосылулары ядро күйін қайта жазады, ал қолмен қосылған ереже келесі оқиғадан кейін жоғалып кетеді немесе ескірген шлюзді көрсетеді.

Бұл ерекшелік қайдан тоқтайды

Ереже бір көз мекенжайынан жергілікті аяқталған трафикті босатады. Ол Docker жариялаған порттарды, DNAT-ты немесе хост арқылы жөнелтілген қызметтерді қамтымайды, себебі бұл пакеттер жөнелтілген трафик ретінде маршрутталады және хосттың жергілікті көзін ешқашан дәл солай тасымалдамайды. Мұндай жобалар әдетте кіруде қойылатын белгі мен сол белгіге сәйкес келетін ережені қажет етеді.

Ол сондай-ақ хосттың жария мекенжайын интерфейсте көрсетпейді. Жоғарғы NAT сол мекенжайға ие болғанда, жауап әлі де сол NAT күткен жолмен шығуы керек, сол себепті WAN кестесі болжамды жария ауқымды емес, бастапқы шлюз бен префиксті көрсетуі тиіс.

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

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