Loopback ke alamat IP Publik yang diteruskan dari jaringan lokal - Hairpin NAT

Ini adalah Pertanyaan Canonical tentang Hairpin NAT (Loopback NAT).

Bentuk umum dari pertanyaan ini adalah:

Kami memiliki jaringan dengan klien, server, dan Router NAT. Ada port forwarding pada router ke server sehingga beberapa layanannya tersedia secara eksternal. Kami memiliki DNS yang menunjuk ke IP eksternal. Klien jaringan lokal gagal terhubung, tetapi pekerjaan eksternal.

• Mengapa ini gagal?
• Bagaimana cara membuat skema penamaan terpadu (nama DNS yang berfungsi baik secara lokal maupun eksternal)?

Pertanyaan ini memiliki jawaban yang digabungkan dari beberapa pertanyaan lainnya. Mereka awalnya mereferensikan FreeBSD, D-Link, Microtik, dan peralatan lainnya. Namun mereka semua berusaha memecahkan masalah yang sama.

Apa yang Anda cari disebut "hairpin NAT". Permintaan dari antarmuka internal untuk alamat IP yang ditetapkan untuk antarmuka eksternal harus di-NATED seolah-olah mereka datang dari antarmuka sisi eksternal.

Saya tidak memiliki keakraban FreeBSD sama sekali, tetapi membaca manual "pf" untuk OpenBSD ( http://www.openbsd.org/faq/pf/rdr.html ) solusi yang diusulkan untuk split-horizon DNS, menggunakan Jaringan DMZ, atau proxy TCP membuat saya percaya bahwa "pf" tidak mendukung hairpin NAT.

Saya akan mencari rute split-horizon DNS dan tidak menggunakan alamat IP di URL secara internal tetapi, sebaliknya, menggunakan nama.

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 iptablesuntuk 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 filterrantai, 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.

Masalahnya di sini adalah, bahwa router Anda tidak NAT alamat klien internal Anda. Dengan demikian, jabat tangan TCP gagal.

Mari kita asumsikan IP berikut

• Klien: 192.168.1.3
• Server: 192.168.1.2
• Router internal: 192.168.1
• Router eksternal: 123.123.123.1

Inilah yang terjadi:

1. Klien (192.168.1.3) mengirimkan TCP-SYN ke IP eksternal Anda, Port 80 (123.123.123.1:80)
2. Router melihat aturan port forwarding dan meneruskan paket ke server (192.168.1.2:80) tanpa mengubah IP sumber (192.168.1.3)
3. Klien menunggu SYN-ACK dari IP eksternal
4. Server mengirim jawabannya kembali ke klien secara langsung, karena itu pada subnet yang sama. Itu tidak mengirim paket ke router, yang akan membalikkan NAT.
5. Klien menerima SYN-ACK dari 192.168.1.2 bukannya 123.123.123.1. Dan membuangnya.
6. Klien masih menunggu SYN-ACK dari 123.123.123.1 dan waktu habis.

Mengapa tidak menggunakan split horizon dns alih-alih alamat IP hardcoding di mana-mana? Anda akan memiliki domain ext.your menunjuk ke 217.xxx di luar, dan kemudian 192.xxx di dalam.

Jika ini adalah router D-Link asli (yaitu, bukan Rev. D / Firmware Versi 1.00VG dari Virgin Media), Anda harus dapat menyesuaikan pengaturan untuk mengatasi ini. (Namun, saya setuju dengan saran poster sebelumnya tentang DD-WRT karena banyak alasan lain!)

1. Masuk ke antarmuka web router
2. Klik tab Advanced di bagian atas
3. Klik tab Pengaturan Firewall di sebelah kiri
4. Klik tombol radio Endpoint Independent di bawah TCP Endpoint Filtering , seperti yang ditunjukkan pada gambar di bawah (atau lihat emulator router di situs web D-Link)
5. Simpan perubahan; kamu sudah selesai

Tangkapan layar ini dari model Rev. C; milikmu mungkin sedikit berbeda.

Baru-baru ini menjawab pertanyaan serupa: Cisco NAT statis tidak bekerja di sisi LAN dan baru menyadari bahwa ini adalah Pertanyaan Canonical. Jadi izinkan saya untuk merangkum solusinya di sini.

Pertama-tama: lupakan NAT (jika Anda bisa) - pertanyaannya sama sekali bukan tentang mengkonfigurasi NAT. Ini tentang mengakses server yang ditempatkan di belakang NAT dari Internet dan LAN. Menggunakan dua zona DNS adalah alternatif yang layak, tetapi tidak selalu solusinya. Tetapi solusinya memang ada dan sangat sederhana (walaupun tidak sempurna, mungkin):

(1) di server: tambahkan alamat IP publik sebagai alamat IP sekunder pada antarmuka jaringan server dengan mask 255.255.255.255 (layanan web atau apa pun yang Anda inginkan di server harus mendengarkan alamat IP ini juga); semua sistem operasi modern akan mengizinkan Anda untuk melakukan ini (atau antarmuka loopback dengan alamat IP publik yang ditetapkan dapat digunakan alih-alih menambahkan IP sekunder ke antarmuka utama).

(2) pada host LAN: tambahkan rute host untuk alamat IP publik, misalnya, untuk host Windows gunakan perintah berikut: route -p tambahkan 203.0.113.130 mask 255.255.255.255 192.168.1.11 (Anda juga dapat menggunakan DHCP " opsi rute statis "untuk mendistribusikan rute). Atau, jika ada (a) saklar L3 (es) / router di antara klien dan router yang menghadap Internet, konfigurasikan rute host tersebut pada sakelar / router perantara ini, bukan pada klien.

Bagi yang terkait dengan jabat tangan tiga arah TCP: itu akan bekerja OK dalam konfigurasi yang diusulkan.

Harap berikan umpan balik (setidaknya, pilih).

Saya akan menjawab pertanyaan saya hanya untuk memperluas wawasan bagi mereka yang memiliki masalah serupa.

Saya menghubungi ISP saya dan meminta mereka untuk mencoba menyelesaikan masalah saya. Apa yang mereka tawarkan kepada saya adalah alamat IP publik lain hanya untuk server, Sekarang saya memiliki lalu lintas lokal di sisi WAN dari FreeBSD dan Kami membuat pipa khusus untuk lalu lintas yang lebih cepat dari lalu lintas lokal ke IP publik dari Server

Dari sudut pandang teknis, solusi terbaik untuk masalah ini adalah mengaktifkan IPv6 di jaringan Anda. Ketika IPv6 diaktifkan, Anda harus membuat catatan AAAA untuk domain Anda. Simpan catatan A yang ada mengarah ke IPv4 eksternal router . Buat catatan AAAA yang menunjuk ke alamat IPv6 dari server .

IPv6 memiliki alamat yang cukup untuk menghindari NAT, jadi Anda tidak perlu NAT hairpin untuk IPv6. Dan setelah Anda mengaktifkan IPv6 dan membuat catatan AAAA, setiap klien yang mendukung RFC 8305 akan mencoba IPv6 sebelum IPv4. Ini berarti Anda tidak perlu hairpin NAT untuk IPv4 juga, karena klien tidak akan menggunakannya.

Anda masih memerlukan IPv4 NAT yang ada untuk koneksi keluar dan penerusan port untuk koneksi masuk sampai sebagian besar dunia telah mengaktifkan IPv6 juga.

Lebih cepat juga.

Menggunakan IPv6 akan memberi Anda kinerja yang lebih baik daripada hairpin NAT.

Dengan hairpin NAT, klien Anda akan mengirim paket melalui switch ke router, router kemudian akan melakukan dua putaran terjemahan dan akhirnya mengirim paket melalui switch ke server. Paket-paket dari server ke klien akan melewati seluruh jalur secara terbalik.

Dengan IPv6 Anda menghindari NAT, sebaliknya paket dikirim langsung melalui peralihan antara klien dan server. Ini berarti pada perjalanan pulang pergi Anda mengurangi jumlah lintasan melalui saklar dari 4 ke 2, dan Anda menghindari 2 perjalanan melalui router dan 4 terjemahan router akan dilakukan. Ini berarti kinerja yang lebih baik.

Ini benar bahkan jika Anda menggunakan saklar yang dibangun ke dalam kotak yang sama dengan router.

Bagaimana jika ISP tidak memiliki IPv6?

Jika Anda menggunakan ISP yang tidak mendukung IPv6, saya akan mempertanyakan apakah Anda harus hosting server di jaringan itu. Ini adalah saran saya tentang apa yang harus dilakukan jika ISP saat ini tidak mendukung IPv6.

Pertama beri tahu ISP bahwa Anda membutuhkan IPv6. Dan mungkin mengingatkan mereka bahwa protokol IPv6 telah ada selama 20 tahun sehingga mereka sudah lama terlambat mendukungnya. Jika itu tidak cukup bagi ISP untuk membuat Anda serius mulai mencari ISP lain.

Jika Anda menemukan ISP dengan dukungan IPv6 Anda dapat menjalankan dengan kedua ISP untuk periode transisi. Pada router yang terhubung ke ISP baru Anda dapat menonaktifkan IPv4 di sisi LAN dan kemudian menghubungkan sisi LAN dari kedua router ke switch yang sama. IPv4 dan IPv6 adalah dua protokol independen dan karenanya tidak ada masalah sama sekali jika koneksi tersebut melalui router yang berbeda. Sebagai manfaat samping itu memberi Anda sejumlah redundansi jika salah satu koneksi mengalami pemadaman.

Jika Anda tidak dapat menemukan ISP dengan dukungan IPv6 Anda harus mempertimbangkan untuk memindahkan server Anda ke fasilitas hosting. Dengan server di fasilitas hosting Anda kurang tergantung pada lokasi geografis dan karena alasan itu ada lebih banyak persaingan antara penyedia yang akan membantu memastikan ada satu yang memenuhi kebutuhan Anda.

Memindahkan server ke fasilitas hosting tidak akan memberi klien Anda IPv6, tetapi memindahkan server berarti Anda tidak perlu lagi hairpin NAT untuk mencapainya.

Apa yang seharusnya tidak Anda lakukan

Jangan nyalakan IPv6 dan buat catatan AAAA jika Anda tidak memiliki cara untuk merutekan lalu lintas IPv6. Jika ISP Anda tidak mendukung IPv6 tetapi Anda tetap memilih untuk mengaktifkan IPv6 di LAN Anda (mungkin menggunakan alamat RFC 4193) dan membuat catatan AAAA itu akan berfungsi untuk klien di LAN Anda yang mencapai server di LAN Anda. Tetapi komunikasi antara LAN Anda dan dunia luar pertama-tama akan mencoba IPv6 (yang tidak akan berfungsi), dan Anda akan mengandalkan jatuh kembali ke IPv4 yang paling lambat sedikit atau paling buruk tidak terjadi.

Karena saya juga menanyakan pertanyaan ini (lihat Bagaimana cara saya mengakses layanan jaringan di belakang firewall dari dalam menggunakan IP luarnya? ) Dan dialihkan di sini tetapi jawaban di sini tidak memberikan solusi (berbeda dengan penjelasan umum ) biarkan saya berikan iptablessolusi Linux saya ( spesifik) di sini untuk menyelamatkan semua orang beberapa jam percobaan. File ini dalam iptables-restoreformat dan dapat dibaca langsung ke iptables (setelah mengedit alamat IP tentunya). Ini untuk server web (port 80) dan hanya untuk IPv4 - aturan untuk IPv6 dan untuk SSL (port 443) adalah analog.

# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Ganti lan.local, web.localdan web.public.comdengan jaringan lokal Anda (mis. 10.0.x.0 / 24), IP lokal server Anda (mis. 10.0.1.2), dan IP publik router Anda (mis. 4.5.6.7). Ini -4hanya untuk memungkinkan aturan IPv6 dan IPv4 dalam file yang sama (baris tersebut diabaikan oleh ip6tables). Juga, ingatlah untuk memasukkan alamat IPv6 di [tanda kurung] ketika mereka menyertakan deklarasi port, misalnya [fe0a:bd52::2]:80.

Itulah semua hal yang menyebabkan saya mencabut rambut ketika mencoba menerapkan penjelasan dalam pertanyaan ini. Saya harap saya tidak meninggalkan apa pun.

Saya akan menambahkan jawaban di sini karena komentar di sini tidak membahas masalah khusus saya. Saya menduga itu karena saya menekan bug kernel linux yang jahat. Penyiapannya adalah:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

Meskipun gambar tampak rumit, satu-satunya perubahan yang relevan untuk situasi yang tercakup dalam komentar lain adalah penambahan jembatan perangkat lunak, br0. Itu ada di sana karena kotak gateway juga merupakan titik akses nirkabel untuk LAN.

Kotak gateway kami masih melakukan tugas-tugas NAT untuk mesin-mesin di LAN. Karena hanya memiliki 1 port ethernet, ia terpaksa melakukan hairpin NAT. Saya curiga seharusnya hanya bekerja dengan aturan iptables yang diberikan dalam komentar lain di sini, tetapi pada kernel Linux 4.9 setidaknya tidak. Di bawah 4,9 sementara kotak gateway kami dapat mengakses internet, mesin-mesin pada LAN yang mencoba mengaksesnya melalui NAT tidak dapat.

tcpdumpmenunjukkan respons terhadap paket yang masuk yang mengenai eth0, tetapi mereka tidak berhasil keluar dari br0. Menjalankan perintah ini memperbaiki bahwa:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

Sebelum perintah itu dijalankan, paket-paket yang masuk diproses sesuai dengan perilaku default kernel, yaitu untuk memberikannya kepada bridge kemudian meneruskannya dengan modul-modul routing kernel. Perintah memaksa paket-paket yang bukan dari LAN untuk memotong jembatan dan langsung menuju rute, yang berarti jembatan tidak mendapatkan kesempatan untuk menjatuhkannya. Alamat broadcast dan multicast harus dijembatani, jika tidak hal-hal seperti DHCP dan mDNS tidak akan berfungsi. jika Anda menggunakan IPv6, Anda harus menambahkan aturan untuk itu juga.

Anda mungkin tergoda untuk memperbaiki masalah menggunakan ini:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

Saya tentu saja sangat tergoda - itu adalah usaha pertama saya. Segera setelah saya melakukannya, mesin-mesin pada LAN memperoleh akses internet, jadi itu bekerja untuk sementara waktu. Kemudian terjadi hal berikut (dan saya tidak mau mengulangi percobaan):

1. Waktu ping melintasi LAN ke gateway berlipat ganda pada interval sekitar 10 detik, naik dari 0,1 ms, menjadi 0,2 ms, 0,4 ms, 0,8 ms, 2ms, dan seterusnya hingga kotak gateway tidak dapat diakses dari LAN. Baunya seperti badai paket, tetapi STP dinyalakan di mana-mana.
2. Tidak lama kemudian semua titik akses nirkabel mati.
3. Ketika mencoba untuk mendiagnosis apa yang terjadi dengan nirkabel, semua telepon IP reboot.
4. Tidak lama kemudian, mesin kabel kehilangan semua kontak dengan LAN.

Satu-satunya jalan keluar adalah me-reboot setiap mesin di gedung. Satu-satunya pengecualian adalah sakelar perangkat keras, yang tidak dapat di-boot ulang. Mereka harus memiliki kekuatan untuk bersepeda.

Karena ini pertanyaan kanonik. Saya akan menjawab jika Anda memiliki router Sonicwall.

Ungkapan untuk mengetahui adalah kebijakan loopback NAT

Dokumen ini menjelaskan bagaimana host pada SonicWall LAN dapat mengakses server pada SonicWall LAN menggunakan alamat IP publik server ke FQDN. Bayangkan sebuah jaringan NSA 4500 (SonicOS Enhanced) di mana Subnet LAN Primer 10.100.0.0 / 24 dan IP WAN Primer adalah 3.3.2.1. Katakanlah Anda memiliki situs Web untuk pelanggan Anda, dan nama hostnya adalah. Anda telah menulis kebijakan dan aturan yang diperlukan agar orang luar bisa masuk ke situs web, tetapi itu benar-benar berjalan di server sisi pribadi 10.100.0.2. Sekarang bayangkan Anda adalah orang yang menggunakan laptop di sisi pribadi, dengan IP 10.100.0.200. Anda ingin menjangkau server menggunakan nama publiknya, karena Anda melakukan hal yang sama ketika laptop Anda ada di jalan. Jika Anda duduk di sisi pribadi, dan minta http://www.example.com>, loopback adalah apa yang memungkinkannya berfungsi, meskipun server sebenarnya berada tepat di sebelah Anda pada alamat IP lokal.

Untuk memungkinkan fungsi ini, Anda perlu membuat kebijakan loopback NAT, juga dikenal sebagai refleksi atau hairpin NAT.

Kebijakan Loopback menggunakan Alamat IP WAN Interface

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Sonicwall akan mengenali layanan eksternal yang Anda coba hubungi, dan akan menulis ulang alamat tujuan agar sesuai dengan alamat internal server, sehingga akan transparan ke komputer.

Dalam FreeBSD menggunakan PF sangat mudah (dalam file pf.conf Anda):

extif = "tun0"
intif = "em0"
{other rules}...
nat on $intif from any to 192.168.20.8 port 80 -> ($extif)

192.168.20.8 akan menjadi server web internal.