Developer alətlərini açın, daxili tətbiqi yükləyin və səhifə göstərilməzdən əvvəl bir sorğunun dörd yoxlama nöqtəsindən keçdiyini izləyin. Əvvəlcə ad həll olunur, sonra TCP bağlantısı açılır, sonra TLS əl sıxması serverin kim olduğunu müəyyən edir və yalnız bundan sonra tətbiq sizin kim olduğunuzu soruşur. Bunları ayrı hadisələr kimi qəbul edin, çünki hər biri fərqli dəlillə uğursuz olur və hər birinə fərqli komanda cavabdehdir. Hadisələrdə qarışıqlığın çoxu 401-i tunel problemi, tunel problemini isə pis şifrə kimi oxumaqdan gəlir.

Birinci yoxlama nöqtəsi: danışmaq istədiyiniz server budurmu

TLS əl sıxması bu suala hər hansı etimad məlumatı göndərilməzdən əvvəl cavab verir. Müştəriniz sertifikat zəncirini etimad anbarına qarşı yoxlayır və sertifikatdakı adın yazdığınız hosta uyğun olduğunu təsdiqləyir. Bu uğursuz olarsa, brauzer sertifikat xətası göstərir və Authorization başlığını heç vaxt göndərmir. Buna görə şifrə sorğusu serverin həqiqi olmasının sübutu deyil; tətbiqin cavab verdiyinin sübutudur.

Burada ilk sərhəd görünür. TLS bağlantını sonlanma nöqtəsinə qədər qoruyur. Əgər yük balanslaşdırıcısı TLS-i sonlandırır və sadə HTTP-ni tətbiqə ötürürsə, şifrələnmiş seqment balanslaşdırıcıda bitir və etimad məlumatları yalnız ilk keçiddə qorunur.

İkinci yoxlama nöqtəsi: 401 mübadiləsində əslində nə səyahət edir

HTTP Basic autentifikasiyası istifadəçi identifikatorunu və şifrəni başlıqda göndərir və Base64 ilə kodlayır; bu, aşağıdakı sənəddə təsvir olunub RFC 7617. Authorization: Basic dXNlcjpwYXNz forması budur; kodlaşdırma sorğunu oxuya bilən hər kəs tərəfindən geri çevrilə bilər, ona görə də bütün məxfilik altındakı nəqliyyatdan gəlir. curl -v həm WWW-Authenticate: Basic çağırışını, həm də geri göndərdiyiniz başlığı göstərir.

Bu başlıq tətbiqə kimin soruşduğunu bildirir. Şəbəkəyə kimin qoşula biləcəyini bildirmir və özü heç nəyi şifrələmir. Tətbiq hələ də etimad məlumatını anbara qarşı yoxlamalı və bu hesabın nə edə biləcəyinə qərar verməlidir; bu, avtorizasiyadır və autentifikasiyadan sonra baş verir.

IPsec tuneli bu yolda harada yerləşir

İndi brauzerdən xaricə doğru get. Şlüz-şlüz IPsec tuneli iki təhlükəsizlik şlüzü arasında seçilmiş trafiki qoruyur, noutbukunuzla tətbiq prosesi arasında deyil. Tunel rejimli ESP orijinal paketi bükür, şlüzlər onu şifrələyir və doğrulaşdırır, daxili ünvanlar isə qalır ki, uzaq tərəf sorğunu tətbiqə yönləndirə bilsin.

Seçim insanları çaşdıran hissədir. Siyasət əsaslı tunellər trafik seçicilərindən istifadə edir, çox vaxt giriş nəzarəti siyahıları kimi ifadə olunur və hansı paketlərin tunelə girdiyini müəyyənləşdirir. Marşrut əsaslı tunellər əvəzində virtual interfeys və marşrut cədvəlindən istifadə edir. Linux-da ip xfrm policy seçiciləri, ip xfrm state isə qurulmuş təhlükəsizlik assosiasiyalarını göstərir; firewall cihazında ekvivalent tunelin SA cədvəli üstəgəl paket izləyicisidir.

Nəticəni açıq deməyə dəyər. Paket tamamilə sağlam tunelin içində oturub yenə də tətbiqin rədd etdiyi HTTPS sorğusunu daşıya bilər və etibarlı etimad məlumatları marşrut imkan verdiyi halda heç bir tunel olmayan yolla gələ bilər.

Uğursuzluğu onu bildirən qatda oxuyun

401 tətbiqin etimad məlumatını qəbul etmədiyini bildirir. 403 onun kimliyi qəbul edib əməliyyatı rədd etdiyini bildirir. TLS xətası müştərinin serveri qəbul etmədiyini bildirir. Marşrutun olmaması və ya siyasət uyğunsuzluğu paketin uzaq şlüzə heç vaxt çatmadığını bildirir. Dörd fərqli uğursuzluq, dörd fərqli sahib, və heç biri giriş formasına baxmaqla diaqnoz edilmir.

Hər qatın istehsal etdiyi dəlildən istifadə edin: status və başlıqlar üçün brauzerin şəbəkə paneli, sertifikat zənciri üçün openssl s_client -connect host:443, tunel trafiki üçün şlüzün SA sayğacları və qeydləri, hesab qərarı üçün tətbiq qeydi. İki qat eyni vaxtda xəta bildirəndə əvvəlcə aşağıdakını düzəldin, çünki ölü tunel autentifikasiya uğursuzluğunu asanlıqla gizlədə bilər və əksi də doğrudur.

Bir xidməti başdan sona xəritələyin

Xəritə çəkdiyiniz xidmət üçün beş sətir yazın: tunelin hansı həmyaşıdları birləşdirdiyi, seçicilərin hansı alt şəbəkələrə və portlara icazə verdiyi, TLS-in harada bitdiyi və sertifikatın hansı kimliyi təsdiqlədiyi, hansı tətbiq hesabı və rolunun istifadə olunduğu və hər qatın harada qeyd apardığı. Onları bir səhifədə saxlayın, çünki xəritənin məqsədi bir qatın məsuliyyətinin harada bitib növbətinin başladığını göstərməkdir.

Sonra hər qat üçün bir mənfi hal sınayın. Səhv şifrə istifadə edin və 401 aldığınızı təsdiqləyin, gözləmə deyil. Seçicilərdən kənar bir alt şəbəkədən qoşulun və paketin tuneldən keçmədiyini təsdiqləyin. Səhv ad üçün sertifikat təqdim edin və müştərinin etimad məlumatı göndərməzdən əvvəl imtina etdiyini təsdiqləyin. Bu üç nəticə dizayn haqqında sizə qutuların hər hansı diaqramından daha çox şey deyir.

Nəhayət, hər əlaqənin hansı qorunmaya ehtiyacı olduğuna qəsdən qərar verin. TLS üzərində Basic autentifikasiyası şlüz arxasındakı kiçik daxili alət üçün məqbul uyğunluqdur; o, istifadəçi üzrə avtorizasiyanın və ya TLS son nöqtəsindən kənar trafikin qorunmasının əvəzi deyil. Tunel yolu qoruyur, sertifikat keçidi qoruyur, 401 isə hesabı qoruyur və yalnız sonuncusu sizin kim olduğunuzu bilir.

Əlaqəli məqalələr