Açıq proksinin VPN vasitəsilə şəxsi mənbəyə necə çatdığı

Saytı tunel vasitəsilə nəşr etmək və istifadəçilərə VPN girişi vermək eyni kabeli paylaşan iki fərqli tənzimləmədir. Birincisində açıq əks proksi ziyarətçinin sorğusunu qəbul edir və onu tunel vasitəsilə heç kimin birbaşa çata bilmədiyi mənbəyə yönləndirir. İkincisində istifadəçi tətbiqə ümumiyyətlə çatmaq üçün əvvəlcə VPN-ə qoşulmalıdır. Bu iki təsviri qarışdırmaq şəxsi backendin sonunda açıq şəkildə ifşa olunmasına gətirib çıxarır.

Diaqramda eyni görünən iki model

Heç nə seçməzdən əvvəl oxları çəkin. Açıq nəşr modeli brauzerdən proksiyə HTTPS üzərindən, sonra proksidən mənbəyə tunel üzərindən gedir və mənbə heç vaxt internetdən bağlantı qəbul etmir. Yalnız VPN modeli müştəridən şlüzə gedir və tətbiqə yalnız həmin yolun içindən çatmaq olar. İstifadəçinin noutbuku tətbiqlə eyni şəbəkədə oturur və bu, həmin modelin bütün mənasıdır.

Modellər kimin doğruladığına və harada doğruladığına görə fərqlənir. Birincisində proksi açıq girişdir və gələn hər hansı sorğunu, o cümlədən düşmən sorğunu, onun üzərində qurulmuş siyasətə uyğun olaraq ötürür. İkincisində çatıla bilənlik özü darvazadır və bu, kobud, lakin real qəbuldur.

TLS harada dayanır və həqiqətən nəyi sübut edir

Brauzerlə proksi arasındakı TLS həmin atlamanı qoruyur və brauzerə ziyarət etmək istədiyi saytı yoxlamağa imkan verir. Əgər proksi TLS-i dayandırırsa, sorğu yönləndirilməzdən əvvəl həmin prosesin içində oxunaqlı formada mövcud olur. Mənbəyə ikinci TLS sessiyası növbəti atlamanı qoruya və tətbiqin son nöqtəsini ayrıca yoxlaya bilər. Sessiyaların heç biri hansı insanın tətbiqdən istifadə edə biləcəyini müəyyən etmir. Proksidəki wildcard sertifikatı da o ikinci atlamaya şamil olunmur.

Bu, insanların şifrələnmiş sözünə sıxdığı hissədir. Məxfilik, bütövlük və server kimliyi nəqliyyat xassələridir; avtorizasiya isə tətbiq qərarıdır. Tunelin arxasındakı şəxsi ünvan soketə kimin çata biləcəyini dəyişir, onlar çatdıqdan sonra kimin daxil ola biləcəyini yox.

Yönləndirilmiş başlıqlara yalnız proksidən etibar edin

Müştəri ünvanı üzrə jurnal aparan və ya avtorizasiya edən tətbiqlər adətən proksinin əlavə etdiyi başlığı oxuyur. O başlıq sadəcə mətndir, ona görə mənbəyə birbaşa çata bilən hər şey istədiyi ünvanı iddia edə bilər. Mənbəyi elə məhdudlaşdırın ki, yalnız proksin tunel ünvanı qoşula bilsin və tətbiqi başlığı yalnız həmin ünvandan qəbul etməyə konfiqurasiya edin.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Əgər bu sorğu proksi olmayan hostdan uğurla keçirsə, mənbə görməzdən gəlməli olduğu başlığa etibar edir. Tətbiqə toxunmazdan əvvəl dinləyicini düzəldin. İmtina, saxta ünvan daşıyan jurnal sətrindən qat-qat yaxşı nəticədir.

Mənbəni yalnız bir yerdən çatıla bilən saxlayın

Mənbənin dinləyicisini tunel ünvanına bağlayın və ya proksiyə qədər firewall ilə əhatə edin, sonra həqiqətən nəyin dinlədiyini təsdiqləyin. Wildcard bağlantı ilə başladılan xidmət hostun malik olduğu hər interfeysdə, o cümlədən marşrutlaşdırıla bildiyini unutduğunuz interfeysdə bağlantı qəbul edir. Dinləmə cədvəli əsas həqiqətdir, tətbiq etmək istədiyiniz konfiqurasiya faylı yox. Əgər wildcard bağlantı qəsdəndirsə, onu daraldan komponent yenə də firewall olmalıdır.

ss -ltnp | grep -E ':(80|443)'

İdarəetmə interfeysləri üçün də eyni baxışı edin, çünki adətən təsadüfi ifşa onlarda olur. Sonra iki modeli ayrı-ayrılıqda yazın: proksi vasitəsilə açıq sayt və yalnız tunel vasitəsilə çatıla bilən idarəetmə interfeysi. Serverin VPN arxasında olması cümləsi bunların heç birini demir.