Mengapa tidak lebih banyak organisasi menggunakan NAT dari dalam ke dalam atau solusi serupa untuk memungkinkan jepit rambut NAT?

Inside-to-inside NAT alias NAT loopback memecahkan masalah NAT hairpin ketika mengakses server web pada antarmuka eksternal ASA atau perangkat serupa dari komputer pada antarmuka internal. Ini mencegah admin DNS dari keharusan mempertahankan duplikat zona DNS internal yang memiliki alamat RFC1918 yang sesuai untuk server mereka yang NATted ke alamat publik. Saya bukan seorang insinyur jaringan, jadi saya mungkin kehilangan sesuatu, tapi ini sepertinya tidak ada otak untuk mengkonfigurasi dan mengimplementasikan. Routing asimetris dapat menjadi masalah tetapi mudah dikurangi.

Dalam pengalaman saya, admin jaringan / insinyur lebih suka orang-orang sistem hanya menjalankan split-dns daripada mengkonfigurasi firewall mereka untuk menangani jepit rambut NAT dengan benar. Kenapa ini?

Ada beberapa alasan mengapa saya tidak melakukannya:

• Mengapa harus memberi tekanan ekstra pada router DMZ dan firewall jika Anda tidak perlu melakukannya? Sebagian besar layanan internal kami tidak di DMZ tetapi area perusahaan umum, dengan layanan proxy di DMZ untuk akses jarak jauh sesekali. Melakukan nat dari dalam ke dalam menambah lebih banyak beban pada DMZ, yang dalam kasus kami akan menjadi signifikan.
• Jika Anda tidak melakukan DNAT + SNAT, Anda akan mendapatkan rute asimetrik, yang terkenal sulit untuk diperbaiki. Jadi Anda SNAT dan kehilangan sumber informasi IP. Namun, sangat berguna untuk menautkan IP sumber ke orang-orang untuk tujuan pemecahan masalah. Atau sesekali tujuan nerfshooting dalam kasus kebodohan. "Hei IP ini sedang melakukan sesuatu yang tidak beres pada layanan yang tidak terauthentikasi X" "Oh, mari kita lihat di log server imap siapa itu"

Jelas, tidak ada jawaban pasti untuk ini, tetapi saya bisa memikirkan sejumlah alasan:

1. Keanggunan: NAT tidak terlalu elegan untuk memulai, tetapi suatu keharusan dengan ruang alamat IPv4 yang terbatas. Jika saya dapat menghindari NAT, saya akan melakukannya. Dengan IPv6 masalah akan hilang dengan cara apa pun.
2. Kompleksitas: terutama dalam kasus di mana Anda tidak memiliki hanya satu router "inti" tunggal yang menciptakan semua batas keamanan Anda, konfigurasi filter bisa menjadi sangat rumit. Entah itu atau Anda harus menyebarkan dan memelihara aturan NAT di hampir semua perangkat router Anda.
3. Referensi: di mana admin firewall adalah orang-orang yang berbeda dari tim admin server lainnya, mereka mungkin sulit dijangkau. Untuk memastikan bahwa perubahan tidak tertunda oleh backlog admin firewall (atau liburan), opsi untuk menjaga tanggung jawab dalam tim yang sama dipilih
4. Portabilitas dan praktik umum: Menggunakan tampilan DNS adalah "hal yang diketahui semua orang dilakukan" untuk menyelesaikan masalah ini. Tidak semua router batas akan mendukung loopback NAT secara langsung, lebih sedikit orang yang mungkin tahu cara mengaturnya dengan benar di lingkungan spesifik Anda. Ketika memecahkan masalah jaringan, kru harus menyadari konfigurasi NAT jepit rambut dan semua implikasinya - bahkan ketika mereka mengejar masalah yang tampaknya tidak terkait

Penafian - ini adalah jawaban flamebait.

Alasan umum saya pikir solusi seperti ini dihindari adalah ketakutan / kebencian irasional terhadap NAT pada bagian dari insinyur jaringan . Jika Anda ingin melihat beberapa contoh diskusi tentang ini, lihat ini:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (Blog Tom tampaknya terus menarik diskusi NAT / IPv6 yang agak bersemangat)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (blog saya)

