Yerli müştəri üçün S3 şlüzü, yoxsa interfeys son nöqtəsi?

Ofis şəbəkəsindən sayt VPN-i ilə S3-ə çatmaq statik marşrutun təkbaşına həll edə biləcəyi marşrutlaşdırma problemi deyil. Şlüz son nöqtəsi marşrut cədvəllərinə bağlanır və VPC daxilində yaranan sorğulara xidmət edir. İnterfeys son nöqtəsi subnet-lərinizdə şəxsi ünvanlı elastik şəbəkə interfeysləri yerləşdirir və həmin ünvanlara VPN və ya Direct Connect üzərindən yerli şəbəkədən çatmaq olar. Sorğunun haradan başladığı ikisindən hansına həqiqətən ehtiyacınız olduğunu müəyyən edir və DNS, təhlükəsizlik qrupu və siyasət işi bu cavabdan irəli gəlir.

Son nöqtə növlərini sorğunun başladığı yerə görə ayırın

Şlüz son nöqtəsi idarə olunan prefiks siyahısına işarə edən marşrut cədvəli qeydi kimi görünür. Onun şəbəkə interfeysi, təhlükəsizlik qrupu və öz şəxsi ünvanı yoxdur; buna görə də yerli host ona marşrut qura bilmir: o biri tərəfdə marşrut qurulacaq heç nə yoxdur. VPC daxilindən gələn trafik S3-ə çatır, çünki subnet marşrut cədvəli həmin prefiksi son nöqtəyə göndərir. Başqa yerdən gələn trafikdə izləyəcək belə qeyd yoxdur.

İnterfeys son nöqtəsi sizin seçdiyiniz subnet-lərdə şəbəkə interfeysləri toplusudur; hər birinin həmin subnet-dən şəxsi ünvanı və bağlı təhlükəsizlik qrupu var. Hibrid müştərinin istifadə edə biləcəyi forma budur, çünki bu, tunelinizin paketlər daşıya biləcəyi adi təyinatdır. Bu həm də o deməkdir ki, son nöqtə subnet-də ünvanlar sərf edir və onlar tükənə bilər.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Adı deyil, Type sütununu oxuyun. Tək VPC adətən eyni xidmət üçün hər iki növü saxlayır və yerli tətbiqinizin ehtiyac duyduğu qeyd interfeys qeydidir.

S3-ü sınaqdan keçirməzdən əvvəl interfeys ünvanına gedən yolu qurun

Üç şey eyni vaxtda doğru olmalıdır: yerli marşrutlaşdırıcının son nöqtə subnet-inə marşrutu var, həmin subnet-dən qayıdış yolu müştəri şəbəkəsinə çatır və son nöqtənin təhlükəsizlik qrupu müştərinin mənbə diapazonunu qəbul edir. Subnet-in şəbəkə ACL-i hər üçü keçdikdən sonra da paketi atmağa davam edə bilər, ona görə onu sonradan yada düşən deyil, dördüncü bənd kimi yoxlayın.

VPC-də hər hansı EC2 instansına işləyən marşrut bunlardan heç birini sübut etmir. O yalnız tunelin qalxdığını göstərir, yolun artıq bildiyiniz hissəsini. Son nöqtə ünvanını ayrıca sübut edin, sonra adın həmin ünvana həll olunduğunu sübut edin.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

Birinci əmr müştərinin hansı interfeysi istifadə edəcəyini göstərir. İkinci TCP əl sıxmasını sübut edir. Üçüncü, TLS-in son nöqtə adı üçün etibarlı sertifikatla tamamlandığını sübut edir; icazələri günahlandırmazdan əvvəl səhv ünvanı tutan yoxlama da elə budur.

Tətbiqin hansı DNS cavabı aldığını müəyyən edin

VPC-də interfeys son nöqtəsinin olması yerli SDK-nı özbaşına yönləndirmir. Müştəri ya AWS-in həmin son nöqtə üçün dərc etdiyi son nöqtəyə xas adı, ya da ofisdən həll oluna bilən etdiyiniz şəxsi host edilmiş zonanı istifadə edir.

Hibrid həll üçün yerli həllediciyə VPC-nin DNS görünüşünə dəstəklənən yol lazımdır, adətən Resolver inbound son nöqtəsi vasitəsilə. Şəxsi DNS-i onun hansı sorğu mənbələrinə təsir etdiyini anlamadan aktivləşdirmək, axtarışın ofisin çata bilmədiyi ünvan qaytarmasına səbəb olur. Parametr VPC həlledicisindən gələn sorğuların cavablarını dəyişir, hər yerdəki hər müştərininkini deyil.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Hər iki əmri tətbiq hostunda işə salın, VPC-dəki jump box-da deyil. Orada cavab verən həlledici yükünüzün istifadə etdiyidir və başqa hostdan fərqli cavab bu dizaynda qarışıqlığın ən geniş yayılmış mənbəyidir.

Əlçatanlıq avtorizasiya deyil

Son nöqtəyə çatan sorğu hələ də səlahiyyətli bir subyekt və tətbiq olunan bucket icazəsi tələb edir. Son nöqtə siyasəti son nöqtənin icazə verdiklərini daralda bilər, bucket siyasəti isə onu yenidən daralda bilər. İnterfeysə çatmaq çağıranın hansı obyektləri oxuya biləcəyi barədə heç nə demir.

Hər iki istiqaməti sınayın: nəzərdə tutulan bucket-ə qarşı zərərsiz, səlahiyyətli bir çağırış və siyasətdən kənar kimlik və ya resurs üçün rədd edilməsi gözlənilən bir çağırış. Nəticə ilə birlikdə son nöqtə adını, həll olunmuş ünvanı və siyasət kontekstini saxlayın ki, növbəti şəxs onu təkrarlaya bilsin. Siyasət növünü adlandıran rədd bir saatlıq təxmini qənaət edir.

Nəhayət, təchizatdan əvvəl iki variantın qiymətini hesablayın. İnterfeys son nöqtəsi interfeys saatına və gigabayta görə hesablanır, şlüz son nöqtəsi isə yox, və bu fərq yalnız VPC tərəfindən girişə ehtiyac duyan bir çox aşağı həcmli yük üçün məsələni həll edir.