SIGKILL-ден кийин OpenVPN DNS калат: адегенде ээсин текшериңиз

OpenVPN кардары өлтүрүлгөндөн кийин DNS чечүүнү токтотот, жана биринчи түйшүк /etc/resolv.conf файлын кайра жазуу болуп саналат. Бул өзгөртүү иштеп жаткан resolverди бузушу мүмкүн, ал эми чыныгы эскирген абал башка жерде турат. Биринчи чечилиши керек суроо — туннель орноткон DNS жөндөөлөрү кимге таандык жана тазалоону өткөрүп жиберген чыгуу чын эле маанилүү болдубу.

Оңдоону үч шарт аныктайт: процессти токтоткон сигнал, жөндөөлөрдү алган resolver компоненти жана туннель байланышы дагы барбы. Аларга ушул тартипте жооп бериңиз, оңдоо адатта глобалдык файлды кармабастан келет.

Кандай чыгуу түрү болгонун аныктаңыз

Community басылымындагы OpenVPN үчүн SIGINT да, SIGTERM да тыкан чыгуу өтүнүчтөрү. SIGKILLди кармоого болбойт: аны блоктоого да, иштетүүгө да болбойт, ошондуктан эч бир өчүрүү процедурасы иштөө мүмкүнчүлүгүн албайт. Алдыңкы пландагы терминалдагы кадимки Ctrl+C SIGINT жаратат, ал эми күтүүнү таштаган көзөмөлчү адатта SIGKILLге көтөрүлөт. Айырма маанилүү, анткени экинчи учур гана илгичтер өткөрүлүп кеткенин кепилдейт.

screen же tmux ичинде иштетүү Ctrl+C кайсы сигналды жиберерин өзгөртпөйт. Терминал адатта эмне кылаарын эмес, процесс чындап эмне алганын текшериңиз.

Туннелди кызмат же байланыш менеджери иштетсе, pidди өлтүрүүнүн ордуна ошол бир байланышты анын ээси аркылуу токтотуңуз. Менеджер процессти кайра көтөрүшү мүмкүн, ошондо сизде жаңы туннель жана баш аламан resolver абалы калат. Өз алдынча процесске тазалоо иштеши үчүн жөнөкөй токтотуу өтүнүчү жетиштүү.

Resolver кимге таандык экенин аныктаңыз

systemd-resolved, resolvconf стилиндеги скрипт жана жөнөкөй файлды кайра жазуу — үч башка ээ. Биринчиси ар бир байланыштын жөндөөлөрүн эстутумда кармайт жана интерфейс жоголгондо аларды таштайт. Экинчиси бир нерсе жок кылганга чейин сакталган жазууларды кармайт. Үчүнчүсү файл жазат жана калыбына келтирүүнү аны жазган адамга калтырат.

Оңдоо буйругун тандоодон мурун ээсин аныктаңыз. Ошол эле белгинин кайсы колдонулуп жатканына жараша үч башка туура жообу бар.

NetworkManager башкарган VPN resolver өзгөртүүлөрүнө мурунтан ээ болушу мүмкүн. Анын үстүнө экинчи жардамчы кошуу бир эле байланыш үчүн атаандашкан эки ээ жаратат, жана утулган тараптын абалы кийинки кайра туташууда кайра пайда болот. Эгер менеджер жооптуу болсо, жөндөөнү скриптте эмес, менеджерде оңдоңуз.

down илгичи эмне кыла алат жана эмне кыла албайт

Скрипт down TUN/TAP түзмөгү жабылгандан кийин бир жолу иштейт. down-pre кошуу бул тартипти тескери бурат жана скриптти түзмөк дагы бар кезде иштетет, муну тирүү байланыш керектеген жардамчылар талап кылат.

Эки нускаманын бири да илгичти SIGKILLден кийин иштетпейт. Укуктар да down-pre аркылуу калыбына келбейт: эгер демон user же group деңгээлине түшсө же chroot чөйрөсүнө кирсе, илгич анын калтырган жеткиликтүүлүгү менен иштейт. Чакырылган илгич resolverди жаңырта албай калышы мүмкүн. OpenVPN маалымдамасы сигналдарды жана callback жашоо цикин камтыйт.

Илгичтин өз катасын процесстин чыгуу абалынын жанында текшериңиз. Жок тазалоо менен ийгиликсиз тазалоо resolverде бирдей, ал эми журналдарда башкача көрүнөт.

Чын эле калган абалды текшериңиз

systemd-resolved колдонгон системада resolvectl status кайсы байланыш дагы VPN DNS серверлерин же маршруттоо домендерин алып жүргөнүн көрсөтөт. Ал байланыш кеткен туташууга же дагы көтөрүлгөн башка туннелге таандык болушу мүмкүн.

Жоголгон интерфейс өзүнүн ар бир байланыш конфигурациясын ала кетет, ошондуктан өткөрүлгөн илгич таза DNS менен катар жашай алат. Эгер байланыш дагы катталган болсо жана токтотулган туташууга гана таандык болсо, ага ээ менеджер аны алып салууга тийиш. Эгер эскирээк скрипт глобалдык resolver файлын кайра жазса, анын ордуна ошол скрипттин документтештирилген калыбына келтирүү кадамын издеңиз.

Башка байланышты уурдабастан калыбына келтириңиз

Ар бир байланыштын жөндөөлөрү сиздин башкарууңузда болсо, resolvectl revert байланыштын атын алат жана ошол интерфейс үчүн аткаруу убагындагы DNS конфигурациясын тазалайт. Бул профилди түзөтүү эмес, аткаруу убагындагы аракет, ошондуктан туруктуу туташуу конфигурациясы өзгөрүүсүз калат. Туура эмес байланышты атасаңыз, иштеп жаткан туннелдин DNSин тазалайсыз, ошондуктан ат абалдын чыгуусунан алынат.

Түзөтүүдөн мурун /etc/resolv.conf башкарылуучу символикалык шилтеме экенине ынаныңыз, андан кийин кардарды дагы бир жолу кадимкидей токтотуп, DNSке кайра караңыз. Эгер экинчи токтотуу тазаласа, мурунку көйгөй конфигурация эмес, мажбурланган чыгуу болгон.