DHCP yangilanishidan keyin VPN uziladimi? Manzillarni solishtiring

Ijara yangilanishi va VPN nosozligi jurnallarda shu qadar tez-tez birga ko'rinadiki, odamlar biri ikkinchisini keltirib chiqaradi degan xulosaga keladi. Vaqt mosligi haqiqiy; sabab-oqibat odatda emas. Yangilanish ijarani bergan serverga bir xil bog'lanishni davom ettirish so'rovini yuboradigan bitta manzilli so'rovdir va server mijoz bitta manzilni ham o'zgartirmasdan uni uzaytirishi mumkin. Voqea atrofida mijozning o'z qiymatlarini ko'rib chiqish jimgina yangilangan ijarani ishlab turgan tunnel ostida haqiqatan o'zgargan tarmoqdan ajratadi.

Uzilgan mijozdan boshlang

Avval mijozning ulanish jurnalini oching va uzilish vaqtini soniyagacha yozib oling. So'ngra o'sha daqiqa uchun operatsion tizimning tarmoq jurnalini oching va interfeys nima qilganini tartib bilan o'qing. Bu tartib butun tekshiruvdir: uzilishdan oldingi DHCP hodisasi, DHCP hodisasidan oldingi uzilish va orasida hech narsa yo'q ikki hodisa uch xil topilma. Tunnel allaqachon qayta ulanayotganda faqat ijarani eslatuvchi jurnal satri bezak, dalil emas.

Vaqt chizig'ini yodda saqlash o'rniga yurganingizda yozib boring. Turli asboblarning vaqt belgilari kamdan-kam to'liq mos keladi va farqning o'zi ba'zan izoh bo'ladi.

Voqea atrofidagi to'rt qiymatni solishtiring

To'rt qiymat ulanishning mahalliy tomonini haqiqiy o'zgarishni ushlash uchun yetarli darajada yaxshi tasvirlaydi: interfeys manzili, standart shlyuz, hal qiluvchilar ro'yxati va interfeysning ish holati. Ularni uzilishdan keyin bir daqiqa ichida oling va tunnel sog'lom bo'lganda olingan yozuv bilan solishtiring.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

O'zgarmagan manzil, o'zgarmagan shlyuz va o'zgargan hal qiluvchilar ro'yxati marshrutlashga emas, nomlarni hal qilishga ishora qiladi va ilovalar xostlarni topishni to'xtatganda tunnel omon qolgan bo'lishi mumkin. O'zgargan shlyuz mahalliy tarmoqdan chiqish yo'li siljiganini bildiradi va bu avvalgisiga ishora qilgan marshrutni bekor qilish uchun yetarli. Agar to'rt qiymatning barchasi sog'lom yozuvga mos kelsa, ijara sizning sababingiz emas va mavzu mijozning o'zining qayta ulanish mantiqiga aylanadi. Nosozlik ko'rinib turganda taqqoslashni oling, chunki qayta yuklashdan keyin olingan sog'lom yozuvning manzillar tarixi boshqacha va u mos kelmaydi.

Yangilanish nimani o'zgartira oladi va nimani olmaydi

RFC 2131 yangilanishni ijara muddatining yarmida asl serverga so'rov sifatida ta'riflaydi, agar birinchi urinish javobsiz qolsa, sakkizdan yettisida istalgan serverga qayta bog'lanish bilan. Ikkala qadam ham mijoz boshqa manzil olishini talab qilmaydi va hamkorlik qiluvchi server odatda mavjud bog'lanishni uzaytiradi. Haqiqiy manzil o'zgarishi odatda boshqa yo'l bilan keladi: server yangilanishdan bosh tortadi, mijoz holatini yo'qotib qaytadan boshlaydi yoki tarmoq qurilmani boshqa segmentga ko'chiradi.

Ulanishning ommaviy tomoni hech qanday mahalliy o'zgarishsiz o'zgarishi mumkin. Operator darajasidagi tarjima orqasida VPN hamkor ko'radigan manzil mahalliy ijara qilgan har qanday ishdan mustaqil ravishda qayta tayinlanishi mumkin va bu qayta tayinlash mijozning ichidan mahalliy tarmoq nosozligidek ko'rinadi. Mahalliy xabar qilingan manzilni hamkor tomonidagi kuzatish bilan solishtirish ularni ajratishning yagona yo'lidir.

Mijoz moslasha olmaganida

Transportini eski manzilga bog'lagan, hamkorga eski marshrutni keshga olgan yoki interfeys identifikatorini saqlagan mijoz endi mavjud bo'lmagan yo'lni qayta-qayta sinab ko'rishi mumkin. Bu moslashish nuqsoni va xost endi yetib bora olmaydigan manzilga qayta yuborishlar sifatida ko'rinadi. Ba'zi mijozlar buni dizayn bo'yicha hal qiladi: masalan, WireGuard yangi manbadan to'g'ri autentifikatsiya qilingan paket kelganda hamkorning oxirgi nuqtasini yangilaydi.

Xizmatni tiklaydigan qo'lda qayta yuklash moslashish qayerda muvaffaqiyatsiz bo'lganiga ishora, ijara va tunnellar bir-biriga mos kelmaydi degan dalil emas. Sinov paytida bloklash siyosatini kuchda qoldiring, aks holda sinovning o'zi boshqa sababli uzilishga aylanadi. Mijoz o'zi tiklandimi, qancha vaqt ketdi va qaysi manzilni qayta sinab ko'rdi — yozib qo'ying; bu ketma-ketlik interfeysda ko'rsatilgan uzilish sababidan ko'proq narsani aytadi.

Ayblashdan oldin voqeani takrorlang

Jadvalni kutmasdan shartni qayta hosil qiling: ijarani bo'shatib qayta yangilang yoki ekvivalent boshqariladigan voqeani majburan keltiring va tunnel omon qolishini kuzating. Boshqariladigan tarmoqda har qanday manzil o'zgarishini tarmoq egasi bilan kelishib oling, chunki o'zboshimchalik bilan statik tayinlash o'sha manzilga allaqachon ega qurilma bilan to'qnashishi mumkin.

Qo'llab-quvvatlangan tuzatishdan keyin o'sha voqeani takrorlang va so'ngra ilova hamda nom so'rovini sinab ko'ring, chunki qayta ulanadigan, lekin DNSni buzadigan tunnel muhim sinovdan kuchsizroq sinovdan o'tadi. Rejalashtirilgan ijarani sabab deb atash o'rniga kuzatgan aniq o'zgarishingizni vaqt belgisi bilan xabar qiling. Bu ikki hisobot orasidagi farq keyingi odam nosozlikni qayta hosil qila oladimi yoki faqat mish-mishni.