it-swarm-id.com

Loopback ke penerusan alamat IP Publik 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 penerusan port pada router ke server sehingga beberapa layanannya tersedia secara eksternal. Kami memiliki DNS yang menunjuk ke eksternal IP. Klien jaringan lokal gagal terhubung, tetapi pekerjaan eksternal.

  • Mengapa ini gagal?
  • Bagaimana saya bisa 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.

46
adopilot

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 dari DNS split-horizon, menggunakan DMZ jaringan, atau TCP proxy membuat saya percaya bahwa "pf" tidak mendukung NAT hairpin).

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

16
Evan Anderson

Karena ini telah dinaikkan menjadi pertanyaan kanonik pada hairpin NAT, saya pikir itu mungkin harus memiliki jawaban yang lebih umum-valid daripada yang saat ini diterima, yang (walaupun sangat baik) berhubungan khusus untuk FreeBSD.

Pertanyaan ini berlaku untuk layanan yang disediakan oleh server pada jaringan IPv4 yang ditujukan RFC1918, yang tersedia untuk pengguna eksternal dengan memperkenalkan tujuan NAT (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 putaran paket yang dibuat pada gateway yang memunculkan name hairpin NAT , dengan analogi dengan giliran jepit rambut .

Masalah muncul ketika perangkat gateway menulis ulang alamat tujuan, tetapi bukan alamat sumber. Server kemudian menerima paket dengan alamat tujuan internal (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 tujuan masuk NAT pada paket awal dengan menulis ulang alamat sumber pengembalian) paket.

Klien kemudian mengirimkan paket ke eksternal alamat IP, tetapi mendapat balasan dari internal alamat IP. Tidak tahu bahwa kedua paket adalah bagian dari percakapan yang sama, jadi tidak ada percakapan yang terjadi.

Solusinya adalah untuk paket yang memerlukan NAT tujuan seperti itu, dan yang mencapai gateway dari jaringan internal, untuk juga menjalankan source NAT (SNAT) pada paket inbound, biasanya dengan menulis ulang alamat sumber menjadi gateway. Server kemudian berpikir klien adalah gateway itu sendiri, dan membalas langsung ke sana. Hal itu pada gilirannya memberikan gateway kesempatan untuk menyeimbangkan efek DNAT dan SNAT pada paket inbound 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:

enter image description here

Beberapa perangkat gateway konsumen cukup cerdas untuk mengenali paket-paket yang dibutuhkan langkah NAT kedua, dan itu mungkin akan bekerja di luar kotak dalam jepit rambut NAT skenario. Yang lain tidak, dan begitu juga tidak, dan tidak mungkin mereka dapat berfungsi. 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 pada 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 rantai filter, aturan tambahan mungkin diperlukan untuk memungkinkan lalu lintas NATted mengalir. Semua diskusi semacam itu berada di luar cakupan jawaban ini.

Tetapi seperti yang dikatakan orang lain, hairpin yang mengaktifkan dengan benar NAT bukan cara terbaik untuk menangani masalah. Yang terbaik adalah DNS split-horizon , di mana organisasi Anda menyajikan jawaban berbeda untuk pencarian asli 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.

49
MadHatter

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.
9
PEra

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

4
Ryaner

Jika ini adalah router D-Link asli (mis., Bukan Rev. D/Firmware Versi 1.00VG dari Virgin Media), Anda harus dapat menyesuaikan pengaturan untuk mengatasi hal 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 Independen Endpoint di bawah Pemfilteran Endpoint TCP , seperti yang ditunjukkan pada tangkapan layar di bawah ini (atau lihat router emulator di situs web D-Link)
  5. Simpan perubahan; kamu sudah selesai

D-Link router web UI screenshot

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

2
David

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

Pertama-tama: lupakan NAT (jika Anda bisa) - pertanyaannya sama sekali bukan tentang mengkonfigurasi NAT. Ini tentang mengakses server yang berada di belakang NAT dari baik Internet dan LAN. Mempekerjakan dua zona DNS adalah alternatif yang layak, tetapi tidak selalu solusinya. Tetapi solusinya 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 opsi "rute statis" DHCP 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 berkaitan dengan jabat tangan TCP tiga arah: itu akan bekerja OK dalam konfigurasi yang diusulkan.

Berikan umpan balik (setidaknya, beri suara).

2
Sergio

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

IPv6 memiliki cukup alamat untuk menghindari NAT, sehingga Anda tidak perlu jepit rambut NAT untuk IPv6. Dan setelah Anda mengaktifkan IPv6 dan membuat AAAA mencatat semua klien yang mendukung RFC 8305 akan mencoba IPv6 sebelum IPv4. Ini berarti Anda tidak perlu jepit rambut NAT juga untuk IPv4, karena klien tidak akan menggunakannya.

Anda masih membutuhkan IPv4 NAT Anda 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 dari server ke klien akan melewati seluruh jalur secara terbalik.

Dengan IPv6 Anda menghindari NAT, sebagai gantinya paket dikirim langsung melalui saklar antara klien dan server. Ini berarti pada perjalanan pulang pergi Anda mengurangi jumlah lintasan melalui saklar dari 4 menjadi 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 katakan kepada ISP bahwa Anda perlu 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 dengan demikian 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 memberikan klien Anda IPv6, tetapi memindahkan server berarti Anda tidak lagi memerlukan jepit rambut NAT untuk mencapainya.

Apa yang tidak boleh 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 bekerja 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.

1
kasperd

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

1
adopilot

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 ----------/
        +----------------------+ 

Terlepas dari gambaran yang 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 menjalankan tugas NAT untuk mesin-mesin di LAN. Karena ia hanya memiliki 1 port ethernet, ia terpaksa melakukan hairpin NAT. Saya menduga itu hanya dapat bekerja dengan aturan iptables yang diberikan dalam komentar lain di sini, tetapi pada kernel Linux 4.9 setidaknya tidak. Di bawah 4.9 kami kotak gateway kami dapat mengakses internet mesin-mesin pada LAN mencoba mengaksesnya melalui NAT can 't.

tcpdump menunjukkan respons terhadap paket yang masuk yang memukul 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 lalu meneruskannya dengan modul routing kernel. Perintah memaksa 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 di LAN mendapatkan 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 berusaha 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.

0
Russell Stuart

Karena saya juga mengajukan pertanyaan ini (lihat Bagaimana saya mengakses layanan jaringan yang disematkan di balik firewall dari dalam menggunakan IP luarnya? ) dan dialihkan ke sini tetapi jawaban di sini tidak memberikan solusi (berbeda dengan penjelasan umum ) biarkan saya memberikan Linux saya (iptables spesifik) solusi di sini untuk menyelamatkan semua orang beberapa jam percobaan. File ini dalam iptables-restore format 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.local dan web.public.com dengan jaringan lokal Anda (mis. 10.0.x.0/24), IP lokal server web Anda (mis. 10.0.1.2), dan IP publik router Anda (mis. 4.5.6.7). -4 hanya untuk mengizinkan aturan IPv6 dan IPv4 dalam file yang sama (baris seperti itu diabaikan oleh ip6tables). Juga, ingatlah untuk memasukkan alamat IPv6 di [tanda kurung] ketika mereka menyertakan deklarasi port, mis. [fe0a:bd52::2]:80.

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

0
Jens

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

Ekspresi yang perlu diketahui 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 Pratama WAN IP adalah 3.3.2.1. Mari katakanlah Anda memiliki situs Web untuk pelanggan Anda, dan hostname-nya 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 bahwa 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 bersama Anda di jalan. sisi pribadi, dan permintaan http://www.example.com >, loopback adalah apa yang memungkinkannya berfungsi, meskipun server sebenarnya berada tepat di sebelah Anda pada alamat IP lokal .

Untuk mengizinkan fungsi ini, Anda perlu membuat kebijakan loopback NAT, juga dikenal sebagai NAT refleksi atau jepit rambut).

Kebijakan Loopback menggunakan WAN Alamat IP Antarmuka

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.

0
yagmoth555