un — Pemisahan Ingress & Egress

un

tamu

1 / ?

kembali ke pelajaran

Dua Arah Traffic, Satu Kotak

Selamat Datang

Banyak diagram arsitektur menunjukkan traffic yang pergi satu arah: klien di atas, server di bawah, panah menuju ke bawah. Kenyataannya, traffic pergi ke dua arah.

Ingress: luar klien mencapai layanan Anda melalui jalur ini. Sebuah reverse proxy di tepi jaringan Anda menghentikan TLS, menyalurkan permintaan, & menegakkan kebijakan akses.

Egress: layanan Anda mencapai layanan luar melalui jalur ini. Menghubungi pengolahan pembayaran API, memuat sasaran webhook, mengirim permintaan ke mitra. Sering melalui forward proxy atau NAT gateway dengan daftar izin.

Banyak arsitektur dimulai dengan satu kotak yang mengatasi keduanya. Ini berhasil, sampai hari ketika itu tidak. Mode kegagalan halus, muncul hanya setelah cukup layanan internal ada, & mengajarkan pelajaran penting tentang pembagian kepedulian.

Setelah mengikuti pelajaran ini Anda akan memahami:

- Mengapa ingress & egress mewakili pola traffic yang berbeda secara fundamental dengan sumbu skala & mode kegagalan yang berbeda

- NAT Hairpin & mengapa proxy yang mencoba menghubungi dirinya sendiri gagal

- Cabang arsitektur: satu kotak menjadi dua, & apa yang setiap satu miliki secara eksklusif

- Kemanangan isolasi keamanan: setiap sisi dapat menutup diri kepada peer sebenarnya yang diizinkan

- Cara mengidentifikasi ketika desain satu-kotak Anda telah mencapai ambang di mana pemisahan diperlukan

Mengapa Arah-Arah Ini Membutuhkan Alat Yang Berbeda

Dua Beban Kerja Yang Berbeda di Satu Batas Jaringan

Karakteristik traffic ingress:

- Diinisialisasi oleh pihak luar (internet yang luas)

- Volume yang berkorespondensi dengan basis pengguna Anda

- Penyelesaian TLS, penyaluran permintaan, batasan kecepatan per sumber

- Kepriadian pertahanan dalam-dalam: DDoS, penyalahgunaan, scraping

- IP publik harus menerima koneksi dari siapa saja

Karakteristik traffic egress:

- Diinisialisasi oleh layanan Anda sendiri (sebuah set klien yang kecil & dikenal)

- Volume yang berkorespondensi dengan pola panggilan layanan ke-layanan & API eksternal

- Allowlisting IP sumber dari endpoint remote (anda memiliki satu IP keluaran tetap yang mitra percayai)

- Kesulitan keamanan dalam kedalaman: pencurian data, layanan internal yang terkorupsi yang menghubungi keluar

- Seharusnya menolak koneksi dari siapa pun selain layanan sendiri

Asimetri kunci: ingress menerima lalu lintas dari dunia; egress menerima lalu lintas hanya dari layanan sendiri. Menempatkan mereka pada mesin yang sama berarti mesin tersebut harus dapat diakses dari dunia (untuk ingress) & hanya dapat diakses oleh layanan sendiri (untuk egress). Aturan firewall yang memenuhi satu bekerja melawan yang lain.

Jalan pertumbuhan: proyek kecil dapat menyembunyikan keduanya di balik satu IP & alat, karena volume kecil & daftar allowlist IP mitra. Seiring pertumbuhan proyek, gesekan antara dua peran meningkat, & suatu hari mode kesalahan spesifik (hairpin NAT) memaksa pemisahan.

Ingress vs egress: sumber yang berbeda, tujuan yang berbeda, persyaratan yang berbeda

Sebuah startup kecil menjalankan segalanya (ingress reverse proxy, egress forward proxy / NAT, layanan internal) di satu VM dengan satu IP publik. Mereka masih cukup awal sehingga ini terlihat baik-baik saja. Namakan dua mode kegagalan khusus atau penderitaan operasional yang desain ini akan temui saat mereka tumbuh, & untuk setiap yang menjelaskan penyebab yang mendasarinya.

The Bug That Forces the Split

Cerita Outage yang Distersikan

Gambaran arsitektur cabang yang nyata yang terjadi di armada produksi. Nama-nama di bawah ini telah dirubah; bentuknya identik dengan yang tim hadapi di alam bebas.

