Böyük yükləmələr VPN-ə qarşı: yolu sorğuda seçin
Marşrutlaşdırıcı cavabın ölçüsünü gəlməmişdən əvvəl bilə bilməz. Tapşırığa görə yönləndirmə tətbiq səviyyəsində qərar nöqtəsi və ya mövcud yolu saxlayan növbə siyasəti tələb edir.
«Böyük yükləmələri VPN-in ətrafından göndər, kiçik cavabları onun üzərində saxla» marşrutlaşdırma siyasəti kimi səslənir, amma deyil. Marşrutlaşdırıcı həmin anda mövcud olan məlumatla qərar verir: ünvanlar, portlar, protokol, firewall işarələri, müəyyən edilmiş axın. Cavabın son ölçüsü bu çoxluğa daxil deyil, çünki hələ gəlməyib və marşrutlaşdırıcı baytları ölçə bildiyi vaxt artıq onları daşıyır. Əgər tapşırığa görə yönləndirmə istəyirsinizsə, qərar tapşırığı bilən nöqtəyə köçməlidir və aşağıdakı yoxlama siyahısı dizaynınızda belə bir nöqtənin olub-olmadığını müəyyən etmək üçündür.
Nə üçün marşrutlaşdırıcı cavabın ölçüsünü bilə bilmir
Paketin marşruta ehtiyac duyduğu anda marşrutlaşdırıcı axının ən çoxu ilk bir neçə paketini görüb. O, kimin kiminlə danışdığını, hansı protokolla, hansı işarə ilə və indiyə qədər neçə baytın keçdiyini deyə bilər. İndiyə qədərki baytlar keçmişi təsvir edir. Cavabın ölçüsü isə hələ yaradılmamış cavabın xassəsidir və hissəli və ya axın şəklində cavablar üçün əvvəlcədən heç vaxt bilinməyə bilər.
Protokolun öz metadatası belə göründüyündən zəifdir. HTTP, uzunluğu gövdədən əvvəl elan olunmayan cavablara icazə verir və bir istifadəçi hərəkəti birləşdirilmiş dəyəri heç bir başlıq dəyərinə bənzəməyən çoxlu sorğu yarada bilər. Başlığı tapşırığın ölçüsü kimi qəbul etmək marşrutlaşdırma xətasından əvvəl modelləşdirmə xətasıdır.
Yoxlama 1: yol seçə bilən qərar nöqtəsi varmı?
Seçimi edəcək komponenti adlandırın, sonra seçim anında onun nə bildiyini adlandırın. Sənədləşdirilmiş host dəstindən gətirən yeniləyici öz məqsədini ötürmə başlamazdan əvvəl bilir. Metadataya baxıb sonra sorğunu açan yükləmə xidməti tapşırığı bağlantı yaranmazdan əvvəl bilir. Əməkdaşlıq edən proxy isə özünü marşrutlaşdırıcı kimi göstərmədən sorğu səviyyəsində siyasət tətbiq edə və ya cavabı keşləyə bilər.
Əgər cavab «şlüz»dürsə, yoxlama siyahısı artıq uğursuz olub. Şlüz tanınan axınları təyinat, işarə və ya müştəri seqmentinə görə təsnif edib ilk paketdən müəyyən yola göndərə bilər; bu, təsdiqlənmiş yeniləyici üçün çox vaxt kifayətdir və naməlum cavab ölçüsü üçün heç vaxt kifayət etmir.
Yoxlama 2: metadata sizə həqiqətən nə deyir?
Tətbiqdən xəbərdar yönləndirmə yalnız oxuduğu sahələr qədər yaxşıdır. HTTP semantikası daxilində cavab uzunluğu qaydaları uzunluğun başlanğıcda mövcud olmadığı hallara icazə verir və məzmun kodlaşdırmaları ötürülən bayt sayını təsvir ölçüsündən fərqli edir. Buna görə başlıq həddi keçdikdə yolu dəyişən siyasət qeyri-sabit davranacaq və əsasən tutmaq üçün nəzərdə tutulduğu böyük ötürmələrdə belə olacaq.
Tətbiq metadatasının dəstəkləyə biləcəyi şey tapşırıq haqqında qərardır: bu iş axını toplu sinxronizasiyadır, bu interaktivdir, bu tanınmış mənbədən proqram yeniləməsidir. Bu, niyyət dilində yazılmış siyasətdir və sınaqdan keçirmək üçün kifayət qədər sabitdir. «Bu cavab qırx meqabaytdan böyük olacaq» isə belə siyasət deyil.
Yoxlama 3: axın artıq mövcuddurmu?
Marşrutlaşdırma axın üçün bağlantının kimliyini dəyişmədən dəyişə bilər və bu, düz saxlanmalı olan fərqdir. TCP bağlantısı son nöqtə ünvanları və portları ilə müəyyən edilir və marşrut cədvəli altında dəyişərsə, paketlər fərqli yol tuta bilər. Görünməz şəkildə dəyişə bilməyən şey şəbəkə ünvanı çevrilməsi vəziyyətidir: trafiki başqa çıxışa köçürmək adətən açıq mənbə dəstini dəyişir və uzaq tərəf uyğun vəziyyəti olmayan fərqli həmkar görəcək.
conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10
Beləliklə, praktik qayda budur: bağlantı ortasında bir çıxışdan digərinə keçid miqrasiya deyil, yeni münasibətdir. Əgər dizayn eyni bağlantının davam etməsini tələb edirsə, qərar ilk SYN-dən əvvəl verilməli idi və sonradan əlavə edilən heç bir paket qaydası onu təmiz şəkildə bərpa edə bilməz.
Yoxlama 4: əsl tələb çıxış deyil, gecikmədirmi?
«Toplu trafiki başqa yerə göndər» xahişlərinin çoxu əslində böyük ötürmənin interaktiv işi yavaş hiss etdirməsindən şikayətdir. Bu, planlaşdırma məsələsidir və planlaşdırma cavabı var: mövcud yolda ədalətli növbə və ya dəstəklənən zolaq siyasəti toplu axının söhbət mesajını ac qoymasının qarşısını alır, heç birini yerindən tərpətmədən.
tc qdisc replace dev eth0 root cake bandwidth 100mbit
Simptomu bu cür həll etmək çıxış qərarını təhlükəsizlik siyasətinin qoyduğu yerdə saxlayır və bir əmrlə geri qaytarıla bilər. Bütün trafik sinfi üçün çıxışı dəyişmək autentifikasiya, jurnal və giriş qaydaları nəticələri olan siyasət dəyişikliyidir, ona görə gecikmə şikayəti üçün ilk müraciət olunan alət olmamalıdır.
Əgər tələb həqiqətən fərqli internet çıxışıdırsa, bunu məhz bu sözlərlə deyin və dəstəklənən sərhəddə həyata keçirin: təsdiqlənmiş iş axınından yeni bağlantı və ya seçilmiş çıxışdan öz sorğusunu açan tətbiq. Sonra hansı tapşırıqların hansı çıxışı istifadə etdiyini qeyd edin ki, növbəti şəxs bunu marşrut cədvəlindən çıxarmalı olmasın.
Yoxlama siyahısını dəyişiklik qeydində saxlayın: qərar nöqtəsi, onu idarə edən sahə və ya tapşırıq, axının artıq mövcud olub-olmadığı və ölçülən simptomun gecikmə yoxsa çıxış olduğu. Dörd sual və dördünə də cavab verən siyasət müdafiə etməli olduğunuz deyil, idarə edə bildiyiniz siyasətdir.