VPN marshrut keshi o‘zgarishingizni yashiryaptimi? Uch narsani tekshiring

O‘zgarish kuchga kirmaganda marshrut keshini tozalash birinchi instinkt, va zamonaviy Linuxda bu behuda mehnat: global IPv4 marshrut keshi yillar oldin olib tashlangan, shuning uchun ip route show cache hech narsa chop etmaydi va tozalash uchun hech narsa yo‘q. Sizni aldovchi holat bir qatlam yuqorida yashaydi: socketda, NAT xaritasida, resolverda yoki eski profilni qayta qo‘llagan tarmoq menejerida. Uch savol bu holatlarni ajratadi: noto‘g‘ri yo‘l yangi oqimdanmi yoki eski ulanishdanmi keladi, platformangiz marshrutlarni umuman keshlaydimi, va holat marshrutlashdami yoki uning ustidami. Interfeysni qayta sozlashdan oldin ularga javob bering.

Birinchi tekshiruv: eski yo‘l yangi oqimdanmi keladi?

O‘rnatilgan ulanish o‘zi yaratilgan marshrutni saqlaydi. Shu sababli tunnel orqali SSH sessiyasi marshrutlash jadvali o‘zgarishidan omon qoladi, yangi sessiya esa darhol yangi yo‘lni oladi, va shu sababli «o‘zgarish hech narsa qilmadi» ko‘pincha «eski socket hali ham uni ushlab turadi» deganini bildiradi. Yangi jarayon bilan sinab ko‘ring, allaqachon ochiq oyna bilan emas.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Oxirgi buyruq yangi ulanish haqiqatan yetib borgan manzilni chop etadi, va holat oynasiga ishonmasdan haqiqiy yo‘lni ko‘rishning eng arzon usuli shu. Uni namespace yoki interfeys ishlatishi kerak bo‘lgan manba manzili bilan solishtiring.

Agar yangi oqim to‘g‘ri yo‘lni olsa va eskisi tiklanmasa, marshrutlashga qarashni to‘xtating. Marshrut to‘g‘ri edi; sessiya eski edi.

Ikkinchi tekshiruv: platformangiz marshrut keshini umuman saqlaydimi?

Linuxda javob yo‘q, ko‘pchilik qo‘llanmalar nazarda tutgan ma’noda. Tashlab yuborish uchun global manzil keshi yo‘q, va tanlangan marshrutni saqlaydigan har bir socket yozuvi socket bilan birga bo‘shatiladi. ip-route qo‘llanmasining kesh bo‘limi tarixiy xatti-harakatni tasvirlaydi, joriy yadroda siz tozalashingiz mumkin bo‘lgan narsani emas.

Boshqa platformalar farq qiladi, va maslahatlarni ko‘chirish aynan shu yerda xato bo‘ladi. Windows manzil keshini saqlaydi, uni netsh interface ip delete destinationcache bilan tozalash mumkin. BSD va macOS route -n get orqali har bir manzil bo‘yicha qidiruvlarni ko‘rsatadi, va ularning keshlari o‘z jadvali bo‘yicha tugaydi. Ulardan birida ishlaydigan buyruq Linuxda hech narsa qilmaydi, shu sababli bir xil tuzatish sinab ko‘rganlarning yarmiga muvaffaqiyatsiz ko‘rinadi.

NAT yoki conntrack jadvali marshrut keshi emas, garchi bir xil belgi tug‘dirsa ham. O‘zgarishingizdan oldin tarjima qilingan oqim o‘z tarjimasini saqlaydi, va marshrutlash siyosati oldinga o‘tgandan keyin ham conntrack -L uni uzoq vaqt ko‘rsatadi. Bu eskirgan holat, lekin marshrutlarni tozalash unga tegmaydi.

Uchinchi tekshiruv: holat marshrutlashdami yoki uning ustidami?

Boshqa narsani o‘qishdan oldin joriy qidiruvni o‘qing: manzil uchun ip route get, keyin from va manba manzili bilan o‘sha buyruq, keyin ip rule show. Agar bu uchtasi niyatingizga to‘g‘ri kelsa, marshrutlash tuzatiladigan qatlam emas, va eskirgan kuzatuv boshqa joydan kelgan.

Uch odatiy gumondor marshrutlashning ustida o‘tiradi. Tarmoq menejeri marshrutni siz o‘chirganingizdan bir necha soniya o‘tib saqlangan profildan qayta o‘rnatishi mumkin, shuning uchun o‘zgarishingiz qaytayotgandek ko‘rinadi; jadvalni qayta tahrirlashdan oldin nmcli connection show --active va birlik holatini tekshiring. Resolver keshi eski manzilni qaytaradi, bu keshni chetlab o‘tuvchi vosita bilan o‘sha nomni so‘ramaguningizcha marshrutlash nosozligidek ko‘rinadi. Ilovaning ulanish hovuzi eski manzilga ishlaydigan socketni saqlaydi va yadrodan hech qachon yangi qaror so‘ramaydi.

Uch javob qanday xulosa chiqarishga imkon beradi

Javoblarni birlashtiring va tuzatish odatda o‘zini aytadi. Marshrut keshi yo‘q platformada yangi oqim noto‘g‘ri yo‘lni olsa, siyosat haqiqatan noto‘g‘ri, shuning uchun tunnel o‘rnatgan qoidalar va jadvalni o‘qing. Eski sessiya tiqilib turganda yangi oqim to‘g‘ri yo‘lni olsa, muammo ilovada yoki socketda. Ikkala holatda ham to‘g‘ri marshrutlar bilan buzilgan kuzatuv holat marshrutlashning ustida ekanini bildiradi.

Umumiy yangilanishga qarshi turing. Tarmoq stekini qayta ishga tushirish yoki asosiy marshruti tunnel bo‘lgan mashinada har bir marshrutni o‘chirish aynan uni tuzatish uchun ishlatayotgan ulanishni uzishi mumkin, va qaysi qatlam muvaffaqiyatsiz bo‘lganini aytadigan dalilni yo‘q qiladi.

Agar haqiqatan biror narsani tozalash kerak bo‘lsa, tashxisga mos eng kichik narsani tozalang: bitta jarayonning socketlari, bitta conntrack yozuvi, resolver keshi. Keyin o‘sha yangi oqim testini takrorlang va nima o‘zgarganini yozing.

Yozuvlaringizda uch holatni alohida saqlang

Saqlangan konfiguratsiya, joriy qidiruv va kuzatilgan oqim uch xil fakt, va ularni «kesh»ga birlashtirish nosozlikni qayta hosil qilishni qiyinlashtiradigan narsa. Marshrutga egalik qiluvchi profil yoki birlikni, ip route get chiqishini, va haqiqiy ulanishning manbasi va manzilini yozing.

Ularning yoniga platforma va mijoz versiyasini yozing, chunki Windows manzil keshini tozalaydigan tuzatish Linux xostiga qo‘llaniladigan tuzatish emas, va ikkalasi o‘rtasida ko‘chirilgan tartib noto‘g‘ri saboq beradi. Muammoni boshqaga topshirganingizda, o‘sha uch satr unga taxmin qilish o‘rniga muvaffaqiyatsiz holatni qayta hosil qilish imkonini beradi.