Mövcud HTTP proksisinə SSH yerli yönləndirməsi: iki loopback ünvanı

Təsdiqlənmiş proksiniz yalnız loopback-də dinləyən bir jump host üzərində işləyir, ona görə də o maşından kənarda heç nə ona çata bilməz. Sizə VPN və ya yeni proksi lazım deyil; sizə o maşının bir portunun öz maşınınızın bir portuna daşınması lazımdır. Yerli yönləndirmə məhz bunu edir və bir əmr üstəgəl bir tətbiq ayarı tələb edir. Qarışıqlıq adətən hansı loopback ünvanının hansı maşına aid olduğunu qarışdırmaqdan yaranır.

Sabit proksinin artıq mövcud olub-olmadığını müəyyənləşdirin

Bu texnika artıq işləyən bir xidməti yönləndirir. Uzaq hostda yalnız SSH demonu varsa və proksi yoxdursa, nə qədər yönləndirmə etsəniz də o yaranmaz və bağlantı uzaq tərəfdən rədd ediləcək. Proksinin bağlandığını, portunu və onun 127.0.0.1 üzərində, yoxsa konkret interfeys ünvanında dinlədiyini təsdiqləyin, çünki yönləndirmənin hədəfi məhz o ünvandır.

Bunu əvvəlcədən təsdiqləmək sizi heç vaxt heç nəyə qoşulmamış tuneli sazlamaqdan xilas edir.

Yönləndirməni qurun və əmri oxuyun

Lazım olan forma noutbukunuzda bir loopback portunu bağlayır və onu server tərəfindən proksinin serverin gördüyü ünvanına qoşur.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N uzaq əmri söndürür, -T isə termios ayrılmasını söndürür, çünki sizə qabıq deyil, tunel lazımdır. Birinci loopback ünvanı noutbukun dinlədiyi yerdir; ikincisi SSH serveri tərəfindən həll edilir, yəni oradakı 127.0.0.1 həmin maşındakı proksi deməkdir. ExitOnForwardFailure yerli port artıq tutulubsa, heç nə yönləndirməyən sessiya başlatmaq əvəzinə əmri ucadan uğursuz edir. Hədəf ünvanı serverin həll etdiyi kimi yazın, çünki yalnız noutbukunuzun həll edə bildiyi ad qarşı tərəfdə uğursuz olacaq.

Serverin öz siyasəti bütün bunlar işləməzdən əvvəl tətbiq olunur. AllowTcpForwarding buna icazə verməlidir və PermitOpen sessiyanın hansı təyinat və portlara çata biləcəyini məhdudlaşdıra bilər, yəni müştərinin qəbul etdiyi yönləndirməni server yenə də rədd edə bilər. Rədd müştəridə yönləndirmə və ya kanal xətası kimi görünür və o mesajı oxumaq əmri redaktə etməkdən daha sürətlidir.

Bir tətbiqi yönləndirməyə yönəldin

Tətbiqi http://127.0.0.1:13128 ünvanında HTTP proksisi istifadə etmək üçün konfiqurasiya edin, uzaq proksi tələb edirsə etimad məlumatları ilə birlikdə. HTTPS təyinatları üçün tətbiqin öz sertifikat yoxlamasını saxlayın, çünki proksi tuneli onu əvəz etmir. Bu, bir xidmətin sabit yönləndirməsidir, ona görə də tətbiqə proksi barədə məlumat verilməlidir, o, özü tapmalı deyil.

Hər hansı daimi konfiqurasiyadan əvvəl sürətli yoxlama: curl -x http://127.0.0.1:13128 -I https://example.com, bu proksinin dəstəkləməli olduğu HTTP CONNECT metodunu sınayır.

Səlahiyyəti olduğu yerdə saxlayın

Uzaq proksi hələ də hansı təyinat və metodlara icazə verdiyini qərar verir və SSH girişi hər hesaba səssizcə ümumi veb relesi verməməlidir. Noutbukda 127.0.0.1 ünvanına bağlanmaq portu yerli şəbəkənizə elan etməyin qarşısını alır və portu eyni maşındakı digər proseslərdən gizli etmir. Bu bağlamanı proksini paylaşmaq üçün wildcard ünvanı ilə əvəz etmək idarə olunmayan açıq relenin yaradılma üsuludur.

SSH transportu serverə qədər olan atlamanı qoruyur. Ondan sonra proksi öz bağlantısını açır, yəni bir təyinata düz HTTP sorğusu serverdən sonra da düz qalır, hərçənd birinci seqment şifrələnmişdi.

İki tərəfi yoxlayın, sonra təmizləyin

Yerli tunelin qurulması və uzaq xidmətin uğuru fərqli nəticələrdir və əmrin çıxış statusu sizə yalnız birincisi barədə deyir. Dinləyicinin mövcud olduğunu ss -ltn ilə yoxlayın, sonra icazə verilən bir tətbiq sorğusu və proksinin rədd etməli olduğu bir sorğu edin. Hər ikisi gözlənildiyi kimi davranırsa, yol realdır; tunel işləyirsə və hər sorğu uğursuz olursa, proksi rədd edir və ya təyinata çata bilmir.

Bitirdikdə, sahib SSH prosesini dayandırın, proksi ayarını tətbiqdən silin və tapşırıqdan uzun yaşayan dinləyici buraxmaq əvəzinə yerli portun yox olduğunu təsdiqləyin.