Karena ini telah dinaikkan menjadi pertanyaan kanonik tentang jepit rambut NAT , saya pikir itu mungkin harus memiliki jawaban yang lebih umum-valid daripada yang saat ini diterima, yang (meskipun sangat baik) berhubungan khusus dengan FreeBSD.
Pertanyaan ini berlaku untuk layanan yang disediakan oleh server pada jaringan IPv4 yang ditangani RFC1918, yang tersedia untuk pengguna eksternal dengan memperkenalkan NAT tujuan (DNAT) di gateway. Pengguna internal kemudian mencoba mengakses layanan tersebut melalui alamat eksternal. Paket mereka keluar dari klien ke perangkat gateway, yang menulis ulang alamat tujuan dan segera menyuntikkannya kembali ke jaringan internal. Ini tajam tentang-turn paket membuat di gateway yang memunculkan nama hairpin NAT , dengan analogi dengan pergantian hairpin .
Masalah muncul ketika perangkat gateway menulis ulang alamat tujuan, tetapi bukan alamat sumber. Server kemudian menerima paket dengan alamat tujuan internal (miliknya sendiri), dan alamat sumber internal (klien); ia tahu ia dapat membalas langsung ke alamat seperti itu, jadi ia melakukannya. Karena balasan itu langsung, itu tidak melalui gateway, yang karenanya tidak pernah mendapat kesempatan untuk menyeimbangkan efek NAT tujuan masuk pada paket awal dengan menulis ulang alamat sumber dari paket kembali.
Klien dengan demikian mengirim paket ke alamat IP eksternal , tetapi mendapat balasan dari alamat IP internal . Tidak tahu bahwa kedua paket adalah bagian dari percakapan yang sama, jadi tidak ada percakapan yang terjadi.
Solusinya adalah bahwa untuk paket yang memerlukan NAT tujuan seperti itu, dan yang mencapai gateway dari jaringan internal , untuk juga melakukan source NAT (SNAT) pada paket inbound, biasanya dengan menulis ulang alamat sumber menjadi gateway. Server kemudian berpikir klien adalah gateway itu sendiri, dan menjawab langsung ke sana. Yang pada gilirannya memberikan gateway kesempatan untuk menyeimbangkan efek DNAT dan SNAT pada paket masuk dengan menulis ulang alamat sumber dan tujuan pada paket kembali.
Klien berpikir itu sedang berbicara ke server eksternal. Server mengira sedang berbicara dengan perangkat gateway. Semua pihak senang. Diagram dapat membantu pada titik ini:
Beberapa perangkat gateway konsumen cukup cerdas untuk mengenali paket-paket yang membutuhkan langkah NAT kedua, dan mereka mungkin akan bekerja di luar kotak dalam skenario NAT jepit rambut. Yang lain tidak, dan begitu juga tidak, dan kecil kemungkinan mereka bisa dibuat bekerja. Diskusi tentang perangkat kelas konsumen mana yang berada di luar topik untuk Kesalahan Server.
Perangkat jaringan yang tepat umumnya dapat dikatakan berfungsi, tetapi - karena mereka tidak bisa menebak-nebak admin mereka - mereka harus diberitahu melakukannya. Linux menggunakan iptables
untuk melakukan DNAT sebagai berikut:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11
yang akan mengaktifkan DNAT sederhana untuk port HTTP, ke server internal aktif 192.168.3.11
. Tetapi untuk mengaktifkan hairpin NAT, kita juga perlu aturan seperti:
iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE
Perhatikan bahwa aturan tersebut harus berada di tempat yang tepat di rantai yang relevan agar dapat berfungsi dengan baik, dan tergantung pada pengaturan dalam filter
rantai, aturan tambahan mungkin diperlukan untuk memungkinkan lalu lintas NATted mengalir. Semua diskusi semacam itu berada di luar cakupan jawaban ini.
Tapi seperti yang orang lain katakan, hairpin NAT yang berfungsi dengan baik bukanlah cara terbaik untuk menangani masalah tersebut. Yang terbaik adalah DNS split-horizon , di mana organisasi Anda menyajikan jawaban berbeda untuk pencarian awal tergantung di mana klien yang meminta, baik dengan memiliki server fisik yang berbeda untuk pengguna internal vs eksternal, atau dengan mengkonfigurasi server DNS untuk merespons secara berbeda sesuai dengan alamat klien yang meminta.