VPN қайта қосылғаннан кейін прокси әлі ескі туннель мекенжайында ма?

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

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

Туннельден емес, тыңдаушыдан бастаңыз

Ойында үш мекенжай бар, ал қайта қосылу олардың тек кейбіреуін жылжытады. Тыңдаушы — браузеріңіз сілтейтін орын, әдетте 127.0.0.1 немесе LAN мекенжайы, және оған туннельдің өзгергені бәрібір. Шығыс жергілікті бастау — жіберуші келесі қадамды теру кезінде ядродан қолдануды сұрайтын нәрсе, ол туннель құрылғысына байланған. Жария шығыс — веб-сервер жазатын нәрсе, ол бірнеше қадам қашықтықтағы аударылған мекенжай болуы мүмкін.

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

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

Бірдеңені өңдеуден бұрын төрт тексеріс

Оларды ретімен орындаңыз. Бірінші сәтсіз тексеріс — тоқтайтын жеріңіз, өйткені келесілер алдыңғылардың орындалғанын болжайды.

1. Қолданылып жатқан туннель прокси салынған профиль екенін, өздігінен қосылған екінші профиль емес екенін растаңыз.
2. Сол құрылғыдағы ағымдағы мекенжайды басып шығарып, оны жұмыс істеп тұрған конфигурациядағы мекенжаймен салыстырыңыз.
3. Дискідегі файл айтқанды емес, жіберушіден қандай бастауды тапқанын сұраңыз.
4. Жіберушіден келетін трафиктің шынымен күткен маршруттау және брандмауэр саясатына бағынатынын растаңыз.

Құрылғы мекенжайы қарапайым: ip -4 addr show dev tun0 ағымдағысын басып шығарады, ал ip -4 route get 1.1.1.1 ядро сол мақсат үшін қай интерфейсті таңдайтынын көрсетеді. Нақты мекенжайға байланатын жіберуші мекенжай жоғалғанда қатты сәтсіздікке ұшырайды. Құрылғыға байланатын немесе әдепкі бастауға қайтатын жіберуші жұмысын жалғастырып, ағып кетеді, және бұл — тыныш нәтиже.

Құжаттаманы сіз іске қосатын шығарылымға сәйкестендіріңіз, іздеудің жоғарғы нәтижесіне емес. Squid-тің шығыс мекенжай директивасы v7 және одан бұрынғылар үшін құжатталған, ал v8 құжаттамасы директива ол жерде қолжетімсіз екенін ашық айтады, сондықтан оның айналасында құрылған скрипт бұл шекарадан өтпейді (Squid tcp_outgoing_address анықтамасын қараңыз). Бірдеңені қайта жүктемес бұрын өнімнің өз талдағышымен тексеріңіз: squid -k parse қателерді хабарлап, жұмыс істеп тұрған процеске тимей шығады.

Әр туннельді нөмірлеп, ескірген алмасуларды тастаңыз

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

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

Ашық сокеттер жаңа мекенжайды ұстанбайды

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

Ауысудан бұрын ашылған сокет арқылы қызмет көрсетілген сұраныс жаңа конфигурация дұрыс болса да ескі жолмен шығады. Егер бұл маңызды болса, ашық шешім қабылдаңыз: қысқа босату терезесіне жол беріп, жаңа жұмысты қабылдауды тоқтатыңыз, немесе ескі сокеттерді жауып, қателерді қабылдаңыз. Содан кейін жаңа байланыспен сынап, бұл нәтижені босату тексерісінен бөлек ұстаңыз. Бастауға байлану да қауіпсіздік шекарасы емес. Трафик әдеттегі маршрутқа ешқашан тимеуі керек болса, оны белгілер мен брандмауэр ережелерімен, DNS және IPv6 қоса, мәжбүрлеңіз, сәтсіз қайта жүктеу проксиді ашық емес, анық өшірулі қалдырсын.

Жаңа шығысты жаңа сұраныспен дәлелдеңіз

Маңыздысы — іске қосылғаннан кейін ашылған сұраныс, ping емес және кэште болған бет емес. Проксиден нақты URL сұрап, қашықтағы жақ хабарлаған шығыс мекенжайды оқыңыз, содан кейін провайдер көрсетсе, клиенттің туннель туралы өз көзқарасымен салыстырыңыз.

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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