VPN situs-ke-situs versus akses jarak jauh: apa yang disatukan keduanya

Kedua desain disebut VPN dan keduanya menyelesaikan masalah yang berbeda. Tunnel situs-ke-situs menyatukan dua gateway, sehingga setiap host di belakangnya dapat menjangkau alamat yang diizinkan di sisi lain tanpa memasang apa pun. Tunnel akses jarak jauh menyatukan perangkat individual ke sebuah jaringan, satu klien pada satu waktu. Perbandingan ini penting karena sebagian besar kesalahan penerapan berasal dari mengonfigurasi salah satu sambil mengharapkan perilaku yang lain, dan gejalanya biasanya timeout pada layanan yang benar-benar telah dijangkau tunnel.

Dua desain, dua batas

Tidak ada desain yang memperluas domain siaran LAN. Perangkat di sisi jauh tidak muncul dalam daftar penemuan lokal, dan mengharapkan hal itu adalah asumsi pertama yang harus dilepaskan. Nama DNS privat yang Anda terbitkan dengan sengaja lebih dapat diprediksi daripada protokol penemuan mana pun, dan tetap bertahan saat berganti vendor.

Ambil 10.10.0.0/24 di satu situs dan 10.20.0.0/24 di situs lain. Gateway A memerlukan rute atau selektor lalu lintas yang mengirim prefiks 10.20.0.0/24 ke tunnel, dan gateway B memerlukan bayangan cerminnya. Host di kedua sisi kemudian memakai konektivitas IP biasa dan tidak pernah tahu bahwa ada tunnel. Ketidakkelihatan itulah fiturnya, dan itu juga sebabnya kegagalan terlihat seperti kesalahan jaringan biasa, bukan kesalahan tunnel.

Berbasis kebijakan dan berbasis rute bukan tunnel yang sama

Dalam penerapan IPsec berbasis kebijakan, selektor lalu lintas yang dinegosiasikan menentukan persis pasangan sumber dan tujuan mana yang dilindungi. Jika subnet baru muncul di belakang salah satu gateway dan tidak ada selektor yang mencakupnya, tunnel tetap aktif dan subnet baru itu tidak diangkut sama sekali. Dalam desain berbasis rute, antarmuka menerima lalu lintas dan tabel perutean yang memutuskan, sehingga menambahkan prefiks menjadi perubahan rute, bukan negosiasi ulang tunnel.

StrongSwan menampilkan kedua pandangan secara langsung, dan membacanya bersama-sama adalah cara mengetahui model mana yang sebenarnya Anda terapkan.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Daftar selektor yang menghilangkan prefiks yang Anda butuhkan menjelaskan kegagalan tanpa tangkapan paket apa pun, dan rute yang menunjuk ke antarmuka keliru menjelaskan kegagalan cermin di jalur kembali. Baca keduanya sebelum menegosiasikan ulang apa pun, karena pembaruan kunci tidak akan menambahkan selektor yang tidak pernah Anda konfigurasi.

Rencanakan pengalamatan sebelum tunnel

Rentang yang tumpang tindih adalah kesalahan desain yang tidak dapat diperbaiki dengan konfigurasi. Jika kedua situs memakai 192.168.1.0/24, host yang memerlukan 192.168.1.50 memiliki dua kandidat dan tidak punya cara memilih. Tunnel akan terautentikasi, asosiasi keamanan akan terbentuk, dan keputusan perutean tetap salah atau ambigu.

Pilih salah satu dari tiga opsi jujur: menomori ulang satu situs, menerjemahkan rentang yang tumpang tindih di gateway sehingga setiap sisi melihat prefiks berbeda, atau melepaskan perutean langsung untuk host tersebut dan menerbitkan layanan dengan cara lain. Masing-masing punya biaya, dan yang pertama biasanya paling murah dalam horizon dua tahun. Putuskan sebelum tunnel ada, karena setelahnya perubahan menyentuh setiap perangkat yang memiliki alamat lama.

Selesaikan juga soal MTU lebih awal. Tunnel mengurangi muatan berguna, dan desain yang bergantung pada fragmentasi berperilaku berbeda dari yang mengunci MSS di gateway.

Penerusan dan kebijakan berada di luar tunnel

Gateway harus bersedia meneruskan paket antara antarmuka tunnel dan antarmuka LAN, dan kedua arah memerlukan kebijakan yang mengizinkan layanan. Di Linux itu dua pengaturan terpisah, ditambah aturan firewall yang memutuskan apakah aliran yang diteruskan diizinkan sama sekali.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Host penerima menambahkan lapisan ketiga: firewall-nya sendiri tetap harus menerima klien dari subnet jauh. Server berkas yang hanya mengizinkan /24 lokalnya akan menolak lalu lintas yang diteruskan dari 10.20.0.7, seberapa pun sehat tunnel terlihat, dan penolakan itu mudah dibaca sebagai kegagalan perutean.

Uji dari host, bukan dari gateway

Ping yang dikirim oleh gateway itu sendiri dapat mengikuti alamat sumber dan kebijakan yang berbeda dari lalu lintas pengguna yang diteruskan. Itu membuatnya menjadi uji yang lemah dan kadang menyesatkan: berhasil saat aplikasi gagal, atau gagal saat aplikasi bekerja.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Gunakan host sungguhan, alamat sumber sungguhan, dan protokol sungguhan yang dipakai aplikasi. Lalu baca jalur balasan secara terpisah, karena arah maju yang bekerja tanpa rute balik menghasilkan timeout yang tampak identik dengan layanan yang diblokir.

Pilih desain menurut pertanyaan yang Anda jawab: apakah Anda menyatukan jaringan atau menerima perangkat? Semua hal lain, termasuk vendor mana yang Anda konfigurasi, mengikuti jawaban itu.