Perusahaan menjalankan server proxy tunggal di 203.0.113.5. Ini mengatur ingress (port 443 untuk pengguna) & egress (port 1080 SOCKS5 untuk layanan internal yang menghubungi keluar). Layanan internal hidup di subnet pribadi & mengalirkan semua lalu lintas keluar melalui proxy SOCKS5 di 203.0.113.5:1080.

Salah satu layanan yang terdapat di balik 203.0.113.5 adalah api.example.com. DNS publik memecahkan api.example.com ke 203.0.113.5.

Sekarang layanan internal yang berbeda perlu menghubungi api.example.com. Jalur keluarnya:

1. Layanan internal mengecualikan api.example.com → 203.0.113.5

2. Layanan internal mengirim permintaan melalui proxy egress SOCKS5 di 203.0.113.5:1080

3. Proxy mencoba membuka koneksi dari dirinya sendiri ke 203.0.113.5:443

4. Ditolak. Paket harus keluar & kembali ke NAT yang sama, yang kebanyakan stack jaringan menolak. Proxy tidak bisa menghubungi dirinya sendiri melalui IP publiknya sendiri.

Ini adalah NAT rambut: paket yang keluar dari NAT dan perlu kembali masuk ke NAT yang sama untuk mencapai tujuannya. Tanpa dukungan khusus hairpin di lapisan routing, paket jatuh.

Mengapa Ini Muncul Terlambat

Pada awal proyek, setiap layanan internal berkomunikasi dengan layanan internal lainnya menggunakan hostname pribadi (internal-api.local) atau tidak memanggil kembali ke layanan publik organisasinya sendiri. Jalan rambut hairpin tidak ada.

Kemudian fitur baru membutuhkan layanan A untuk menghubungi api.example.com (hostname publik). Jalan rambut aktif. Ditolak koneksi. Outage.

Pengaturan patch gejala (mendorong resolusi untuk memberikan IP pribadi api.example.com daripada publik). Akar masalah: satu kotak melakukan terlalu banyak pekerjaan.

NAT Rambut: paket keluar & tidak dapat kembali masuk ke NAT yang sama

Garis Kebangunan Arsitektur

Satu Kotak Menjadi Dua

Pengaturan bersih: memisahkan proxy menjadi dua mesin.

Server Ingress (IP publik 203.0.113.5):

- Caddy / reverse proxy pada porta 80, 443

- Catatan DNS publik mengarah ke sini

- Menyimpan api.example.com, app.example.com, dll

Server Egress (IP publik yang berbeda 203.0.113.99):

- SOCKS5 / forward proxy pada porta 1080

- Dinding api mengizinkan koneksi masuk hanya ke IP subnet internal

- Layanan internal mengarahkan semua keluar melalui alamat ini

Apa yang Ini Beli:

1. Rambut terpecah. Layanan internal yang menghubungi api.example.com mengalir keluar melalui 203.0.113.99 (egress), yang kemudian terhubung normal ke 203.0.113.5 (ingress, IP yang berbeda). Lingkaran NAT hilang karena dua IP yang hidup di mesin yang berbeda.

2. Pengisolasi keamanan. Server egress dapat menutup firewall ke set kecil IP internal. Server ingress tetap terbuka untuk dunia. Dua set aturan, masing-masing mengungkapkan peran dengan bersih.

3. Skalabilitas independen. Bandwidth ingress skalabel dengan pengguna; bandwidth egress skalabel dengan aktivitas layanan internal. Naikkan satu tanpa menyentuh yang lain.

4. Pengisolasi kegagalan. Konfigurasi egress yang salah tidak lagi memutuskan situs publik. Serangan DDoS terhadap situs publik tidak lagi menghabiskan bandwidth egress.

5. Pemodelan pikai yang lebih jelas. Setiap mesin memiliki tugas yang satu. Insinyur berpikir tentang kekhawatiran ingress tanpa memikirkan egress, dan sebaliknya.

Setelah pembagian, layanan internal yang masih perlu menghubungi `api.example.com`. Lalui paket jalur baru dari layanan internal ke backend api. Termasuk: IP apa layanan internal terhubung pertama kali, apa yang mesin itu lakukan dengan permintaan, IP apa yang dikirimkan berikutnya, dan di mana respons pergi.

Dua Sumbu, Dua Keputusan Penataan

Pengaturan Skalabilitas Independen

Sebelum pembagian, pertumbuhan dalam arah yang sama menekan mesin yang sama. Setelah pembagian, setiap arah memiliki penyiapan sendiri.

Penataan Ingress: skalabilitas dengan pengguna. Keputusan kapasitas hidup di lapisan yang menghadap ke luar (lebih banyak replika proxy balik, VM yang lebih besar, CDN di depan). Anggaran bandwidth dibandingkan terhadap lalu lintas pengguna pada puncak.