Dari apa yang bisa saya katakan, banyak ketakutan ini bermula dari implementasi NAT yang buruk dari Cisco (jadi dalam arti itu mungkin tidak masuk akal), tetapi menurut saya insinyur jaringan "klasik" begitu terlatih dalam "NAT adalah pandangan dunia yang buruk, bahwa dia tidak bisa melihat contoh nyata seperti ini di mana itu masuk akal dan sebenarnya menyederhanakan solusinya.

Di sana Anda pergi - downvote ke isi hati Anda! :-)

Dugaan saya adalah:

1. Split DNS lebih mudah dipahami.
2. NAT Hairpin menggunakan sumber daya di router sementara split-dns tidak.
3. Router mungkin memiliki batasan bandwidth yang tidak Anda dapatkan melalui pengaturan split-dns.
4. Split-dns akan selalu berkinerja lebih baik karena Anda menghindari langkah-langkah perutean / NAT.

Di sisi positifnya untuk hairpin NAT,

• Setelah pengaturan itu hanya berfungsi.
• Tidak ada masalah dengan cache DNS untuk laptop yang dipindahkan antara jaringan kerja dan internet publik.
• DNS untuk server hanya dikelola di satu tempat.

Untuk jaringan kecil dengan persyaratan lalu lintas rendah ke server internal saya akan pergi dengan hairpin NAT. Untuk jaringan yang lebih besar dengan banyak koneksi ke server dan di mana bandwidth dan latensi penting, gunakan split-dns.

Dari sudut pandang saya, ini sedikit berubah antara transisi Cisco Pix ke ASA. Kehilangan aliasperintah. Dan secara umum, mengakses alamat luar dari antarmuka bagian dalam pada firewall Cisco memerlukan semacam tipu daya. Lihat: Bagaimana cara saya mencapai server internal pada IP eksternal?

Kami tidak selalu perlu mempertahankan zona DNS internal duplikat. Cisco ASA dapat mengarahkan permintaan DNS untuk alamat eksternal ke alamat internal jika dikonfigurasi pada pernyataan NAT. Tapi saya lebih suka menyimpan zona internal untuk zona DNS publik agar memiliki rincian dan untuk dapat mengelola ini di satu tempat daripada melangkah ke firewall.

Biasanya, hanya ada beberapa server yang mungkin memerlukan ini dalam suatu lingkungan (mail, web, beberapa layanan publik), jadi itu bukan masalah besar.

Saya dapat memikirkan beberapa alasan:

1. Banyak organisasi telah membagi DNS sebagai akibat dari tidak ingin mempublikasikan semua informasi DNS internal mereka kepada dunia, sehingga tidak banyak upaya tambahan untuk menangani beberapa server yang juga diekspos melalui IP publik.
2. Sebagai sebuah organisasi dan jaringannya tumbuh lebih besar, mereka sering memisahkan sistem yang melayani orang-orang internal dari server yang melayani eksternal, sehingga routing ke yang eksternal untuk penggunaan internal mungkin merupakan jalur jaringan yang jauh lebih lama.
3. Semakin sedikit modifikasi yang dilakukan perangkat perantara terhadap paket, semakin baik jika menyangkut latensi, waktu respons, beban perangkat, dan pemecahan masalah.
4. (sangat kecil, harus diakui) Ada protokol yang masih dapat dipatahkan NAT jika perangkat NATing tidak melampaui header paket dan memodifikasi data di dalamnya dengan alamat IP yang baru. Bahkan jika itu hanya kasus memori institusional, itu masih merupakan alasan yang sah bagi orang untuk menghindarinya, terutama jika mereka berurusan dengan protokol yang tidak 100% mereka yakini.

Jika saya akan menggunakan loopback NAT saya akan sedikit khawatir tentang bagaimana perangkat NAT akan menangani alamat sumber palsu. Jika tidak memeriksa antarmuka mana paket masuk, maka saya bisa menipu alamat internal dari WAN dan mengirim paket ke server dengan alamat internal. Saya tidak bisa mendapatkan balasan, tetapi saya mungkin bisa kompromi server menggunakan alamat internal.

Saya akan mengatur loopback NAT, tancapkan ke saklar DMZ dan mengirim paket dengan alamat sumber internal palsu. Periksa log server untuk melihat apakah mereka diterima. Kemudian saya akan pergi ke kedai kopi dan melihat apakah ISP saya memblokir alamat palsu. Jika saya menemukan router NAT saya tidak memeriksa antarmuka sumber, saya mungkin tidak akan menggunakan loopback NAT bahkan jika ISP saya memeriksa.