Mengungkap banyak server di belakang NAT menggunakan satu alamat IP publik

17

Ini adalah Pertanyaan Canonical tentang NAT dan DNS

Saat ini saya sedang mencoba untuk mengatur jaringan dengan DMZ yang berisi server web dan server email yang dipisahkan dari Internet oleh firewall yang menerjemahkan alamat jaringan (NAT).

Saya telah menginstal firewall NAT dengan antarmuka berikut:

WAN - x.x.x.x (redacted public IP address)
DMZ - 192.168.124.5/24
LAN - 192.168.123.5/24

Di DMZ saya, saya memiliki dua host saya:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

Saya tahu bahwa saya harus mengkonfigurasi DNS untuk example.comdomain untuk menyelesaikan keduanya example.comdan mail.example.comke alamat IP publik saya.

Saya ingin firewall NAT saya meneruskan semua permintaan masuk ke example.comserver web pada 192.168.124.30, dan semua permintaan masuk ke mail.example.comserver email pada 192.168.124.32. Saya melihat fitur "port forwarding" dalam konfigurasi firewall NAT saya tetapi sepertinya tidak dapat mencapai apa yang saya cari.

networking domain-name-system firewall nat Atrotygma
sumber
3
Saya mengedit pertanyaan Anda untuk menghapus referensi ke teknologi tertentu. Pertanyaannya masih menanyakan hal dasar yang sama tetapi dengan cara yang netral teknologi. Demikian juga, jawaban saya berlaku untuk pertanyaan awal Anda tetapi juga akan berlaku jika orang lain dengan situasi firewall dan layanan host yang berbeda datang mencari jawaban di sini.
Evan Anderson

Jawaban:

18

Anda menjadi kacau dalam pemikiran Anda tentang bagaimana informasi mengalir di antara lapisan-lapisan protokol TCP / IP - antara DNS dan protokol-protokol lapisan aplikasi, khususnya.

Anda memiliki satu alamat IP publik. DNS Anda tentu saja dapat menyelesaikan keduanya mail.example.comdan example.comke alamat IP publik yang sama.

Secara umum, datagram IP yang berisi permintaan ke alamat IP publik Anda, yang akan diterima oleh antarmuka eksternal firewall Anda, tidak mengandung nama host yang coba diakses oleh klien jarak jauh. Firewall Anda tidak dapat secara ajaib "mengetahui" nama host mana yang ditangani klien jarak jauh, karena kedua nama host tersebut memutuskan untuk alamat IP yang sama. Lapisan IP tidak mengetahui nama host yang digunakan pada lapisan aplikasi.

Protokol TCP dan UDP membedakan layanan khusus yang ditawarkan oleh host menggunakan nomor port. Dalam contoh Anda, dimungkinkan untuk menggunakan fitur penerusan port (juga disebut terjemahan alamat port, atau PAT) firewall NAT Anda untuk mengirim permintaan yang masuk ke port TCP 80 (HTTP) ke server web saat mengirim port TCP inbound 25 (SMTP) ke server email Anda.

Namun, jika Anda berencana untuk meng-host layanan yang sama di kedua mesin maka strategi ini menjadi bermasalah. Misalkan Anda akan meng-host situs web aman di server web Anda (untuk akses Pelanggan) dan situs web aman di server email Anda (untuk webmail). Permintaan yang datang ke alamat IP publik firewall NAT Anda ke port TCP 443 (HTTPS) hanya dapat dialihkan ke satu server atau yang lain.

Solusi umum untuk situasi ini adalah memiliki lebih banyak alamat IP publik. Karena alamat IPv4 menjadi langka yang juga bisa menjadi masalah.

Kami akhirnya mengatasi kelangkaan alamat IP publik di beberapa protokol pada lapisan aplikasi. Sebagai contoh, HTTP / 1.1 menambahkan Host:header khusus untuk memungkinkan server web untuk meng-host beberapa situs web pada alamat IP publik yang sama. TLS menambahkan ekstensi Indikasi Nama Server (SNI) untuk memungkinkan pemilihan sertifikat yang sesuai berdasarkan nama host yang dimasukkan oleh klien jarak jauh.

Melakukan solusi semacam ini di lapisan aplikasi berarti bahwa setiap protokol lapisan aplikasi akan membutuhkan "perbaikan" sendiri (dan kemudian semua perangkat lunak server dan klien harus menerapkan "perbaikan" itu). Itu perintah yang sulit.

