Pertahankan atau SNAT IP klien VPN di batas cloud

Mempertahankan alamat klien VPN sampai ke aplikasi membuat setiap baris log dan setiap entri daftar izin berarti hal yang sama. Menulis ulang alamat itu di tepi cloud membuat tabel rute lebih sederhana dan log kurang berguna. Tidak ada pilihan yang salah dengan sendirinya, dan argumen yang memutuskannya jarang soal kinerja. Tiga kondisi memutuskannya: apakah aplikasi harus tahu siapa orang yang terhubung, apakah kain cloud akan menerima sumber yang hendak Anda kirim, dan siapa yang bersedia memikul tanggung jawab rute balik setelahnya.

Tiga kondisi memutuskannya

Mulailah dari kebutuhan aplikasi, bukan dari diagram jaringan. Jika otorisasi atau audit bergantung pada alamat klien individual, maka mempertahankannya adalah kebutuhan fungsional dan menerjemahkannya adalah kemunduran. Jika aplikasi hanya perlu tahu bahwa lalu lintas datang melalui jalur akses jarak jauh, alamat yang diterjemahkan sudah cukup dan jauh lebih murah dioperasikan.

Kondisi kedua bersifat mekanis. Jaringan virtual tidak otomatis memercayai paket yang mengklaim alamat yang tidak ditetapkan ke antarmuka pengirim. Sebagian besar kain cloud menegakkannya, dengan cara dan nama yang berbeda, dan desain yang mengabaikannya akan terlihat benar di diagram dan diam-diam gagal di produksi.

Kondisi ketiga bersifat organisasi. Mempertahankan sumber berarti tabel rute subnet aplikasi harus menunjuk balik ke gateway untuk prefiks klien, dan setiap tim yang menambahkan subnet setelahnya harus menjaga rute itu tetap konsisten. Itu biaya kecil sekali, dan biaya berulang di puluhan akun. Putuskan siapa yang membayarnya sebelum Anda menjanjikan perilaku itu.

Rute bukan izin untuk memalsukan

Menambahkan rute balik memberi tahu subnet Anda ke mana balasan harus pergi. Itu tidak memberi tahu kain bahwa instans yang meneruskan paket tersebut berhak mengirimnya dengan sumber asing. Di AWS, kontrol yang relevan adalah pemeriksaan sumber dan tujuan, dan itu terlihat per 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

Matikan hanya untuk instans yang pekerjaan terdokumentasinya adalah penerusan, dan tidak untuk yang lain. Setiap VM aplikasi yang membiarkan pemeriksaan tetap aktif adalah satu mesin lebih sedikit yang dapat dipakai untuk mengirim lalu lintas dengan sumber pinjaman. Jika platform Anda bukan AWS, carilah pengaturan anti-pemalsuan atau alamat yang diizinkan yang setara, bukan mengasumsikan perilakunya ikut terbawa.

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

Apa yang dibeli penerjemahan dan apa biayanya

Menulis ulang sumber di gateway menghilangkan masalah jalur balik. Aplikasi melihat satu alamat yang sudah diketahuinya cara mencapainya, dan prefiks klien tidak pernah harus muncul di tabel rute cloud. Di Linux aturannya satu baris, dan layak menulis versi tersempit yang Anda bisa:

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 sekarang dicatat aplikasi: 10.40.3.10 untuk setiap pengguna, pada setiap koneksi, selamanya. Daftar alamat yang diizinkan yang dibangun dari nilai itu kini memberi akses ke seluruh populasi akses jarak jauh, dan setiap tinjauan insiden harus kembali ke gateway untuk menjawab siapa orang ini.

Solusinya bukan meninggalkan penerjemahan, melainkan berhenti berpura-pura bahwa alamat adalah identitas. Bawa identitas klien dalam bidang yang terautentikasi, catat di gateway bersama tuple yang diterjemahkan, dan biarkan aplikasi bergabung berdasarkan itu. Tanpa kunci penggabungan, penerjemahan mengubah masalah jaringan menjadi masalah forensik permanen.

Relay adalah antarmuka yang berbeda

Proksi terbalik di depan aplikasi menghindari pertanyaan jalur terutek sepenuhnya. Proksi membuka koneksi backend-nya sendiri, sehingga prefiks klien tidak perlu dapat dirutekan di dalam jaringan virtual, dan aplikasi dapat menerima identitas dalam header yang ditetapkan proksi.

Header itu hanya dapat dipercaya ketika backend menerimanya dari proksi dan dari yang lain tidak. Dalam istilah nginx itu berarti menamai peer tepercaya secara eksplisit alih-alih memercayai apa pun yang datang:

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

Setiap klien yang dapat menjangkau backend secara langsung dapat memalsukan header yang sama, jadi backend harus tidak terjangkau kecuali melalui proksi. Itu fakta firewall, bukan pendapat konfigurasi, dan itulah asumsi yang orang lewati ketika menyalin cuplikan itu.

Relay juga mengubah apa yang Anda beli. Anda mendapat identitas tingkat aplikasi dan tempat alami untuk mencatatnya; Anda melepaskan keumuman, karena setiap protokol baru membutuhkan dukungan proksinya sendiri. Untuk layanan HTTP perdagangan itu biasanya baik, dan untuk apa pun yang bukan HTTP biasanya sama sekali tidak tersedia.

Tuliskan apa yang dilihat setiap batas

Apa pun yang Anda pilih, tinjauan desain harus berakhir dengan satu tabel yang menyebut alamat sumber dan identitas yang dapat dibuktikan di setiap lompatan. Tanpanya, insiden pertama menghasilkan tiga tim yang masing-masing menggambarkan klien yang berbeda.

Lalu pilih. Pertahankan ketika otorisasi aplikasi benar-benar bergantung pada alamat klien dan Anda dapat memikul rutenya. Terjemahkan ketika tidak demikian dan Anda dapat membawa identitas di luar pita, dan gunakan panduan AWS untuk instans penerusan untuk pengaturan penerusan yang khusus platform. Beralihlah ke relay ketika layanan berbicara HTTP dan Anda ingin identitas berhenti menjadi alamat.