Penataan Egress: skalabilitas dengan panggilan internal service-to-external API. Sering kali dikendalikan oleh pengiriman webhook, panggilan ke pengolahan pembayaran, atau pengambilan data pihak ketiga. Anggaran bandwidth dibandingkan terhadap pola panggilan internal.

Pengalihan Kegagalan: Serangan DDoS terhadap ingress yang menghadap ke luar tidak memakan bandwidth egress (panggilan ke pengolahan pembayaran tetap melaju). Jatuhnya proxy egress tidak lagi menutup situs yang menghadap ke luar (pengguna tetap mencapai situs; hanya panggilan outbound internal yang gagal).

SLO yang Berbeda: ketersediaan ingress penting bagi pengguna (outage situs yang terlihat); ketersediaan egress penting bagi operator (kegagalan latar belakang yang mungkin memakan waktu lebih lama untuk deteksi). Setiap sisi dapat membawa SLO sendiri.

Beberapa Server Egress

Setelah peran egress menjadi mesin sendiri, langkah yang jelas berikutnya adalah menjalankan beberapa mesin egress di balik load balancer untuk HA. Setiap layanan internal baru mengarah ke nama host egress (yang mengatur ke kolam yang dibalikkan) daripada ke IP tunggal.

Pelajaran yang sama seperti di sistem yang didistribusikan: ketika lapisan menjadi tanpa status & memiliki peran sendiri, itu berkali-kali dengan mudah.

Integrasi Mitra Baru

Organisasi Anda menjalankan pembagian ingress / egress sebagaimana dirancang. Server egress memiliki IP publik yang tetap (203.0.113.99) yang telah Anda allowlist dengan tiga API mitra eksisting (pengolahan pembayaran, gateway SMS, penyedia email).

Tim produk ingin menambah integrasi keempat: sistem pengiriman webhook yang menghubungi endpoint pelanggan di seluruh dunia. Prediksi volume: 10.000 panggilan per menit, dengan lonjakan hingga 30.000.

Putuskan: apakah integrasi mitra baru ini perlu diatur pada server egress yang ada, atau apakah itu membutuhkan jalur egress terpisah? Berpikir tentang bandwidth, pengalihan kegagalan, & apakah allowlist eksisting mitra perlu diperbarui dalam kasus apa pun.

Mengatur Batas Jaringan untuk Layanan yang Berkembang

Sinopsis

Anda telah belajar mengapa ingress & egress membutuhkan alat yang berbeda, kegagalan hairpin NAT yang memaksa pemisahan di flota nyata, & bagaimana skala independen, isolasi keamanan, & isolasi kegagalan mengumpul setelah pemisahan terjadi.

Terapkan semua empat.

Perusahaan SaaS menengah menggunakan tiga subdomain produk (app, api, admin) untuk pengguna mereka, plus empat integrasi outbound (Stripe, Twilio, SendGrid, sistem webhook untuk pelanggan). Hari ini segalanya hidup di balik mesin proxy tunggal di satu IP publik. Mereka sudah mulai mendapatkan laporan tentang kegagalan hairpin intermitten saat layanan internal mencoba menghubungi api.example.com. Mereka ingin merancang solusi permanen.

Usulkan arsitektur ingress / egress untuk perusahaan ini. Alamat: berapa banyak mesin, IP mana yang melayani peran apa, di mana setiap subdomain DNSnya menunjuk, integrasi outbound mana yang membagi jalur egress (& yang seharusnya dipisah), & satu kekhawatiran pemantauan konkrit yang desain baru memungkinkan yang tidak ada di desain sebelumnya.

Ke Mana Kursus Ini Berlanjut

Sekarang Anda telah melihat salah satu refaktoring pemisahan-koncern terbersih dalam sistem distribusi: satu kotak menjadi dua, masing-masing dengan peran jelas, & sistem menghasilkan manfaat skala, keamanan, & isolasi kegagalan secara bertahap.

Les privat berikutnya (cs_distsys_failure_modes_and_blast_radius) memperluas alasan isolasi kegagalan. Anda akan membaca laporan postmortem DNS-SERVFAIL yang disantai, mengidentifikasi pola kegagalan kaskade, & menulis tindakan tanpa membenarkan yang mengincar sistem daripada orang.

Pelajaran teman: geometry_of_ingress_egress_separation mengubah pembagian sebagai graf bipartit & menjelajahi titik potong, partisi jaringan, & apa yang teori graf mengatakan tentang batas jaringan.

Baik sekali. Lanjut.