Kekalkan atau SNAT IP klien VPN di sempadan awan

Mengekalkan alamat klien VPN sehingga ke aplikasi menjadikan setiap baris log dan setiap entri senarai benaran bermaksud perkara yang sama. Menulis semula di tepi awan menjadikan jadual penghalaan lebih mudah dan log kurang berguna. Kedua-dua pilihan tidak salah dengan sendirinya, dan hujah yang menentukannya jarang berkaitan prestasi. Tiga syarat menentukannya: sama ada aplikasi mesti tahu manusia mana yang bersambung, sama ada fabrik awan akan menerima sumber yang ingin anda hantar, dan siapa yang sanggup memikul tanggungjawab laluan balik selepas itu.

Tiga syarat menentukannya

Mulakan dengan keperluan aplikasi, bukan dengan rajah rangkaian. Jika kebenaran atau audit bergantung pada alamat klien individu, maka mengekalkannya ialah keperluan fungsi dan menterjemahkannya ialah kemunduran. Jika aplikasi hanya perlu tahu bahawa trafik tiba melalui laluan akses jauh, alamat yang diterjemah sudah mencukupi dan jauh lebih murah untuk dikendalikan.

Syarat kedua bersifat mekanikal. Rangkaian maya tidak mempercayai secara automatik paket yang mendakwa alamat yang tidak diberikan kepada antara muka penghantar. Kebanyakan fabrik awan menguatkuasakannya, dengan cara dan nama yang berbeza, dan reka bentuk yang mengabaikannya akan kelihatan betul dalam rajah dan gagal secara senyap dalam pengeluaran.

Syarat ketiga bersifat organisasi. Mengekalkan sumber bermakna jadual penghalaan subnet aplikasi mesti menunjuk balik ke gerbang untuk awalan klien, dan setiap pasukan yang menambah subnet kemudiannya mesti memastikan laluan itu konsisten. Itu kos kecil sekali, dan kos berulang merentas berpuluh-puluh akaun. Tentukan siapa yang membayarnya sebelum anda menjanjikan tingkah laku itu.

Laluan bukan kebenaran untuk memalsukan

Menambah laluan balik memberitahu subnet anda ke mana balasan harus pergi. Ia tidak memberitahu fabrik bahawa instans yang memajukan paket itu dibenarkan mengeluarkannya dengan sumber asing. Di AWS kawalan yang berkaitan ialah pemeriksaan sumber dan destinasi, dan ia kelihatan bagi setiap instans:

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

Matikannya hanya untuk instans yang kerja terdokumentasinya ialah pemajuan, dan bukan untuk apa-apa yang lain. Setiap VM aplikasi yang membiarkan pemeriksaan itu dihidupkan ialah satu mesin kurang yang boleh digunakan untuk mengeluarkan trafik dengan sumber pinjaman. Jika platform anda bukan AWS, cari tetapan anti-pemalsuan atau alamat dibenarkan yang setara dan bukannya menganggap tingkah laku itu berpindah.

Tangkapan paket pantas menyelesaikan persoalan lebih cepat daripada membaca konsol. Jika balasan keluar dan klien tidak pernah melihatnya, fabriklah yang membuang sumber palsu itu, bukan aplikasi yang gagal.

Apa yang dibeli terjemahan dan apa kosnya

Menulis semula sumber di gerbang menghapuskan masalah laluan balik. Aplikasi melihat satu alamat yang sudah diketahuinya cara mencapainya, dan awalan klien tidak perlu muncul dalam jadual penghalaan awan. Di Linux peraturannya satu baris, dan wajar menulis versi paling sempit yang anda mampu:

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

Perhatikan apa yang kini direkodkan aplikasi: 10.40.3.10 untuk setiap pengguna, pada setiap sambungan, selama-lamanya. Mana-mana senarai alamat dibenarkan yang dibina atas nilai itu kini memberi akses kepada seluruh populasi akses jauh, dan mana-mana semakan insiden mesti kembali ke gerbang untuk menjawab siapa ini.

Penyelesaiannya bukan meninggalkan terjemahan, tetapi berhenti berpura-pura bahawa alamat itu identiti. Bawa identiti klien dalam medan yang disahkan, logkannya di gerbang bersama tuple yang diterjemah, dan biarkan aplikasi bergabung dengannya. Tanpa kunci gabungan, terjemahan mengubah masalah rangkaian menjadi masalah forensik yang kekal.

Geganti adalah antara muka yang berbeza

Proksi songsang di hadapan aplikasi memintas persoalan laluan yang dihalakan sepenuhnya. Proksi membuka sambungan backendnya sendiri, jadi awalan klien tidak perlu boleh dihalakan di dalam rangkaian maya, dan aplikasi boleh menerima identiti dalam pengepala yang ditetapkan proksi.

Pengepala itu hanya boleh dipercayai apabila backend menerimanya daripada proksi dan daripada tiada yang lain. Dalam istilah nginx itu bermakna menamakan rakan yang dipercayai secara eksplisit dan bukannya mempercayai apa sahaja yang tiba:

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

Mana-mana klien yang boleh mencapai backend secara langsung boleh memalsukan pengepala yang sama, jadi backend mesti tidak boleh dicapai kecuali melalui proksi. Itu fakta tembok api, bukan pendapat konfigurasi, dan itulah andaian yang orang langkau apabila menyalin coretan itu.

Geganti juga mengubah apa yang anda beli. Anda mendapat identiti peringkat aplikasi dan tempat semula jadi untuk merekodnya; anda melepaskan keluasan, kerana setiap protokol baharu memerlukan sokongan proksinya sendiri. Bagi perkhidmatan HTTP pertukaran itu biasanya baik, dan bagi apa-apa yang bukan HTTP biasanya tidak tersedia langsung.

Tuliskan apa yang dilihat setiap sempadan

Apa pun yang anda pilih, semakan reka bentuk harus berakhir dengan satu jadual yang menamakan alamat sumber dan identiti yang boleh dibuktikan pada setiap lompatan. Tanpanya, insiden pertama menghasilkan tiga pasukan yang masing-masing menerangkan klien yang berbeza.

Kemudian pilih. Kekalkan sumber apabila kebenaran aplikasi benar-benar bergantung pada alamat klien dan anda boleh memikul laluannya. Terjemah apabila tidak dan anda boleh membawa identiti di luar jalur, dan gunakan panduan AWS untuk instans pemajuan untuk tetapan pemajuan khusus platform. Berpaling kepada geganti apabila perkhidmatan bertutur HTTP dan anda mahu identiti berhenti menjadi alamat.