Katta yuklab olishlar va VPN: yo'lni so'rovda tanlang

“Katta yuklab olishlarni VPN atrofidan yubor, kichik javoblarni esa uning ustida saqla” degani marshrutlash siyosatiga o'xshaydi, lekin unday emas. Router o'sha lahzada mavjud ma'lumot bilan qaror qiladi: manzillar, portlar, protokol, firewall belgilari, aniqlangan oqim. Javobning yakuniy hajmi bu to'plamda yo'q, chunki u hali kelmagan, router baytlarni o'lchay oladigan paytda esa u ularni allaqachon tashimoqda. Agar vazifa bo'yicha boshqarishni istasangiz, qaror vazifani biladigan nuqtaga ko'chishi kerak, quyidagi tekshiruv ro'yxati loyihangizda shunday nuqta bor-yo'qligini ko'rsatadi.

Nima uchun router javobni o'lchay olmaydi

Paketga yo'l kerak bo'lgan lahzada router oqimning ko'pi bilan birinchi bir necha paketini ko'rgan bo'ladi. U kim kim bilan gaplashayotganini, qaysi protokol bilan, qaysi belgi bilan va shu paytgacha qancha bayt o'tganini ayta oladi. Shu paytgacha o'tgan baytlar o'tmishni tasvirlaydi. Javobning hajmi hali yaratilmagan javobning xossasi, bo'lingan yoki oqimli javoblarda esa u hech qachon oldindan ma'lum bo'lmasligi mumkin.

Hatto protokolning o'z metama'lumotlari ham ko'ringanidan zaifroq. HTTP tanadan oldin uzunligi e'lon qilinmaydigan javoblarga ruxsat beradi, bitta foydalanuvchi harakati esa yig'indi xarajati hech bir sarlavha qiymatiga o'xshamaydigan ko'p so'rovlar tug'dirishi mumkin. Sarlavhani vazifa hajmi deb qabul qilish marshrutlash xatosidan oldin modellashtirish xatosi.

Tekshiruv 1: yo'lni tanlay oladigan qaror nuqtasi bormi?

Tanlovni amalga oshiradigan komponentni ayting, so'ng tanlov lahzalarida u nimalarni bilishini ayting. Hujjatlashtirilgan hostlar to'plamidan oladigan yangilovchi o'z maqsadini uzatish boshlanishidan oldin biladi. Metama'lumotlarni ko'rib, so'ng so'rovni ochadigan yuklab olish xizmati vazifani aloqa paydo bo'lishidan oldin biladi. Hamkorlik qiluvchi proxy o'zini router qilib ko'rsatmasdan so'rov darajasidagi siyosatni qo'llashi yoki javobni keshga saqlashi mumkin.

Agar javob “shlyuz” bo'lsa, tekshiruv ro'yxati allaqachon muvaffaqiyatsiz. Shlyuz ma'lum oqimlarni manzil, belgi yoki mijoz segmenti bo'yicha tasniflab, ularni birinchi paketdan belgilangan yo'l bo'ylab yuborishi mumkin, bu tasdiqlangan yangilovchi uchun ko'pincha yetarli, noma'lum javob hajmi uchun esa hech qachon yetarli emas.

Tekshiruv 2: metama'lumotlar sizga aslida nima deydi?

Ilovani taniydigan boshqarish u o'qiydigan maydonlar qanchalik yaxshi bo'lsa, shunchalik yaxshi. HTTP semantikasi dagi javob uzunligi qoidalari uzunlik boshida mavjud bo'lmagan holatlarga ruxsat beradi, kontent kodlashlari esa uzatilgan bayt sonini tasvir hajmidan baribir farqli qiladi. Shuning uchun sarlavha chegaradan oshganda yo'lni almashtiradigan siyosat izchil bo'lmagan holda tutadi, asosan aynan ushlash uchun mo'ljallangan katta uzatishlarda.

Ilova metama'lumotlari qo'llab-quvvatlashi mumkin bo'lgan narsa — vazifa haqidagi qaror: bu ish oqimi ommaviy sinxronizatsiya, bu interaktiv, bu ma'lum manbadan dasturiy yangilanish. Bu niyat tilida yozilgan siyosat va sinovdan o'tkazish uchun yetarlicha barqaror. “Bu javob qirq megabaytdan katta bo'ladi” bunday siyosat emas.

Tekshiruv 3: oqim allaqachon mavjudmi?

Marshrutlash oqim uchun aloqa identifikatorini o'zgartirmasdan o'zgarishi mumkin, va bu farqni aniq saqlashga arziydi. TCP aloqasi o'z uchlarining manzillari va portlari bilan aniqlanadi, marshrutlash jadvali ularning ostida o'zgarsa paketlar boshqa yo'l olishi mumkin. Ko'rinmas tarzda o'zgara olmaydigan narsa tarmoq manzillarini tarjima qilish holati: trafikni boshqa chiqishga ko'chirish odatda ommaviy manba kortejini o'zgartiradi, uzoq tomon esa mos holatsiz boshqa hamkorni ko'radi.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Shunday qilib amaliy qoida: aloqa o'rtasida bir chiqishdan ikkinchisiga ko'chish yangi munosabat, migratsiya emas. Agar loyiha o'sha aloqaning davom etishini talab qilsa, qaror birinchi SYNdan oldin qabul qilinishi kerak edi, va keyin qo'shilgan hech bir paket qoidasi uni toza tarzda qayta qura olmaydi.

Tekshiruv 4: haqiqiy talab kechikishmi, chiqish emasmi?

“Ommaviy trafikni boshqa joyga yubor” degan ko'p so'rovlar aslida katta uzatish interaktiv ishni sekin his qildirishi haqidagi shikoyatlardir. Bu rejalashtirish muammosi va uning rejalashtirish javobi bor: mavjud yo'lda adolatli navbat yoki qo'llab-quvvatlanadigan o'tkazuvchanlik siyosati ommaviy oqimning chat xabarini och qoldirishining oldini oladi, ikkalasini ham joyidan siljitmasdan.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Alomatga shunday yondashish chiqish qarorini xavfsizlik siyosati qo'ygan joyda qoldiradi va uni bitta buyruq bilan qaytarish mumkin. Butun trafik sinfi uchun chiqishni o'zgartirish autentifikatsiya, jurnallash va kirish qoidalariga oqibatlari bo'lgan siyosat o'zgarishi, shuning uchun kechikish shikoyatida birinchi vosita bo'lmasligi kerak.

Agar talab haqiqatan boshqa internet chiqishi bo'lsa, buni o'sha so'zlar bilan ayting va qo'llab-quvvatlanadigan chegarada amalga oshiring: tasdiqlangan ish oqimidan yangi aloqa yoki o'z so'rovini tanlangan chiqish orqali ochadigan ilova. So'ng qaysi vazifalar qaysi chiqishdan foydalanishini yozib qo'ying, keyingi odam buni marshrutlash jadvalidan taxmin qilmasligi uchun.

Tekshiruv ro'yxatini o'zgarish yozuvida saqlang: qaror nuqtasi, uni harakatga keltiruvchi maydon yoki vazifa, oqim allaqachon mavjudmi va o'lchangan alomat kechikishmi yoki chiqishmi. To'rt savol, va to'rttasiga ham javob beradigan siyosat — himoya qilinadigan emas, boshqariladigan siyosat.