Subnet yang sama di kedua ujung: petakan LAN jarak jauh ke rentang bebas

Rumah dan kantor sama-sama memakai 192.168.1.0/24, jadi permintaan ke 192.168.1.1 punya dua kemungkinan jawaban dan klien memilih satu tanpa bertanya. Penomoran ulang jaringan kantor yang berjalan jarang populer, dan alamat router sering tertanam di printer, kamera, dan dokumentasi. Pemetaan alamat di sisi klien dapat menampilkan jaringan jarak jauh di bawah rentang bebas sebagai gantinya, dan bagian host bisa tetap sama sehingga 192.168.1.20 tampil sebagai 10.203.41.20. Kendalanya, hanya sebagian klien yang menerapkannya, dan itu tidak melakukan apa pun untuk jalur balik.

Dua pandangan atas host yang sama

Pemetaan mempertahankan bagian host dan hanya mengubah bagian jaringan. Mesin yang sama lalu menjawab pada dua alamat tergantung di mana Anda berdiri. Menuliskan kedua kolom sebelum mengonfigurasi apa pun mencegah kesalahan pembacaan log dan aturan firewall di kemudian hari.

Perangkat lokal di rumah mempertahankan alamat 192.168.1.x mereka sendiri, dan itulah inti latihannya. Printer di ruang sebelah tetap terjangkau sementara kantor muncul di bawah rentang yang tidak bertabrakan.

Urutan argumen adalah seluruh triknya

Opsi ini menerima arah, jaringan dan mask, serta alias: jaringan pertama adalah yang dilihat klien, alias adalah yang dilihat server. Untuk sumber daya yang berada di belakang gateway jarak jauh, arahnya adalah bentuk tujuan. Membalik kedua jaringan karena argumen terakhir disebut alias adalah kesalahan yang menghasilkan tunnel yang terhubung dan tidak memetakan apa pun.

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"

Rute adalah yang mengirim paket klien untuk rentang baru ke dalam tunnel; terjemahan menulis ulang tujuan di sepanjang jalan. Balasan dari 192.168.1.20 ditulis kembali ke 10.203.41.20 agar socket di klien tetap konsisten. Satu host bekerja dengan cara yang sama dengan mask penuh, selama rute dan pemetaan menjelaskan alamat yang sama.

Ini pemetaan alamat, bukan pemetaan port. Dua layanan pada satu host tidak dapat dipisahkan dengannya, dan protokol yang menyematkan alamat IP di dalam payload-nya tetap akan melihat yang asli.

Pemetaan tidak membuat jalur balik

Terjemahan terjadi di klien, jadi server tetap harus merutekan balasan ke tunnel dan firewall-nya tetap harus mengizinkannya. Jika gateway jarak jauh tidak tahu cara mencapai subnet tunnel, permintaan datang dan jawaban keluar lewat pintu yang salah; pemetaan hanya membuat kegagalan tampak seperti masalah klien.

Aturan di sisi server sebaiknya menjelaskan alamat yang ada di server setelah terjemahan, bukan rentang yang terlihat oleh klien. Menyalin alias ke aturan izin membuang satu sore, karena tidak ada paket di sisi itu yang membawanya.

Pilih rentang alias yang tidak bertabrakan dengan apa pun yang dirutekan klien: VPN lain, jaringan kontainer, kantor kedua. Tabrakan di sini memunculkan kembali ambiguitas awal di bawah nomor berbeda dan lebih sulit dilihat karena alamatnya tampak asing.

Nama dan payload bertahan melewati terjemahan

Nama host yang diterjemahkan ke 192.168.1.20 yang asli mengirim browser ke perangkat lokal alih-alih perangkat jarak jauh, apa pun yang dikatakan tabel routing. Jawaban DNS privat harus menunjuk ke rentang yang terlihat oleh klien, sementara sertifikat TLS tetap membawa nama yang diharapkan aplikasi. Uji dengan nama, bukan dengan alamat, karena alamat bisa berfungsi sementara nama diam-diam diterjemahkan ke arah yang salah. Ketika gateway jarak jauh juga melayani zona itu, catatannya sendiri juga memerlukan rentang yang terlihat oleh klien.

Pengalihan, URL tersemat, dan aplikasi yang memberikan alamatnya sendiri di dalam payload dapat rusak dengan cara yang tidak dapat diperbaiki oleh pemetaan paket apa pun. Perlakukan itu sebagai masalah aplikasi dan ukur upayanya dengan tepat sebelum menjanjikan bahwa penomoran ulang tidak diperlukan.

Tiga pemeriksaan sebelum berkomitmen

Pertama, pastikan implementasi klien. Community OpenVPN mendukung opsi ini; basis kode OpenVPN 3 mencantumkannya di antara fitur yang tidak didukung, sehingga profil yang dikirim ke klien bergaya Connect mungkin mengabaikannya begitu saja. Direktif yang diterima dan tidak pernah diterapkan lebih buruk daripada kesalahan, karena tunnel tampak sehat.

Kedua, verifikasi rute dan terjemahan secara terpisah dengan jendela diagnostik singkat pada verbositas tinggi, lalu uji layanan yang sebenarnya alih-alih ping. Ketiga, pastikan router lokal dan sumber daya jarak jauh tetap dapat dibedakan dari klien, karena itulah tujuan awalnya.

Jika klien tidak dapat melakukan terjemahan, mintalah bantuan dari sisi gateway atau terima penomoran ulang. Menambahkan lebih banyak rute untuk alamat yang sama bukanlah desain.