Menjangkau /24 jarak jauh lewat tunnel: NETMAP, DNAT, atau rute?

Anda dapat menjangkau subnet di balik ujung tunnel dengan tiga cara, dan satu menit mengumpulkan fakta biasanya menyingkirkan dua. Faktanya adalah apakah server di sana harus membedakan pengguna, apakah seseorang di sana akan pernah menelepon ke rentang Anda, dan siapa yang boleh menyunting router di ujung jauh. Jawab ketiganya dan desainnya memilih sendiri. Sisanya mengasumsikan Anda mengelola ujung itu dan boleh menyunting firewall-nya.

Tiga opsi, dan apa yang sebenarnya diubah masing-masing

Pemetaan prefiks, DNAT per host, dan prefiks yang dirutekan semuanya memindahkan paket antara dua rentang yang sama, tetapi mengubah hal yang berbeda. Pemetaan menciptakan rentang alias dan menulis ulang alamat secara aritmetika saat transit. Aturan per host juga menulis ulang, hanya saja setiap tujuan dinamai dengan tangan. Prefiks yang dirutekan tidak menulis ulang apa pun: paket mempertahankan alamat asli dan kedua ujung sepakat di mana alamat itu tinggal.

Mulailah eliminasi dari sisi jauh, tempat batasan paling sulit diubah. Jika server di sana menulis alamat klien ke log, memeriksanya terhadap daftar izin, atau menyerahkannya ke sistem lain, menerjemahkan sumber menghancurkan satu-satunya pengenal mereka. Jika sisi jauh juga harus menelepon, terjemahan gugur sepenuhnya, karena tidak ada yang tahu alias itu ada di sana. Hanya ketika sisi jauh sekadar menjawab permintaan, opsi yang lebih murah menjadi aman.

Pasangan prefiks, dan mengapa ukurannya harus sama

NETMAP adalah target tabel nat yang bekerja pada sepasang prefiks dengan panjang identik. Ia tidak punya tabel per alamat di dalamnya: ia mencopot prefiks, menyimpan bit host, dan memasangnya kembali ke prefiks baru, karena itu /24 dipetakan ke /24 dan tidak pernah ke /25. Posisi menentukan arah: kecocokan tujuan di PREROUTING menulis ulang ke mana paket pergi, dan kecocokan sumber di POSTROUTING menulis ulang dari mana ia datang.

Host di 192.168.2.17 tampil bagi klien Anda sebagai 10.50.1.17, dan oktet terakhir bukan hiasan — itu angka yang sama di kedua sisi. Tambahkan host di 192.168.2.40 besok dan aliasnya 10.50.1.40, tanpa aturan yang perlu disunting.

Klien tetap memerlukan rute untuk rentang alias yang menunjuk ke kotak Anda, kecuali alias berada di dalam subnet yang sudah mereka jangkau. Gateway tidak perlu rute untuk alias, karena terjemahan tujuan berjalan di PREROUTING, sebelum pencarian rute. Penerusan juga harus aktif, atau kernel membuang paket setelah penulisan ulang. Tiga perintah di bawah adalah seluruh penyiapan pada gateway bergaya Debian dengan klien di br0, alias di 10.50.1.0/24, dan tunnel di tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Balasan harus menemukan jalannya sendiri kembali

Menulis ulang tujuan hanya menentukan ke mana paket dikirimkan. Server di sisi jauh tetap harus menjawab alamat yang dapat dijangkau, dan ada dua cara mengaturnya. Terjemahkan sumber agar balasan kembali ke kotak Anda, atau biarkan sumber apa adanya dan beri sisi jauh rute untuk rentang klien.

