Cara Merencanakan Kumpulan Alamat Klien VPN yang Cocok

Mulailah di kolom kumpulan pada server VPN, bukan di lembar kerja. Apa pun yang Anda ketik di sana menjadi ruang alamat internal bagi setiap klien yang terhubung sesudahnya, dan harus hidup berdampingan dengan LAN yang dijangkau klien tersebut, situs ter-rute di belakangnya, dan alamat apa pun yang sudah dipegang klien di rumah. Hubungkan satu klien segera setelah kumpulan disimpan, karena koneksi pertama itulah yang memberi tahu apakah nilainya bekerja dalam praktik. Dari situ penelusuran bergerak ke luar: alamat yang diterima klien, jalur yang dilalui balasan, dan catatan yang Anda tinggalkan.

Mulailah di kolom kumpulan, sebelum klien mana pun terhubung

Setiap produk menampilkannya berbeda, jadi temukan objek yang benar-benar memberikan alamat. OpenVPN punya direktif kumpulan di sisi server yang membagikan alamat bebas berikutnya, gateway IKEv2 punya bagian kumpulan yang terikat pada konfigurasi peer, dan WireGuard tidak punya keduanya karena setiap peer membawa alamatnya sendiri di berkas konfigurasinya. Direktif kumpulan dan alamat per peer tidak bisa dipertukarkan, dan menyunting yang salah membuang sisa penelusuran.

Setelah kolomnya ada, daftarkan rentang yang sudah ada: LAN kantor, setiap situs ter-rute, VPC cloud, dan kumpulan lain yang masih beroperasi. Tumpang tindih ditentukan oleh aritmetika prefiks, bukan oleh apakah nomor host terlihat familier, jadi bandingkan agregatnya dengan setiap rentang itu. Dua rentang yang keduanya tampak seperti 10.x tidak berbahaya bila agregatnya tidak beririsan dan menjadi insiden dukungan bila beririsan.

Lalu putuskan apakah alamat itu fungsi dari siapa yang terhubung atau kapan mereka terhubung. Penetapan dinamis membagikan apa yang bebas, sedangkan penetapan per identitas mengikat alamat tetap ke kredensial. Tuliskan pilihannya, karena itu mengubah seperti apa koneksi ulang nantinya.

Baca alamat yang benar-benar diterima klien

Hubungkan satu klien dan baca apa yang dilaporkan terowongan, bukan apa yang dijanjikan kumpulan. Klien menampilkan alamat internalnya di status koneksi, dan di Linux antarmuka membawanya langsung.

Bandingkan alamat itu dengan rentang yang Anda simpan. Jika berada di luar rentang, Anda sedang melihat jalur penetapan yang berbeda dari yang Anda sunting. Periksa juga panjang prefiks, karena klien dengan /32 tidak punya peer on-link dan mengirim setiap tujuan lewat rute bawaannya.

ip -4 addr show tun0
ip route get 192.168.50.20

Klien yang terhubung dari router rumah yang memakai rentang sama akan terhubung lalu nyaris tidak menjangkau apa pun. Klien mempertahankan rute lokalnya untuk prefiks itu, sehingga alamat terowongan bertabrakan dengan jaringan di belakangnya dan lalu lintas keluar lewat antarmuka yang salah. Kasus itu tidak bisa diperbaiki di server; obat yang terdokumentasi adalah menomori ulang jaringan rumah atau memilih rentang kumpulan yang cukup jauh agar tabrakan tetap jarang. Catat kegagalan dan obatnya, karena meja bantuan akan menemuinya lagi.

Hubungkan ulang klien yang sama dan amati alamatnya. Kumpulan dinamis bisa mengembalikan nilai yang sama atau berbeda dan keduanya benar, sedangkan kumpulan per identitas yang mengubah alamat tidak menghormati ikatan itu. Pemeriksaan itu butuh beberapa detik dan memutuskan apakah mode yang Anda catat di bagian pertama adalah mode yang berlaku.

Ikuti balasan kembali dari layanan

Kumpulan hanya bekerja bila balasan bisa pergi kembali kepadanya. Layanan di LAN menjawab alamat internal, jadi gateway-nya perlu rute untuk kumpulan atau terjemahan di depan layanan. Ketika permintaan datang lewat terowongan dan balasan keluar lewat jalur berbeda, firewall stateful atau pemeriksaan jalur balik menjatuhkannya, dan klien melihat layanan yang terhubung lalu menggantung. Tempatkan kumpulan dalam desain perutean sebagai satu blok yang bisa diringkas, bukan menambah rute per host.

Terjemahan mengubah apa yang dilihat bagian lain sistem. Ketika sumber ditulis ulang, alamat di firewall host dan di log aplikasi adalah yang diterjemahkan, sehingga aturan yang ditulis terhadap alamat kumpulan tidak cocok dengan apa pun dan baris log tidak bisa dilacak kembali ke klien. Dokumentasi penerusan strongSwan mencakup separuh sisi server dari jalur itu untuk gateway IKEv2. DNS membawa kendala yang sama, karena nama yang diselesaikan ke alamat yang tidak bisa dijangkau klien gagal belakangan dan di tempat lain.

Dua klien, lalu satu pencabutan

Hubungkan dua klien sekaligus dan baca kedua alamatnya. Keduanya harus berbeda, bisa dipakai, dan berada di dalam kumpulan, serta masing-masing harus menjangkau layanan yang dituju. Kumpulan yang membagikan alamat duplikat biasanya muncul di sini, bukan pada uji satu klien pertama.

Cabut satu kredensial sementara klien lain tetap terhubung, lalu coba layanan itu dari klien yang bertahan. Pencabutan yang mengganggu sesi lain menunjuk pada keadaan bersama, paling sering satu kredensial atau satu alamat yang dipakai ulang antarperangkat. Hubungkan ulang klien yang dicabut dan pastikan ia ditolak, bukan diberi alamat yang dibebaskan.

Akhiri dengan tujuan yang seharusnya ditolak. Klien yang menjangkau segalanya baru terhubung, belum diuji.

Tuliskan keempat nilai itu di tempat perubahan berikutnya akan menemukannya

Catatannya singkat: rentang dan prefiks kumpulan, mode penetapan, jalur kembali atau terjemahan yang dipakai, dan cakupan DNS yang menjawab untuk tujuan itu. Letakkan di samping konfigurasi server, bukan di tiket, dan beri tanggal. Siapa pun yang mengubah salah satu dari empat itu nanti memerlukan tiga lainnya di hadapannya, karena perubahan ukuran kumpulan memutus rute dan perubahan rute memutus jawaban DNS.

Simpan catatan kepemilikan bersamanya: rentang terowongan milik server VPN, dan reservasi yang dibuat di cakupan DHCP LAN tidak mereservasi apa pun bagi klien di dalam terowongan. Satu baris itu mencegah pengerjaan ulang paling umum, ketika seseorang menambahkan reservasi dan mengharapkan alamat terowongan mengikutinya.