Üç mühəndisdən daxili xidmətə necə çatdıqlarını soruşun və üç fərqli layihə alacaqsınız: veb-proxy, SSH tuneli və ya tam VPN. Hər üçü uzaq xidməti əlçatan edə bilər və hər üçü trafiki başqa yerdən gəlirmiş kimi göstərə bilər. Fərqlər sonra, istifadə olunan protokol seçilmiş alətin güman etdiyi protokol olmadıqda üzə çıxır. Sürətli brauzer yoxlamasından keçən layihə, müraciətə səbəb olan tətbiqdə adətən uğursuz olur.

İki faktdan qərar verin: hansı protokollar keçməlidir və iştirak edən adları kim həll edə bilər. Qalan hər şey üstünlük məsələsidir.

Proxy yalnız başa düşdüyünü ötürür

Veb-proxy qurulduğu protokolu təhlil edir. Müştəri ona sorğu verir, o da həmin sorğunu irəli ötürür, buna görə proxy ayarı olmayan tətbiq ümumiyyətlə iştirak etmir. HTTPS üçün müştəriyə qeyri-şəffaf kanal lazımdır, proxy bunu sorğunu oxumaqla deyil, CONNECT vasitəsilə təmin edir.

SSH dinamik yönləndirməsi SOCKS danışan yerli port açır və bu port TCP axınını müştərinin göstərdiyi istənilən təyinatına ötürür. TCP üzərində qurulan protokollar adətən onun vasitəsilə işləyir. UDP işləmir, alət bunu açıq şəkildə əlavə etmirsə. Yerli yönləndirmə daha dardır: bir yerli port bir sabit host və porta bağlanır, bu da yalnız bir məlum xidmətə xidmət edir.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN paketləri hərəkət etdirir. Müştərinin tunelə yönəltdiyi hər şey ondan keçir, UDP və ICMP də daxil, buna görə tək bağlantıya deyil, şəbəkə tələbinə uyğundur.

Adı kiminsə həll etməsi lazımdır

Hədəf ad yalnız uzaq şəbəkənin DNS-ində varsa, axtarışı aparan maşın həmin zonanı görə bilməlidir. Veb-proxy axtarışı özü edir, buna görə daxili ad onun vasitəsilə işləyir, hətta noutbuk adı ümumiyyətlə həll edə bilməsə də. SOCKS da eyni cür davrana bilər, amma yalnız müştəri adı ötürsə, artıq həll etdiyi ünvana qoşulmaq əvəzinə. Bu seçim serverdə deyil, müştəridədir.

curl ayrılığı aydın göstərir: bir bayraq host adını proxy-yə ötürür, digəri onu əvvəlcə yerli həll edir. Yerli həll ilə yalnız daxili olan ad hər hansı tunelə toxunmadan uğursuz olur və xəta əslində DNS qərarı olan şeyi proxy-nin üstünə atır.

VPN üçüncü yolu seçir: özəl həlledicini və axtarış domenini marşrutların yanında quraşdırır. Bu rahatdır və tanış bir illüziya yaradır: cavab verməyən həlledici ilə mövcud olan marşrut, paketlər o tərəfə çatsa da, ölü tunel kimi görünür.

Şəbəkə yalnız bir çıxışa icazə verdikdə

Bir çox korporativ şəbəkə xarici bağlantılara yalnız autentifikasiyalı veb-proxy vasitəsilə icazə verir. OpenVPN və SSH orada işlədilə bilər: birincisi öz nəqliyyatını proxy-dən tunellə, ikincisi kiçik CONNECT köməkçisini işə salan proxy əmri ilə.

TCP üzərində qurulan tunellər bu məhdudiyyətə dözür, UDP əsaslı VPN isə dözmür, bu da evdə işləyib ofisdə uğursuz olan çoxlu konfiqurasiyanı izah edir. İkinci xərci gözdən qaçırmaq asandır: proxy-li TCP bağlantısı içində daşınan TCP tunelinin artıq yenidən ötürmə edən iki qatı var və itki zamanı bu cütlük heç bir qatın təkbaşına yaratmadığı şəkildə dayanır.

Araçıları zəncirləmək qat seçməkdən fərqli sualdır. İkinci proxy və ya Tor əlavə etmək kimin nəyi müşahidə etdiyini dəyişir və zəncirdəki mövqe hansı hopun şifrəli mətni gördüyünü müəyyən edir.

Sıra hopların sayından daha vacibdir. Xarici hop şifrəli axını izləyir, daxili hop isə daşıdığı açıq mətni görür, buna görə zəncir ən diqqətsiz halqası qədər gizlidir. Protokolları hoplar arasında qarışdırmaq bunu avtomatik yaxşılaşdırmır. Çox vaxt uğursuzluq rejimlərini düşünməyi çətinləşdirir.

Saxta ünvan seçimlərdən biri deyil

Paketləri başqasının mənbə ünvanı ilə düzəltmək faydalı heç nə vermir: cavablar əsl sahibinə gedir və əksər şəbəkələr trafiki tamamilə atır. Araçı məhz mənbənin uydurula bilmədiyi üçün tələb olunur və bu, hər üç layihənin dürüst əsaslandırmasıdır.

Bu həm də onların hər birinin nə iddia edə biləcəyini məhdudlaşdırır. Müəyyən ünvandan gəlirmiş kimi görünmək, o ünvanın qanuni olaraq harada verildiyi və onu kimin marşrutlaşdıra biləcəyi ilə bağlı sualdır, hansı alətin başlığı saxtalaşdıra bilməsi ilə deyil. Əgər layihə başqa cür fərz edirsə, fərz onu filtrləyən ilk provayderdə uğursuz olur. Fərziyyəni yazın ki, uğursuzluq gələndə tanınsın.

Protokollara və adlara görə qərar verin

Tək veb müştəri tək veb xidmətə ehtiyac duyursa və proxy ayarları varsa, proxy seçin. Bir neçə məlum TCP xidməti kifayətdirsə və SSH girişi artıq varsa, SSH tuneli seçin. Bir neçə tətbiq, TCP olmayan trafik, özəl DNS və ya təkrar istifadə oluna bilən yol tələbin hissəsidirsə, VPN seçin.

Sonra həqiqi müştəri və həqiqi adla yoxlayın. Proxy vasitəsilə səhifə yükləmək sizə UDP haqqında heç nə öyrətmir, bir aləti SOCKS üzərində işlətmək isə sistem həlledicisi haqqında heç nə öyrətmir. Prosesin hansı yerli ünvana bağlandığını və hansı həlledicinin cavab verdiyini oxuyun. İşləyən yol ilə bir dəfə təsadüfən işləmiş yol arasındakı fərq budur.

Əlaqəli məqalələr