Subnet sama di kedua-dua hujung: petakan LAN jauh ke julat bebas

Rumah dan pejabat kedua-duanya menggunakan 192.168.1.0/24, jadi permintaan ke 192.168.1.1 mempunyai dua jawapan yang mungkin dan klien memilih satu tanpa bertanya. Penomboran semula rangkaian pejabat yang berjalan jarang popular, dan alamat penghala sering tertanam dalam pencetak, kamera dan dokumentasi. Pemetaan alamat di sisi klien boleh memaparkan rangkaian jauh di bawah julat bebas sebagai gantinya, dan bahagian hos boleh kekal sama supaya 192.168.1.20 kelihatan sebagai 10.203.41.20. Masalahnya ialah hanya sesetengah klien melaksanakannya, dan ia tidak melakukan apa-apa untuk laluan balik.

Dua pandangan bagi hos yang sama

Pemetaan mengekalkan bahagian hos dan hanya mengubah bahagian rangkaian. Mesin yang sama kemudian menjawab pada dua alamat bergantung pada tempat anda berdiri. Menulis kedua-dua lajur sebelum mengkonfigurasi apa-apa mengelakkan salah baca log dan peraturan firewall kemudian.

Peranti tempatan di rumah mengekalkan alamat 192.168.1.x mereka sendiri, dan itulah tujuan latihan ini. Pencetak di bilik sebelah kekal boleh dicapai manakala pejabat muncul di bawah julat yang tidak berlanggar.

Urutan argumen ialah keseluruhan helahnya

Pilihan ini mengambil arah, rangkaian dan topeng, serta alias: rangkaian pertama ialah apa yang klien lihat, alias ialah apa yang pelayan lihat. Bagi sumber yang berada di belakang gateway jauh, arah ialah bentuk destinasi. Membalikkan kedua-dua rangkaian kerana argumen terakhir dipanggil alias ialah kesilapan yang menghasilkan terowong yang bersambung dan tidak memetakan apa-apa.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Laluan ialah apa yang menghantar paket klien untuk julat baharu ke dalam terowong; terjemahan menulis semula destinasi sepanjang jalan. Balasan daripada 192.168.1.20 ditulis semula ke 10.203.41.20 supaya soket pada klien kekal konsisten. Satu hos berfungsi dengan cara yang sama dengan topeng penuh, selagi laluan dan pemetaan menerangkan alamat yang sama.

Ini pemetaan alamat, bukan pemetaan port. Dua perkhidmatan pada satu hos tidak boleh dipisahkan dengannya, dan protokol yang membenamkan alamat IP dalam muatannya masih akan melihat yang sebenar.

Pemetaan tidak mencipta laluan balik

Terjemahan berlaku pada klien, jadi pelayan masih perlu menghala balasan ke terowong dan firewallnya masih perlu membenarkannya. Jika gateway jauh tidak tahu cara mencapai subnet terowong, permintaan tiba dan jawapan keluar melalui pintu yang salah; pemetaan hanya membuat kegagalan kelihatan seperti masalah klien.

Peraturan di sisi pelayan harus menerangkan alamat yang wujud pada pelayan selepas terjemahan, bukan julat yang kelihatan kepada klien. Menyalin alias ke peraturan kebenaran membazirkan satu petang, kerana tiada paket di sisi itu membawanya.

Pilih julat alias yang tidak berlanggar dengan apa-apa lagi yang dihalakan klien: VPN lain, rangkaian kontena, pejabat kedua. Perlanggaran di sini memperkenalkan semula kekaburan asal di bawah nombor yang berbeza dan lebih sukar dilihat kerana alamatnya kelihatan asing.

Nama dan muatan bertahan melalui terjemahan

Nama hos yang diselesaikan kepada 192.168.1.20 sebenar menghantar pelayar ke peranti tempatan dan bukan peranti jauh, apa pun kata jadual penghalaan. Jawapan DNS peribadi mesti menunjuk ke julat yang kelihatan kepada klien, manakala sijil TLS masih membawa nama yang dijangka oleh aplikasi. Uji dengan nama dan bukan dengan alamat, kerana alamat boleh berfungsi sementara nama senyap menyelesaikan ke arah yang salah. Apabila gateway jauh juga menyediakan zon itu, rekodnya sendiri juga memerlukan julat yang kelihatan kepada klien.

Ubah hala, URL terbenam dan aplikasi yang memberikan alamatnya sendiri dalam muatan boleh rosak dengan cara yang tiada pemetaan paket dapat membaikinya. Anggapnya sebagai masalah aplikasi dan anggarkan usaha dengan sewajarnya sebelum berjanji bahawa penomboran semula tidak diperlukan.

Tiga pemeriksaan sebelum komited

Pertama, sahkan pelaksanaan klien. Community OpenVPN menyokong pilihan ini; pangkalan kod OpenVPN 3 menyenaraikannya antara ciri yang tidak disokong, jadi profil yang ditolak ke klien gaya Connect mungkin hanya mengabaikannya. Arahan yang diterima tetapi tidak pernah digunakan lebih buruk daripada ralat, kerana terowong kelihatan sihat.

Kedua, sahkan laluan dan terjemahan secara berasingan dengan tetingkap diagnostik pendek pada verbositi tinggi, kemudian uji perkhidmatan sebenar dan bukan ping. Ketiga, sahkan bahawa penghala tempatan dan sumber jauh kekal boleh dibezakan daripada klien, kerana itulah matlamat asal.

Jika klien tidak dapat melakukan terjemahan, minta bantuan daripada sisi gateway atau terima penomboran semula. Menambah lebih banyak laluan untuk alamat yang sama bukanlah reka bentuk.