strongSwan ke AWS Site-to-Site: mengapa Child SA tidak memilih apa pun

Tunnel IKE bisa aktif sementara asosiasi anak mengecualikan subnet Anda. Bandingkan dulu CIDR lokal dan jarak jauh AWS dengan leftsubnet dan rightsubnet.

Konsol menampilkan up, strongSwan melaporkan asosiasi IKE yang terbentuk, dan paket tetap tidak sampai. Hal berikutnya yang perlu dibandingkan bukan kunci yang dibagikan sebelumnya, melainkan pasangan prefiks yang diyakini setiap sisi dilindungi tunnel. Jalankan pemeriksaan di bawah ini secara berurutan, karena dua yang pertama menentukan apakah tunnel sanggup membawa lalu lintas Anda sama sekali.

Terjemahkan nama AWS ke istilah strongSwan

AWS menjelaskan koneksi dari sisi pelanggan: alamat gateway pelanggan dan CIDR lokal milik Anda, dan CIDR jarak jauh milik VPC. strongSwan menyebut kedua ujung sebagai left dan right, dengan prefiks Anda di leftsubnet dan prefiks VPC di rightsubnet. Membalik satu pasangan menghasilkan tunnel yang menegosiasikan dan memilih lalu lintas yang salah.

Unduh konfigurasi yang dibuat AWS untuk koneksi itu dan jadikan rujukan untuk koneksi tersebut, termasuk alamat dan prefiks tunnel. Membiarkan kedua kolom CIDR kosong saat pembuatan membuat layanan memakai bawaan 0.0.0.0/0 di tiap sisi. Router yang dikonfigurasi dengan prefiks sempit lalu tidak akan pernah cocok, jadi isi kolomnya atau lebarkan pemilih dengan sengaja.

Ketidakcocokan di sini tampak seperti kegagalan perutean dan sebenarnya bukan.

Kunci alamat yang benar-benar dilihat AWS

Router di belakang NAT dapat mengirim IKE dari antarmuka yang tidak pernah dikenal sisi jauh. Alamat gateway yang tercatat di AWS harus yang diamati AWS di jaringan, dan router harus dipatok ke alamat lokal yang sama alih-alih mengikuti rute bawaannya.

conn %default
    local_addrs = 203.0.113.10

Di strongSwan, local_addrs memilih alamat sumber untuk IKE, dan konfigurasi OpenSwan lama menulis gagasan yang sama sebagai left. Arahkan ke antarmuka yang memiliki alamat publik, lalu pastikan di perangkat NAT itu sendiri bahwa UDP 500 dan 4500 mencapai host tersebut, karena aturan sisa dari router sebelumnya membuangnya diam-diam. Pasangan pemilih yang benar dengan alamat sumber yang salah tetap gagal, dan log akan menyalahkan proposal. Kesesatan itulah sebabnya alamat sumber layak diperiksa sendiri.

Pastikan aturan penerusan alih-alih menganggapnya, karena aturan yang dulu benar untuk router sebelumnya sering tertinggal.

Tangani fase 1 dan fase 2 secara terpisah

AWS menampilkan opsi IKE dan ESP sebagai daftar terpisah. Suite IKE yang diterima kedua sisi tidak mengatakan apa pun tentang proposal ESP, karena kedua daftar itu independen. Baca keduanya dari konfigurasi yang dihasilkan lalu bandingkan satu per satu.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Sintaks tidak berpindah antarpelaksanaan. Pasangan yang berfungsi di OpenSwan, misalnya phase2alg=aes_gcm dengan ike=aes256-sha1;modp1024, perlu diterjemahkan ke bentuk esp= dan ike= strongSwan, dan nama algoritmanya berbeda. Karena GCM mengautentikasi saat mengenkripsi, ia tidak memerlukan transformasi integritas terpisah, tidak seperti suite CBC yang dipasangkan dengan SHA. Baris fase 2 yang ditempel dari satu daemon ke daemon lain tanpa terjemahan menghasilkan penolakan yang terbaca seperti ketidakcocokan pemilih.

Periksa asosiasi anak, bukan indikator tunnel

Jika koneksi termuat tetapi tidak ada asosiasi anak yang muncul, proposal atau pemilihnya ditolak. Jika anak muncul dan pemilihnya mengecualikan prefiks Anda, paket disaring sebelum mencapai tunnel. Indikator konsol hanya mencakup tingkat IKE, jadi tidak bisa memberi tahu mana dari keduanya yang terjadi.

ipsec statusall

Cari asosiasi keamanan anak dan baca pemilih lalu lintas yang tercetak di sampingnya, lalu bandingkan dengan prefiks dari konfigurasi yang dihasilkan.

Uji dari host di dalam prefiks lokal ke host di dalam prefiks VPC, dan periksa jalur balik serta grup keamanan atau ACL jaringan mana pun di sisi AWS. Pemilih yang benar tidak melindungi paket dari kemungkinan dibuang nanti.

Saat masih gagal setelah pemilih cocok

Pastikan rute di kedua sisi mengarah ke tunnel, lalu pastikan perangkat NAT tidak menulis ulang lalu lintas dengan cara yang tidak diharapkan kebijakan. Tunnel berbasis kebijakan mencocokkan alamat paket, jadi terjemahan yang diterapkan setelah keputusan kebijakan mengubah hasilnya.

Catat satu paket masuk dan satu paket keluar di tiap sisi sebelum mengubah proposal lain.

Catat pemilih, proposal fase 1 dan fase 2, serta alamat sumber di tiket. Empat nilai itu menjelaskan sebagian besar kegagalan site-to-site tanpa panggilan.

Artikel terkait