Sebagai pengganti dari memodifikasi lapisan aplikasi protokol beberapa protokol dengan mudah menerima menjadi "multiplexed" antara beberapa host menggunakan perangkat lunak yang dapat "merutekan" permintaan. Kemungkinan ini melampaui apa yang mampu dilakukan firewall NAT sederhana karena paket-paket perlu diperiksa pada lapisan aplikasi. Menggunakan reverse-proxy seperti nginx adalah contoh yang baik dari jenis "multiplexing" ini (atau aturan penerbitan Web tentang Forefront TMG atau ISA Server di lingkungan Microsoft) untuk protokol HTTP. Secara teori, protokol apa pun bisa multiplexing melalui proxy terbalik tetapi protokol yang lebih esoterik semakin besar kemungkinan Anda akan berbicara tentang memiliki kode kustom yang ditulis.

Ketika Anda perlu menawarkan layanan yang sama dari dua host berbeda pada satu alamat IP publik, Anda selalu memiliki opsi untuk memindahkan salah satu host ke port non-standar. Ini akan mengharuskan klien untuk mengetahui port non-standar. Dalam hal HTTP (S) ini menghasilkan URL dengan http://example.com:XXXnotasi (di mana XXXnomor port non-standar). Apakah ini akan bermasalah dalam situasi Anda adalah sesuatu yang hanya Anda yang dapat memutuskan. (Pengalaman saya menunjukkan bahwa hampir tidak ada pengguna akhir yang mampu menangani :XXXnotasi port di URL apa pun yang harus mereka masukkan sendiri.)

Evan Anderson
sumber
1
Penanganan masalah, bukan "memperbaiki". :)
Michael Hampton
@MichaelHampton - Aku dengar ya '! > tersenyum <
Evan Anderson
@ EvanAnderson Terima kasih atas jawaban Anda. Saya kira saya mengacaukan semuanya karena saya terbiasa bekerja dengan ForeFront, tugas seperti itu terasa biasa bagi saya. Apakah Anda mengetahui adanya distribusi firewall Linux dengan kemampuan ini yang berfungsi pada lapisan aplikasi? Saya sudah melihat Shorewall, tapi saya tidak yakin apakah ini bisa melakukan ini karena didasarkan pada iptables yang, seperti yang Anda sebutkan, pada layer ip.
Atrotygma
5

Fitur "Port Forwarding" Anda dapat memungkinkan Anda mengirimkan lalu lintas yang diperuntukkan bagi: 80 dan: 443 hingga 192.168.124.30 dan port lainnya (atau hanya yang digunakan oleh server email Anda yang dikonfigurasi untuk digunakan) ke 192.168.124.32. Jika karena alasan tertentu Anda memerlukan salah satu dari kedua port tersebut untuk server email dan juga untuk server web, Anda dalam masalah. Agar metode ini berfungsi, akses web apa pun ke server email Anda harus menggunakan porta yang berbeda (kemungkinan besar tidak standar). Anda mungkin juga akan mengatur server web untuk mengarahkan kembali segala sesuatu yang mengatakan " mail.example.com" untuk digunakan , bagi pengguna yang tidak tahu cara menambahkan nomor port dan / atau menentukan koneksi aman. (Anda hanya akan menggunakan koneksi web yang aman ke server surat, kan?)https://mail.example.com:other_port

Ini adalah pada lapisan Transport daripada lapisan Aplikasi, yang berarti tidak harus bergantung pada inspeksi paket yang mendalam. Alih-alih itu dapat melihat lokasi yang mudah ditemukan di header TCP untuk port.

Monty Harder
sumber
3

Jika "permintaan masuk" Anda adalah hal yang berbeda, yaitu lalu lintas web (HTTP) untuk server web dan lalu lintas surat (SMTP) untuk server email, ini memang dapat dilakukan: HTTP menggunakan port TCP 80 (443 untuk HTTPS), sedangkan SMTP menggunakan port TCP 25; dengan demikian, dari alamat IP publik yang sama, Anda dapat meneruskan lalu lintas HTTP ke server web Anda, dan lalu lintas SMTP ke server email Anda; inilah yang dimaksud dengan "port forwarding". Setiap firewall yang layak mampu melakukan ini.

Namun, jika secara kebetulan kedua server harus dapat menerima jenis lalu lintas yang SAMA, jika server email Anda juga meng-host layanan webmail, maka Anda dalam masalah, karena Anda dapat meneruskan port tertentu (80 dan / atau 443) hanya untuk satu server; untuk memisahkan lalu lintas web berdasarkan nama yang digunakan klien untuk memintanya, Anda memerlukan sesuatu yang beroperasi pada tingkat yang lebih tinggi dari TCP / IP, seperti proxy terbalik.

Massimo
sumber