Masquerade di jalur keluar adalah jalur lebih pendek: satu aturan di POSTROUTING dan sisi jauh melihat alamat tunnel Anda, jadi ia tidak perlu rute sendiri. Biayanya adalah semua pengguna menyatu ke satu alamat, dan log per pengguna berhenti bermakna. Membiarkan sumber utuh menyimpan informasi itu, tetapi situs jauh harus mengirim balasan untuk rentang klien kembali melalui tunnel. Pada OpenVPN server itu adalah push "route 10.50.9.0 255.255.255.0" yang dikirim, ditambah baris route 192.168.2.0 255.255.255.0.

Kegagalan mahal adalah mengerjakan separuh dari masing-masing. Jika Anda mem-masquerade sebagian lalu lintas sementara sisi jauh juga membawa rute balik untuk lalu lintas lain, balasan tiba di antarmuka tempat entri pelacakan koneksi tidak pernah terlihat. Klien melaporkan waktu habis untuk permintaan yang dicatat server sebagai telah dilayani. Kedua arah aliran harus melewati instans netfilter yang sama: satu gateway yang menerjemahkan, bukan dua firewall berderet.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Baca entri di kedua arah: tuple asli menyimpan alias Anda di tujuan, sedangkan tuple balasan membawa alamat asli. Jika tuple balasan tidak ada, jalur kembali adalah masalahnya, bukan aturannya. Jika penghitung PREROUTING tidak pernah bergerak, paket tidak pernah mencapai kait itu.

Tabrakan dan pencarian yang berjalan lebih dulu

Dua rentang berbeda dapat bertabrakan dan kedua kegagalan tampak seperti tunnel rusak, bukan aturan buruk. Alias yang Anda buat harus tidak terpakai di sepanjang jalur, dan rentang asli sisi jauh tidak boleh sudah ada di jaringan Anda. Duplikat menghasilkan lalu lintas intermiten ke host yang salah, yang lebih sulit didiagnosis daripada koneksi yang ditolak. Tanyakan tabel rute sebelum menambahkan aturan.

Di gateway, ip route get 192.168.2.17 semestinya menyebut perangkat tunnel; jembatan lokal berarti rentang jauh tertutup bayangan dan tidak ada aturan nat yang memperbaikinya. Jika jaringan Anda sudah memakai 192.168.2.0/24, nomori ulang situs jauh alih-alih menumpuk pemetaan di atas tabrakan.

Mengujinya dari klien nyata, lalu mempertahankannya

Ujilah dari mesin yang benar-benar akan memakai alias, bukan dari gateway, karena lalu lintas yang dihasilkan lokal tidak pernah melewati PREROUTING dengan cara yang sama. Buka koneksi ke satu host beralias dan amati penghitung serta entri conntrack muncul bersamaan, lalu tutup dan pastikan entrinya pergi. Entri basi menunjuk ke koneksi setengah terbuka, yang biasanya berarti balasannya tidak pernah kembali.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Dua atau tiga koneksi berhasil membuktikan aritmetikanya, tetapi tidak mengatakan apa pun tentang ketahanan atau tentang insinyur berikutnya. Simpan aturan di tempat proses boot membacanya, yang di Debian dan Ubuntu berarti iptables-save > /etc/iptables/rules.v4 dengan netfilter-persistent aktif. Pemetaan yang hilang saat reboot lebih buruk daripada tidak ada, karena gangguan datang tanpa perubahan terbaru untuk disalahkan.

Tinggalkan catatan di samping aturan: rentang alias, rentang asli, alasan pasangan itu, dan sisi mana yang boleh memulai. Catatan itu memisahkan desain dari tumpukan aturan yang tidak berani dihapus siapa pun. Ia juga menyelesaikan pertanyaan kemudian, ketika situs jauh menambah host dan alamat yang tidak dikonfigurasi siapa pun sudah menjawab. Jika catatan menyebut sisi jauh memerlukan rute balik, orang berikutnya tahu bahwa menghapus aturan masquerade memutus konektivitas. Dokumentasi di sini murah; menemukan ulang ketergantungan NAT pada pukul tiga pagi tidak.