Bir bulud xidməti üçün yerli TLS, SSH yönləndirməsi və ya VPN

Sual nadir hallarda iki bulud maşını arasında nəyisə şifrələmək lazımdırmı olur; əsas məsələ hansı interfeysi şifrələdiyiniz və kimin kimin şəxsiyyətini yoxladığıdır. Mən bu söhbətlərə şəbəkə diaqramından deyil, xidmətdən başlayıram, çünki xidmət artıq nəyə ehtiyacı olduğunu bilir. Üç sərhəd halların çoxunu əhatə edir: tətbiqin öz TLS-i, SSH üzərindən yönləndirilən tək TCP portu və hər iştirakçıya ünvan verən marşrutlaşdırılmış örtük. Onlar güclərinə görə deyil, problemin nə qədərini əhatə etdiklərinə görə sıralanır.

Şəbəkə ilə deyil, xidmətlə başlayın

Prosesdən bayıra doğru gedin. Hansı protokolda danışır, müştəri hansı adı yoxlayacaq və ümumiyyətlə kimin bağlantı açmaq hüququ var? Bu üç cavab istənilən müqayisə cədvəlindən daha sürətli variantları aradan qaldırır və xidmətin öz konfiqurasiyası adətən onları bir neçə dəqiqə ərzində cavablandırır.

api.internal.example üçün sertifikatla 8443 portunda artıq HTTPS təqdim edən kiçik daxili API götürün. Hostda ss -ltnp onun nəyə bağlandığını, openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example isə sertifikatın müştərinin həqiqətən istifadə edəcəyi ad üçün etibarlı olub-olmadığını göstərir. Əgər hər ikisi sağlamdırsa, xidmət öz axınını qoruya bilər və yalnız əlçatanlıq işi qalır. Bu, şəbəkə qurmaqdan qat-qat kiçik bir problemdir.

Addım 1: xidmət özünü qoruyurmu?

Bu, uyğun gəldikdə seçiləcək variantdır və komandaların güman etdiyindən daha tez-tez uyğun gəlir. Xidmətin şifrələməsi müştəri ilə server arasındakı bütün yolu, o cümlədən aradakı hər keçidi əhatə edir və ortadan keçən heç bir tunel bunu yaxşılaşdırmır. Gözlənilən adı və etimadı açıq şəkildə qurğulayın, müştərinin standart anbarında təsadüfən olana güvənməyin.

Şifrələmə və əlçatanlıq ayrı-ayrı nəzarətlər olaraq qalır və bu variant məhz onları birləşdirdikdə səhv edir. Məhdudiyyətsiz ictimai dinləyicidəki TLS xidməti hələ də hər kəsin bağlantı cəhdlərini qəbul edir, ona görə dinləyici və şəbəkə qaydaları yükün qorunduğundan asılı olmayaraq ayrıca əhatələnməlidir. Sonra asılılıqları yoxlayın, çünki TLS üzərindəki API kəşfiyyat son nöqtəsi, admin portu və ya yanındakı toplu ötürmə kanalı haqqında heç nə demir. Onların hər biri öz cavabını tələb edir və bir qorunmayan qardaş bütün sərhədi uydurma etməyə kifayətdir.

Addım 2: tək TCP portu bütün tələbdir?

Tələb həqiqətən tək TCP portudursa, yönləndirmə işləyən ən kiçik şeydir. SSH yerli yönləndirməsi həmin portu artıq mövcud olan autentifikasiyalı bağlantıdan keçirir.

Forma ssh -N -L 8443:127.0.0.1:8443 [email protected]-dir və vacib detal hədəf ünvandır: 127.0.0.1 uzaq tərəfdə həll olunur, buna görə xidmətə bağlantı noutbukdan deyil, bastiondan açılır. Yerli dinləyicini -L 127.0.0.1:8443:... kimi dar bağlayın ki, xidməti təsadüfən öz yerli şəbəkənizə dərc etməyəsiniz. Server tərəfində müştərinin düzgün davranacağına güvənmək əvəzinə hesabın nəyi yönləndirə biləcəyini məhdudlaşdırın. PermitOpen, AllowTcpForwarding local və GatewayPorts no standartı ümumi təyinatlı releydən xüsusi kanal düzəldən üç parametrdir.

Müqavilə hər iki istiqamətdə dardır. SSH öz kanalını qoruyur və bastiondan başqa tətbiqə əlavə keçid öz mühafizəsini tələb edir. Yalnız bastionun loopbackında dinləyən xidmətin məruz qalması başqa şəbəkədən əldə ediləndən tamamilə fərqlidir və yönləndirmə bunu dəyişmir. Tətbiqin autentifikasiyasını və TLS yoxlamalarını yerində saxlayın, tuneli onların əvəzi hesab etməyin.

Bu, bir sahibi olan bir bağlantı üçün yaxşı işləyir. Geniş miqyasda bu sistemə çevrilir: yerli port toqquşmaları, nəzarət, açar rotasiyası və yenidən başlatmadan sonra yönləndirməni kimin yenidən işə saldığı sualı.

Addım 3: əsl tələb marşrutlaşdırmadır?

Bu siyahı ən kiçik variantın dürüst qiymətidir və buna görə komandalar sonda unudulmuş bir neçə fon əmrini idarə olunan bir şeylə əvəz edir. Əvəzləmə avtomatik olaraq VPN deyil. Tələb hələ də tək TCP portudursa, sənədləşdirilmiş sahibi olan nəzarətli yönləndirmə örtükdən daha ucuz işləyir və görə bildiyiniz şəkildə uğursuz olur. Zərifliyi ölçməzdən əvvəl əməliyyat sahibliyini ölçün.

Marşrutlaşdırma tələb olduqda o, düzgün cavaba çevrilir. Adi IP bağlantısına ehtiyac duyan bir neçə tətbiq, TCP yönləndirməsinin daşıya bilmədiyi protokollar və ya hostlar arasında köçən xidmətlər eyni istiqaməti göstərir.

Örtük iştirakçılara ünvan və marşrut verir, sonra əsl iş başlayır: üst-üstə düşməyən diapazonlar, marşrut sahibliyi, DNS, qeydiyyat, ləğv və bir həmkar yox olduqda nə olacağı. Bunların heç biri ünvanla birlikdə gəlmir. Örtüyə qəbul edilmiş həmkar da təyinatdakı hər əməliyyat üçün avtomatik səlahiyyətli deyil, ona görə xidmət səviyyəsində autentifikasiya qalır.

Bundan sonra nəyə sahibsiniz

Arxada qoyduğunuz qeydə iki şey aiddir. Birincisi, müştərinin yoxlaması gözlənilən şəxsiyyətdir, çünki bu sərhədlərin hər biri nəyisə işlətmək üçün ad yoxlaması yumşaldılan kimi səssizcə pisləşir. İkincisi, çıxarma addımıdır: giriş bitəndə hansı açar, hansı qayda və ya hansı marşrut yox olur və bunu kim edir.

Gəzinti başladığı yerdə, xidmətdə bitir. Faktiki trafiki əhatə edən və yoxlamaq istədiyiniz həmkarları yoxlayan sərhədi seçin, sonra girişin necə yeniləndiyini, izləndiyini və silindiyini yazın. OpenSSH istinadı dar müqavilə vəd etməzdən əvvəl yönləndirmə seçimlərini təsdiqləmək üçün yerdir. Çıxarma addımını bir cümlə ilə təsvir edə bilmirsinizsə, sərhəd problemdən böyükdür.