Mengapa Kebijakan Keamanan IPsec Bukan Entri Tabel Rute
Rute yang berfungsi tidak membuktikan apa pun tentang IPsec. Baca pencarian rute dan selektor kebijakan untuk alur yang sama, lalu pastikan sebuah asosiasi mencakupnya.
Lakukan ping ke 10.20.0.5 melalui terowongan dan tidak ada yang kembali, sementara tabel rute bersikeras bahwa subnet itu dapat dijangkau. Perutean dan IPsec menjawab pertanyaan yang berbeda, dan hanya satu di antaranya tentang keterjangkauan. Pencarian maju memilih jalur, lalu basis data kebijakan keamanan memutuskan apakah jalur itu harus dilindungi, dibiarkan atau ditolak. Ketika keduanya tidak sepakat, paket mati diam-diam, jadi bacalah keduanya dalam urutan itu.
Mulai dari pencarian, bukan tabel
Tanyakan kepada kernel apa yang sebenarnya akan dilakukannya: ip route get 10.20.0.5 mencetak rute yang dipilih, antarmuka keluar, dan alamat sumber yang akan digunakannya. Prefiks, aturan kebijakan, tanda, atau sumber pilihan semuanya dapat mengubah jawaban itu, itulah sebabnya pencarian langsung mengalahkan membaca tabel dengan mata.
Uji tujuan di dalam rentang terlindungi, bukan alamat gateway. Mencapai gateway di sisi seberang hanya membuktikan bahwa ada rute; itu tidak mengatakan apa pun tentang subnet yang sebenarnya Anda butuhkan. Lalu pastikan antarmuka yang dipilih pencarian adalah yang Anda harapkan digunakan terowongan.
Cocokkan selektor di kedua sisi
Basis data kebijakan memiliki entrinya sendiri, dan masing-masing menyebutkan arah, sumber, tujuan, dan protokol, lalu menyatakan apa yang harus terjadi pada paket yang cocok. Gunakan ip xfrm policy untuk menampilkannya; tanda menunjukkan apakah tindakannya melindungi, melewati, atau memblokir. Kebijakan yang selektornya lebih luas atau lebih sempit dari alur uji Anda tidak akan cocok dengannya, dan paket keluar tanpa perlindungan. Itulah kegagalan yang Anda cari, bukan rute yang hilang.
Bandingkan nilai sebenarnya: sumber, tujuan, protokol, dan port. Jika pencarian menyelesaikan satu pasangan alamat sementara entri kebijakan mencakup pasangan lain, kedua tampilan menggambarkan lalu lintas yang berbeda. Jalankan ulang keduanya dengan tuple yang sama sebelum menarik kesimpulan, atau Anda akan mengedit kebijakan yang tidak pernah ada di jalur.
Kecocokan kebijakan bukan keadaan terpasang
Kebijakan yang cocok hanya mengatakan paket harus dilindungi; kernel masih memerlukan asosiasi keamanan untuk melakukan perlindungan. Tampilkan dengan ip xfrm state, atau dengan swanctl --list-sas ketika strongSwan melakukan negosiasi, dan baca selektor serta penghitung pada setiap entri.
Ketika kebijakan cocok dan tidak ada asosiasi yang mencakup selektor yang sama, paket dibuang alih-alih dikirim dalam teks polos. Itulah pembuangan yang harus dicari ketika terowongan aktif tetapi satu subnet gagal. Penghitung mengatakan sisanya: asosiasi yang tidak pernah bertambah tidak pernah dipilih, sedangkan yang bertambah dan tetap berakhir pada pembuangan menunjuk ke sisi jauh. Memperbaiki selektor dan memperbarui kunci adalah perbaikan yang berbeda, jadi putuskan mana yang Anda butuhkan sebelum menyentuh konfigurasi.
Apa yang masih dibutuhkan terowongan berbasis rute
Antarmuka XFRM membuat terowongan tampak seperti perangkat yang dapat Anda rutekan, yang benar-benar berguna. Itu tidak menghapus kebijakan dan keadaan yang menentukan apa yang terjadi setelah paket tiba di sana. Rute menyumbang hop berikutnya dan tidak lebih.
Jika perangkat ada dan rute menunjuk ke dalamnya sementara tidak ada asosiasi yang cocok dengan selektor dalam, paket dibuang, dan tidak ada jumlah pengeditan rute yang menghasilkan kunci atau selektor. Periksa antarmuka dengan sumber dan tujuan yang sama seperti yang Anda rutekan, lalu bandingkan dengan daftar keadaan.
Tetapkan kepemilikan sebelum mengedit apa pun
Firewall host menambahkan keputusan ketiga yang tidak diketahui oleh kedua basis data. Rute yang benar plus kebijakan yang cocok plus asosiasi yang terpasang masih bisa berakhir pada paket yang dibuang, dan aplikasi hanya melaporkan batas waktu. Pastikan firewall mengizinkan lalu lintas terlindungi sebelum menyalahkan IPsec. Menangkap di perangkat terowongan dan di antarmuka fisik menunjukkan di sisi mana enkripsi paket itu menghilang.
Kepemilikan konfigurasi menentukan apakah perbaikan Anda bertahan setelah mulai ulang. Satu komponen dapat memasang keadaan sementara komponen lain mengelola rute, dan pengeditan manual pada yang kedua ditimpa saat terowongan naik berikutnya. Ubah konfigurasi pemilik, lalu baca kembali kedua tampilan; RFC 4301 menjaga kedua basis data tetap terpisah ketika Anda harus menjelaskan pemisahan itu kepada orang lain.