Bulud sərhədində VPN müştəri IP-lərini qoru və ya SNAT et

VPN müştərisinin ünvanını tətbiqə qədər saxlamaq hər jurnal sətrinin və hər icazə siyahısı qeydinin eyni mənanı verməsinə səbəb olur. Onu bulud kənarında yenidən yazmaq marşrut cədvəlini sadələşdirir və jurnalları daha az faydalı edir. Seçimlərin heç biri tək başına səhv deyil və bunu həll edən arqument nadir hallarda performansla bağlı olur. Üç şərt buna qərar verir: tətbiq hansı insanın qoşulduğunu bilməlidirmi, bulud strukturu göndərmək istədiyiniz mənbəni qəbul edəcəkmi və geri marşrutun məsuliyyətini sonradan kim öz üzərinə götürəcək.

Üç şərt buna qərar verir

Tətbiqin tələbindən başlayın, şəbəkə diaqramından yox. Əgər avtorizasiya və ya audit fərdi müştəri ünvanından asılıdırsa, onun qorunması funksional tələbdir və tərcümə reqressiyadır. Əgər tətbiq yalnız trafikin uzaq giriş yolu ilə gəldiyini bilməlidirsə, tərcümə edilmiş ünvan kifayətdir və istismarı xeyli ucuzdur.

İkinci şərt mexanikidir. Virtual şəbəkə göndərən interfeysə təyin edilməmiş ünvanı iddia edən paketə avtomatik etibar etmir. Bulud strukturlarının çoxu bunu müxtəlif üsullarla və müxtəlif adlarla tətbiq edir və buna məhəl qoymayan dizayn diaqramda düzgün görünəcək, istehsalatda isə səssizcə düşəcək.

Üçüncüsü təşkilatidir. Mənbələri qorumaq o deməkdir ki, tətbiq alt şəbəkəsinin marşrut cədvəli müştəri prefiksi üçün şlüzə geri baxmalıdır və sonradan alt şəbəkə əlavə edən hər komanda həmin marşrutu ardıcıl saxlamalıdır. Bu, bir dəfə kiçik bir xərcdir və onlarla hesab boyunca təkrarlanan bir xərcdir. Davranışa söz verməzdən əvvəl bunu kimin ödədiyini qərarlaşdırın.

Marşrut saxtakarlıq üçün icazə deyil

Geri marşrut əlavə etmək alt şəbəkənizə cavabların hara getməli olduğunu deyir. O, struktura bu paketləri yönləndirən instansın onları yad mənbə ilə göndərməyə icazəsi olduğunu demir. AWS-də müvafiq nəzarət mənbə və təyinat yoxlamasıdır və hər instans üzrə görünür:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Bunu yalnız sənədləşdirilmiş vəzifəsi yönləndirmə olan instans üçün söndürün, başqa heç nə üçün yox. Yoxlamanı aktiv saxlayan hər tətbiq VM-i borc alınmış mənbə ilə trafik göndərmək üçün istifadə oluna biləcək bir maşın azdır. Platformanız AWS deyilsə, davranışın olduğu kimi keçəcəyini fərz etmək əvəzinə ekvivalent anti-spoofing və ya icazəli ünvan parametrini axtarın.

Sürətli bir paket tutması məsələni konsolu oxumaqdan tez həll edir. Əgər cavablar çıxırsa və müştəri onları heç vaxt görmürsə, tətbiq deyil, struktur saxtalaşdırılmış mənbəni atır.

Tərcümə nə qazandırır və nəyə başa gəlir

Mənbəni şlüzdə yenidən yazmaq geri yol problemini aradan qaldırır. Tətbiq artıq necə çatacağını bildiyi bir ünvan görür və müştəri prefiksinin bulud marşrut cədvəlində görünməsi heç vaxt lazım olmur. Linuxda qayda bir sətirdir və bacardığınız ən dar versiyanı yazmağa dəyər:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Diqqət yetirin ki, tətbiq artıq nə qeyd edir: 10.40.3.10 hər istifadəçi üçün, hər bağlantıda, əbədi olaraq. Bu dəyər üzərində qurulmuş hər ünvan icazə siyahısı artıq bütün uzaq giriş populyasiyasına giriş verir və hər insident araşdırması bunun kim olduğunu cavablandırmaq üçün şlüzə qayıtmalıdır.

Həll tərcümədən əl çəkmək deyil, ünvanın kimlik olduğunu iddia etməyi dayandırmaqdır. Müştəri kimliyini autentifikasiya edilmiş sahədə daşıyın, onu şlüzdə tərcümə edilmiş tupla birlikdə qeyd edin və tətbiqin həmin üzərində birləşməsinə imkan verin. Birləşmə açarı olmadan tərcümə şəbəkə problemini daimi bir forensik problemə çevirir.

Relay fərqli interfeysdir

Tətbiqin qarşısındakı tərs vəkil marşrutlaşdırılmış yol məsələsini tamamilə yan keçir. Vəkil öz backend bağlantısını açır, buna görə müştəri prefiksinin virtual şəbəkə daxilində marşrutlaşdırıla bilən olması heç vaxt lazım deyil və tətbiq kimliyi vəkilin təyin etdiyi başlıqda ala bilər.

Bu başlıq yalnız backend onu vəkildən qəbul edib başqa heç nədən qəbul etmədikdə etibarlıdır. nginx baxımından bu, gələn hər şeyə inanmaq əvəzinə etibarlı həmyaşıdı açıq şəkildə adlandırmaq deməkdir:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Backend-ə birbaşa çata bilən hər müştəri eyni başlığı saxtalaşdıra bilər, ona görə backend yalnız vəkil vasitəsilə əlçatan olmalıdır. Bu firewall faktıdır, konfiqurasiya rəyi deyil və insanların parçanı kopyalayarkən atladığı fərziyyə budur.

Relay həm də nə aldığınızı dəyişir. Tətbiq səviyyəsində kimlik və onu qeyd etmək üçün təbii bir yer alırsınız; ümumiliyi itirirsiniz, çünki hər yeni protokol öz vəkil dəstəyini tələb edir. HTTP xidmətləri üçün bu mübadilə adətən yaxşıdır və HTTP olmayan hər şey üçün adətən heç mövcud deyil.

Hər sərhədin nə gördüyünü yazın

Nə seçsəniz də, dizayn baxışı hər hoppda mənbə ünvanını və sübut edilə bilən kimliyi adlandıran bir cədvəllə bitməlidir. O olmadan ilk insident hər biri fərqli müştəri təsvir edən üç komanda yaradır.

Sonra seçin. Tətbiqin avtorizasiyası həqiqətən müştəri ünvanından asılı olduqda və marşrutu öz üzərinizə götürə bildikdə mənbəni qoruyun. Belə olmadıqda və kimliyi bantdan kənar daşıya bildikdə tərcümə edin və platformaya xas yönləndirmə parametrləri üçün AWS yönləndirmə instansı təlimatından istifadə edin. Xidmət HTTP danışdıqda və kimliyin ümumiyyətlə ünvan olmağına son qoymaq istədikdə relay-a müraciət edin.