Mencapai /24 jauh melalui terowong: NETMAP, DNAT atau laluan?
Petakan seluruh awalan dengan NETMAP, tambah peraturan DNAT setiap hos atau laluan julat sebenar, dan tentukan berdasarkan apa yang perlu dilihat oleh sisi jauh dan siapa boleh memulakan trafik.
Anda boleh mencapai subrangkaian di belakang titik akhir terowong melalui tiga cara, dan satu minit pengumpulan fakta biasanya menyingkirkan dua. Faktanya ialah sama ada pelayan di sana mesti membezakan pengguna, sama ada seseorang di sana akan pernah mendail ke arah julat anda, dan siapa yang boleh menyunting penghala hujung jauh. Jawab ketiga-tiganya dan reka bentuk memilih dirinya sendiri. Selebihnya menganggap anda mengendalikan titik akhir dan boleh menyunting firewalnya.
Tiga pilihan, dan apa yang sebenarnya diubah oleh setiap satu
Pemetaan awalan, DNAT setiap hos dan awalan yang dilalukan semuanya memindahkan paket antara dua julat yang sama, tetapi mengubah perkara yang berbeza. Pemetaan mencipta julat alias dan menulis semula alamat secara aritmetik semasa dalam perjalanan. Peraturan setiap hos juga menulis semula, cuma setiap destinasi dinamakan dengan tangan. Awalan yang dilalukan tidak menulis semula apa-apa: paket mengekalkan alamat sebenar dan kedua-dua hujung bersetuju di mana alamat itu berada.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Mulakan penyingkiran dari sisi jauh, di mana kekangan paling sukar diubah. Jika pelayan di sana menulis alamat klien ke dalam log, menyemaknya terhadap senarai benarkan atau menyerahkannya kepada sistem lain, menterjemah sumber memusnahkan satu-satunya pengecamnya. Jika sisi jauh juga mesti mendail masuk, terjemahan sama sekali tidak boleh, kerana tiada siapa di sana tahu alias itu wujud. Hanya apabila sisi jauh sekadar menjawab permintaan barulah pilihan lebih murah menjadi selamat.
Pasangan awalan, dan mengapa saiznya mesti sepadan
NETMAP ialah sasaran jadual nat yang berfungsi pada pasangan awalan yang sama panjang. Ia tiada jadual setiap alamat di dalamnya: ia menanggalkan awalan, menyimpan bit hos dan memasangnya semula pada awalan baharu, sebab itulah /24 dipetakan ke /24 dan tidak pernah ke /25. Kedudukan menentukan arah: padanan destinasi dalam PREROUTING menulis semula ke mana paket pergi, dan padanan sumber dalam POSTROUTING menulis semula dari mana ia datang.
Hos pada 192.168.2.17 muncul kepada klien anda sebagai 10.50.1.17, dan oktet terakhir bukan hiasan — ia nombor yang sama pada kedua-dua belah. Tambah hos pada 192.168.2.40 esok dan aliasnya ialah 10.50.1.40, tanpa peraturan untuk disunting.
Klien masih memerlukan laluan untuk julat alias yang menunjuk ke kotak anda, melainkan alias berada dalam subrangkaian yang mereka sudah capai. Get laluan tidak memerlukan laluan untuk alias, kerana terjemahan destinasi berjalan dalam PREROUTING, sebelum carian laluan. Pemajuan juga mesti dihidupkan, jika tidak kernel akan menggugurkan paket selepas tulisan semula. Tiga arahan di bawah ialah keseluruhan persediaan pada get laluan gaya Debian dengan klien pada br0, alias pada 10.50.1.0/24 dan terowong pada 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 MASQUERADEBalasan mesti mencari jalannya sendiri untuk pulang
Menulis semula destinasi hanya menentukan ke mana paket dihantar. Pelayan hujung jauh masih mesti menjawab alamat yang dapat dicapainya, dan ada dua cara untuk mengaturnya. Terjemah sumber supaya balasan kembali ke kotak anda, atau biarkan sumber dan beri sisi jauh laluan untuk julat klien.
Masquerade pada jalan keluar ialah laluan lebih pendek: satu peraturan dalam POSTROUTING dan sisi jauh melihat alamat terowong anda, jadi ia tidak memerlukan laluan sendiri. Kosnya ialah setiap pengguna runtuh menjadi satu alamat, dan log setiap pengguna tidak lagi bermakna apa-apa. Membiarkan sumber utuh mengekalkan maklumat itu, tetapi tapak jauh kemudian mesti menghantar balasan untuk julat klien kembali melalui terowong.OpenVPN pelayan itu ialah push "route 10.50.9.0 255.255.255.0", serta route 192.168.2.0 255.255.255.0 baris.
Kegagalan yang mahal ialah melakukan separuh daripada setiap satu. Jika anda masquerade sebahagian trafik sementara sisi jauh juga membawa laluan balik untuk trafik lain, balasan tiba pada antara muka di mana entri penjejakan sambungan tidak pernah dilihat. Klien melaporkan tamat masa untuk permintaan yang pelayan catat sebagai dilayan. Kedua-dua arah sesuatu aliran mesti merentasi instans netfilter yang sama: satu get laluan menterjemah, bukan dua firewall bersiri.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nBaca entri dalam kedua-dua arah: tuple asal mengekalkan alias anda pada destinasi, manakala tuple balasan membawa alamat sebenar. Jika tuple balasan tiada, masalahnya ialah laluan balik, bukan peraturan. Jika pembilang PREROUTING tidak pernah bergerak, paket tidak pernah sampai ke cangkuk itu.
Perlanggaran dan carian yang berjalan dahulu
Dua julat berbeza boleh berlanggar, dan kedua-dua kegagalan kelihatan seperti terowong rosak bukan peraturan buruk. Alias yang anda cipta mesti tidak digunakan di sepanjang laluan, dan julat jauh sebenar tidak boleh sudah wujud pada rangkaian anda. Pertindihan menghasilkan trafik hos salah yang berselang-seli, lebih sukar didiagnosis daripada sambungan ditolak. Tanya jadual laluan sebelum menambah peraturan.
Pada get laluan, ip route get 192.168.2.17 sepatutnya menamakan peranti terowong; jambatan setempat bermakna julat jauh dilindungi dan tiada peraturan nat akan membaikinya. Jika rangkaian anda sudah menggunakan 192.168.2.0/24, nomborkan semula tapak jauh dan bukannya menyusun pemetaan pada perlanggaran.
Mengujinya dari klien sebenar, kemudian menyimpannya
Uji dari mesin yang benar-benar akan menggunakan alias, bukan dari get laluan, kerana trafik yang dijana secara setempat tidak pernah merentasi PREROUTING dengan cara yang sama. Buka sambungan ke satu hos beralias dan perhatikan pembilang dan entri conntrack muncul bersama, kemudian tutup dan sahkan entri itu pergi. Entri lapuk menunjuk kepada sambungan separa terbuka, yang biasanya bermakna balasan 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.17Dua atau tiga sambungan berjaya membuktikan aritmetik itu, tetapi tidak berkata apa-apa tentang ketekalan atau jurutera seterusnya. Simpan peraturan di tempat proses but membaca, yang pada Debian dan Ubuntu bermakna iptables-save > /etc/iptables/rules.v4 dengan netfilter-persistent didayakan. Pemetaan yang hilang semasa but semula lebih teruk daripada tiada, kerana gangguan datang tanpa perubahan terkini untuk dipersalahkan.
Tinggalkan nota di sebelah peraturan: julat alias, julat sebenar, sebab pasangan itu dan pihak mana yang boleh memulakan. Nota itu memisahkan reka bentuk daripada longgokan peraturan yang tiada siapa berani padam. Ia juga menyelesaikan soalan kemudian, apabila tapak jauh menambah hos dan alamat yang tiada siapa konfigurasikan sudah menjawab. Jika nota menyatakan sisi jauh memerlukan laluan balik, orang seterusnya tahu bahawa membuang peraturan masquerade memutuskan sambungan. Dokumentasi murah di sini; menemui semula kebergantungan NAT pada pukul tiga pagi tidak.