Dimungkinkan untuk menyelesaikan ini dengan menggunakan NAT; hanya saja tidak terlalu elegan.
Jadi dengan asumsi Anda tidak dapat menyelesaikan ini dengan memiliki jaring internal yang memiliki nomor jaringan yang tidak biasa sehingga tidak pernah benar-benar mengalami konflik, inilah prinsipnya:
Karena subnet lokal dan jarak jauh memiliki nomor jaringan yang sama, lalu lintas dari klien Anda tidak akan pernah menyadari bahwa ia harus melalui gateway terowongan untuk mencapai tujuannya. Dan bahkan jika kita bayangkan itu bisa, situasinya akan sama untuk host jarak jauh karena akan mengirim jawaban.
Jadi tetap dengan saya dan berpura-pura bahwa sampai sekarang, tidak ada masalah samping ketika saya menulis bahwa untuk konektivitas penuh, Anda perlu NAT kedua ujungnya di dalam terowongan untuk membedakan host dan memungkinkan untuk routing.
Membuat beberapa jaring di sini:
- Jaringan kantor Anda menggunakan 192.0.2.0/24
- Kantor jarak jauh Anda menggunakan 192.0.2.0/24
- Gateway VPN jaringan kantor Anda menyembunyikan 192.0.2.0/24 host di belakang nomor jaringan NATed 198.51.100.0/24
- Gateway VPN jaringan kantor jarak jauh Anda menyembunyikan 192.0.2.0/24 host di belakang nomor jaringan NATed 203.0.113.0/24
Jadi di dalam terowongan VPN, host kantor sekarang 198.51.100.x dan host kantor jarak jauh 203.0.113.x. Lebih jauh lagi kita berpura-pura semua host dipetakan 1: 1 di NAT gateway VPN masing-masing. Sebuah contoh:
- Tuan rumah jaringan kantor Anda 192.0.2.5/24 secara statis dipetakan sebagai 198.51.100.5/24 di gateway kantor vpn NAT
- Tuan rumah jaringan kantor jarak jauh Anda 192.0.2.5/24 secara statis dipetakan sebagai 203.0.113.5/24 di gateway kantor vpn terpencil NAT
Jadi ketika host 192.0.2.5/24 di kantor jauh ingin terhubung ke host dengan ip yang sama di jaringan kantor, perlu melakukannya dengan menggunakan alamat 198.51.100.5/24 sebagai tujuan. Berikut ini terjadi:
- Di kantor jarak jauh, host 198.51.100.5 adalah tujuan jarak jauh yang dicapai melalui VPN dan dialihkan ke sana.
- Di kantor jarak jauh, host 192.0.2.5 disamarkan sebagai 203.0.113.5 saat paket melewati fungsi NAT.
- Di kantor, host 198.51.100.5 diterjemahkan ke 192.0.2.5 ketika paket melewati fungsi NAT.
- Di kantor, kembalikan lalu lintas ke host 203.0.113.5 melewati proses yang sama dengan arah sebaliknya.
Jadi, sementara ada solusinya, ada sejumlah masalah yang harus diatasi agar ini dapat bekerja dalam praktik:
- IP yang disamarkan harus digunakan untuk konektivitas jarak jauh; DNS menjadi kompleks. Ini karena titik akhir harus memiliki alamat IP unik, seperti yang dilihat dari host penghubung.
- Fungsi NAT harus diimplementasikan kedua ujungnya sebagai bagian dari solusi VPN.
- Memetakan host secara statis adalah suatu keharusan untuk dapat dijangkau dari ujung yang lain.
- Jika lalu lintas searah, hanya pihak penerima yang membutuhkan pemetaan statis semua host yang terlibat; klien dapat melarikan diri dengan secara dinamis NATed jika diinginkan.
- Jika lalu lintas dua arah, kedua ujung memerlukan pemetaan statis semua host yang terlibat.
- Konektivitas internet tidak boleh terganggu terlepas dari VPN split atau non-split.
- Jika Anda tidak dapat memetakan 1-ke-1, itu menjadi berantakan; pembukuan yang cermat adalah suatu keharusan.
- Secara alami seseorang berisiko menggunakan alamat NAT yang juga ternyata merupakan duplikat :-)
Jadi pemecahan ini perlu desain yang cermat. Jika kantor jauh Anda benar-benar terdiri dari pejuang jalanan, Anda menambahkan lapisan masalah di dalamnya:
- mereka tidak pernah tahu sebelumnya ketika mereka berakhir dengan id bersih yang tumpang tindih.
- gateway kantor jarak jauh NAT perlu diterapkan pada laptop mereka.
- gateway kantor akan membutuhkan dua VPN, satu bebas-NAT dan satu NATed, untuk mencakup kedua skenario. Jika tidak, jika seseorang memilih salah satu subnet yang Anda pilih untuk metode NAT, semuanya tidak akan berhasil .
Tergantung pada klien VPN Anda, Anda mungkin dapat secara otomatis memilih satu VPN atau yang lain tergantung pada alamat jaringan segmen lokal.
Perhatikan bahwa semua penyebutan NAT dalam konteks ini menunjukkan fungsi NAT yang dapat dikatakan terjadi dalam perspektif terowongan. Secara bertahap, pemetaan NAT statis harus dilakukan sebelum paket "memasuki" terowongan, yaitu sebelum dienkapsulasi dalam paket transportasi yang akan membawanya melintasi internet ke gateway VPN lainnya.
Ini berarti bahwa seseorang tidak boleh membingungkan alamat ip publik gateway VPN (dan yang dalam praktiknya mungkin juga NAT: ed, tetapi kemudian sepenuhnya di luar perspektif transportasi ke situs jarak jauh melalui VPN) dengan alamat pribadi unik yang digunakan sebagai topeng. untuk alamat pribadi duplikat. Jika abstraksi ini sulit untuk digambarkan, ilustrasi tentang bagaimana NAT dapat dipisahkan secara fisik dari gateway VPN untuk tujuan ini dibuat di sini:
Menggunakan NAT dalam Jaringan yang Tumpang Tindih .
Mengondensasi gambar yang sama ke pemisahan logis di dalam satu mesin, yang mampu melakukan fungsi NAT dan gateway VPN, hanya mengambil contoh yang sama satu langkah lebih jauh, tetapi memang lebih menekankan pada kemampuan perangkat lunak yang ada. Meretasnya bersama misalnya dengan OpenVPN dan iptables dan memposting solusinya di sini akan menjadi tantangan yang layak.
Softwarewise tentunya dimungkinkan:
PIX / ASA 7.x dan yang lebih baru: LAN-to-LAN IPsec VPN dengan Contoh Konfigurasi Jaringan yang Tumpang tindih
dan:
Mengkonfigurasi Terowongan IPSec Antar Router dengan Duplikat Subnet LAN
Implementasi yang sebenarnya karena itu tergantung pada banyak faktor, sistem operasi yang terlibat, perangkat lunak terkait dan kemungkinannya tidak sedikit. Tapi itu tentu bisa dilakukan. Anda perlu berpikir dan bereksperimen sedikit.
Saya belajar ini dari Cisco seperti yang terlihat oleh tautan.