Tunnel penuh di strongSwan membutuhkan 0.0.0.0/0 di kedua sisi

Koneksi strongSwan yang bekerja untuk satu subnet privat tidak akan membawa lalu lintas internet hanya karena seseorang mengedit satu baris. Tunnel penuh adalah kesepakatan antara dua pihak tentang alamat mana yang dilindungi child SA, dan setiap pihak menyebut pihak lain relatif terhadap dirinya sendiri. Benarkan satu sisi dan salahkan sisi lain, maka child SA entah tidak naik atau naik lebih sempit dari yang dimaksud. Lima pemeriksaan di bawah mengikuti kesepakatan itu dari klien, melalui gateway, dan keluar ke internet.

Periksa dulu selektor klien

Klien menjelaskan apa yang ingin dilindungi di sisi jauh sebagai remote_ts, dan semua yang dikirimnya berasal dari alamatnya sendiri yang diberikan. Untuk lalu lintas internet nilai itu harus mencakup tujuan yang benar-benar akan dicapai pengguna, yang dalam praktik berarti seluruh ruang IPv4. Klien yang masih mencantumkan satu subnet meminta tunnel terpisah, apa pun nama profil di antarmuka. Sisi sumber biasanya dynamic karena alamat diberikan saat terhubung. Sumber tetap yang ditulis di sana rusak begitu kumpulan alamat berubah.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Fragmen ini bukan berkas koneksi lengkap, dan yang ini mengasumsikan autentikasi, identitas, dan kumpulan alamat virtual sudah dikonfigurasi. Selektor sumber klien dan alamat yang diberikan server tetap harus cocok, atau child SA naik dengan cakupan yang tidak diharapkan kedua pihak. Muat dengan swanctl --load-all dan baca keluarannya sebelum menganggap berhasil. Berkas yang berhasil diurai masih bisa ditolak karena selektor yang tidak tumpang tindih dengan proposal pihak lain.

Periksa selektor gateway di sisinya sendiri

Gateway membaca konsep yang sama dari arah berlawanan. Tujuan internet bersifat lokal bagi gateway, jadi local_ts-nya adalah yang lebar dan remote_ts-nya menjelaskan kumpulan klien. Pembalikan itu adalah kesalahan paling umum dalam konfigurasi tunnel penuh, dan lolos tinjauan karena kedua baris tampak masuk akal secara terpisah.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Menyalin fragmen klien ke berkas gateway menghasilkan pasangan selektor yang tidak menjelaskan apa pun yang berguna, karena kedua sisi akan mengklaim peran yang sama. Panduan penerusan strongSwan mendokumentasikan pemasangan klien dan gateway secara eksplisit, dan layak dibaca di samping berkas koneksi alih-alih setelah kegagalan. Berkas gateway juga membutuhkan definisi kumpulan alamat yang dirujuk remote_ts. Selektor yang menyebut kumpulan yang tidak ada dimuat tanpa keluhan dan gagal saat terhubung.

ipsec.conf lama memakai peran kiri dan kanan dengan kunci berbeda, dan baris rightsubnet bukan pengganti langsung nilai swanctl. Simpan kedua sintaksis di berkas terpisah alih-alih menempelkan yang satu ke yang lain. Mencampurnya dalam satu direktori adalah cara koneksi yang berfungsi diam-diam kembali setelah reboot.

Periksa child SA yang dinegosiasikan, bukan berkasnya

Konfigurasi yang tersimpan membuktikan niat dan tidak lebih. Pihak lain dapat mempersempit yang diminta, dan child SA yang ada tidak diganti hanya karena berkas di bawahnya berubah. Pastikan apa yang benar-benar terpasang sebelum mengubah hal lain.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Perintah pertama menunjukkan apa yang dimuat daemon, yang kedua menunjukkan child SA yang terbentuk, dan yang ketiga menunjukkan kebijakan yang akan diterapkan kernel. Jika berkas menyebut 0.0.0.0/0 dan daftar menunjukkan satu subnet, negosiasi mempersempit cakupan dan membaca ulang berkas tidak akan menjelaskannya. Hentikan child, mulai ulang, dan bandingkan ketiga keluaran lagi. Child yang kembali dengan cakupan sempit yang sama dipersempit oleh sisi jauh, bukan oleh berkas lokal, dan itu adalah percakapan dengan administrator lain, bukan suntingan lokal.

Baca kedua arah dalam daftar kebijakan, karena tunnel yang memasang satu arah dan bukan yang lain adalah masalah perutean dalam kostum konfigurasi. Kebijakan maju dan balik harus menyebut pasangan selektor yang sama dalam bayangan cermin, dan cermin yang hilang adalah cacat pada daemon atau pada proposal, bukan pada teks selektor.

Periksa penerusan dan jalur balik

Selektor mengizinkan lalu lintas ke gateway; itu tidak membuat gateway merutekan lalu lintas tersebut lebih jauh. Penerusan harus diaktifkan, firewall harus mengizinkan aliran, dan balasan harus menemukan jalan kembali ke kumpulan klien. Itu tiga persyaratan terpisah, dan masing-masing gagal dengan gejala berbeda. Aturan penerusan yang hilang berperilaku seperti lubang hitam, sedangkan rute balik yang hilang berperilaku seperti tunnel satu arah.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Alamat klien privat biasanya memerlukan terjemahan sumber yang disengaja sebelum dapat meninggalkan antarmuka publik, sedangkan alokasi yang dirutekan secara eksplisit memerlukan perlakuan berbeda. Jika NAT terlibat, pertahankan pengecualian yang didukung implementasi agar lalu lintas yang harus diperiksa kebijakan keamanan tidak diterjemahkan melewatinya. Aturan masquerade lebar yang disalin dari gateway lain mengubah jauh lebih banyak aliran daripada yang dimaksud penulisnya. Tulis aturan hanya untuk kumpulan klien, dan tinggalkan komentar mengapa aturan itu ada.

Di klien, pastikan rute yang dipasang backend, bukan rute yang Anda asumsikan. Manajer dengan pemasangan rute dinonaktifkan memerlukan desain perutean yang dirawat manual, dan desain itu harus diperbarui setiap kali tunnel berubah. Periksa tabel perutean setelah menyambung ulang, bukan hanya setelah boot baru.

Periksa apa yang masih belum dicakup tunnel

Pasangan selektor mencakup IPv4 dan tidak lebih. IPv6, DNS, dan kebijakan tingkat aplikasi apa pun adalah keputusan terpisah yang diabaikan diam-diam oleh selektor IPv4 yang lebar. Tunnel yang membawa setiap paket IPv4 masih bisa membocorkan setiap pencarian nama.

Nyatakan jalur DNS yang dimaksud secara eksplisit, karena tunnel penuh yang masih menyelesaikan nama melalui resolver lokal membocorkan kueri ke luar tunnel dan merusak nama privat. Jika klien diberi alamat IPv6, keluarga alamat itu memerlukan perlakuan yang sama, atau host akan memilih jalur yang tidak dilindungi tunnel. Uji dengan nama yang hanya bisa dijawab sisi privat, dan perlakukan jawaban publik sebagai kebocoran.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Pastikan rantai dengan dua perintah itu plus selektor yang dinegosiasikan dari daftar di atas. Jika traceroute menunjukkan router lokal sebagai lompatan pertama, lalu lintas tidak memakai tunnel apa pun yang diklaim selektor. Akses internet baru lengkap ketika lalu lintas yang dipilih diterima, diteruskan, dan dikembalikan melalui gateway yang dirancang. Menemukan 0.0.0.0/0 dalam profil adalah awal rantai itu, bukan buktinya.