Apa yang dicatat untuk VPN situs-ke-situs: selektor dan cakupan

Enam bulan setelah tunnel diaktifkan, subnet baru berhenti cocok dengan kebijakan dan satu-satunya dokumen di berbagi hanya menulis VPN kantor. Itulah kegagalan yang dicegah catatan selektor, dan sifatnya spesifik: himpunan alamat berubah sementara dokumennya tidak. Menulis catatan dengan benar berarti tahu himpunan alamat mana dari beberapa yang Anda jelaskan, dan mencatat yang benar-benar diberlakukan oleh sisi lain, bukan yang Anda konfigurasi.

Terkonfigurasi bukan ternosiasi

Dalam tunnel IPsec berbasis kebijakan, tiap sisi mengusulkan selektor lalu lintas: rentang sumber dan tujuan untuk asosiasi anak. Sisi yang menjawab boleh mempersempit usulan itu , sehingga asosiasi terpasang bisa mencakup lebih sedikit daripada yang dicantumkan konfigurasi. Catatan yang menyalin konfigurasi karena itu menjelaskan niat, bukan cakupan perlindungan saat ini. Keduanya menyimpang diam-diam, dan tidak ada yang menunjukkannya di halaman status tunnel.

Simpan kedua kolom, dengan tanggal Anda mengamatinya. Selektor terkonfigurasi adalah yang Anda maksud; yang ternosiasi adalah yang sedang diberlakukan kernel. Ketika keduanya berbeda, perbedaan itu menjelaskan kegagalan mengejutkan jauh lebih sering daripada bug perutean.

Satu asosiasi juga tidak mewakili setiap pasangan terkonfigurasi. Tunnel dengan beberapa kombinasi selektor bisa berakhir dengan beberapa asosiasi anak, dan catatan yang mencantumkan salah satunya adalah inventaris sebagian. Daftarkan semuanya alih-alih merangkumnya.

Tunnel berbasis rute memilih dengan cara lain

Dengan antarmuka berbasis rute, tabel perutean menentukan apa yang masuk ke tunnel dan selektornya bisa sengaja lebar. Itu desain yang sah, bukan kelalaian, dan catatan harus menjelaskannya begitu. Tuliskan rute, antarmuka yang dituju, dan kebijakan firewall yang membatasi layanan mana yang dapat dijangkau. Cakupan perlindungan memang lebar dengan sengaja, dan cakupan layanan yang mempersempitnya.

Menyalin templat berbasis kebijakan ke tunnel berbasis rute menghasilkan dokumen yang menjelaskan mekanisme yang tidak dipakai penerapan. Insinyur berikutnya lalu mencari selektor yang seharusnya tidak pernah ada di sana, dan menyimpulkan tunnel salah konfigurasi padahal hanya terdokumentasi buruk.

Terjemahan termasuk dalam tabel yang sama

Ketika NAT menyajikan rentang berbeda ke sisi lain, catat prefiks asli dan terjemahan bersama-sama. Catat tahap di mana selektor dan aturan akses mencocokkannya, karena urutannya menentukan apakah sisi jauh pernah melihat alamat yang Anda tulis. Tabel dengan hanya satu dari dua rentang lebih buruk daripada tanpa tabel, karena terlihat lengkap.

Inilah detail yang merusak tunnel yang berfungsi setelah perubahan NAT: selektor masih cocok dengan prefiks asli, sisi lain kini menerima yang terjemahan, dan rute baliknya menunjuk alamat yang sudah tidak ada. Tidak ada yang mencatat kesalahan saat keduanya berhenti sepakat.

DNS privat termasuk di tempat yang sama. Nama yang diselesaikan ke alamat yang tidak dapat dipakai dari situs terkait adalah kesalahan dokumentasi dengan tiket dukungan terlampir, dan tunnel akan disalahkan.

Lampirkan persyaratan layanan

Rentang terlindungi bukan daftar izin. Tuliskan layanan mana yang seharusnya dapat dijangkau dari sumber mana, dan siapa pemilik aplikasi di belakangnya. Kedua bidang itu menjawab pertanyaan berbeda, dan mencampurnya adalah cara tinjauan keamanan berakhir berdebat soal perutean alih-alih akses.

Lalu sebutkan administrator jaringan yang memelihara aturan itu. Inventaris selektor tanpa pemilik menua diam-diam, dan yang usang tidak bisa dibedakan dari yang salah ketika tunnel putus pukul dua pagi. Pemilik juga orang yang dapat memastikan perubahan itu disengaja.

Ubah catatan menjadi rencana uji

Untuk setiap jalur yang diperlukan, pilih host sumber dan tujuan yang mewakili dan catat rute, layanan, serta gateway balasan yang diharapkan. Itu mengubah dokumen menjadi rencana uji alih-alih deskripsi. Baca asosiasi hidup dengan perintah di bawah, dan bandingkan dengan baris ternosiasi yang Anda tulis.

swanctl --list-sas

Kerangka lima baris biasanya cukup untuk menjaga catatan jujur. Versi di bawah muat di tiket perubahan tanpa terpotong:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Ping hanya ke gateway bukan uji penerimaan. Itu tidak pernah melatih jalur transit, sehingga bisa lolos sementara setiap aliran yang diteruskan gagal. Uji dari host di satu sisi ke layanan di sisi lain dan pastikan balasannya tiba melalui tunnel. Jika hanya ping yang lolos, catatan baru saja menemukan masalah penerusan yang ingin dicegahnya. dokumentasi penerusan strongSwan menjelaskan bagaimana selektor, rute, dan penerusan saling berinteraksi pada rekan Linux.