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

Konsol menunjukkan up, strongSwan melaporkan persatuan IKE yang terjalin, dan paket masih tidak tiba. Perkara seterusnya yang perlu dibandingkan bukan kunci yang dikongsi terlebih dahulu, tetapi pasangan awalan yang dipercayai setiap pihak dilindungi terowong. Lakukan pemeriksaan di bawah mengikut urutan, kerana dua yang pertama menentukan sama ada terowong itu mampu membawa trafik anda sama sekali.

Terjemahkan nama AWS ke istilah strongSwan

AWS menerangkan sambungan dari pihak pelanggan: alamat get laluan pelanggan dan CIDR setempat milik anda, dan CIDR jauh milik VPC. strongSwan menamakan kedua-dua hujung sebagai left dan right, dengan awalan anda dalam leftsubnet dan awalan VPC dalam rightsubnet. Membalikkan satu pasangan menghasilkan terowong yang merunding dan memilih trafik yang salah.

Muat turun konfigurasi yang AWS jana untuk sambungan itu dan anggap ia sebagai rujukan untuk sambungan tersebut, termasuk alamat dan awalan terowong. Jika kedua-dua medan CIDR dibiarkan kosong semasa penciptaan, perkhidmatan menggunakan lalai 0.0.0.0/0 pada setiap pihak. Penghala yang dikonfigurasikan dengan awalan sempit kemudian tidak akan pernah sepadan, jadi isi medan itu atau luaskan pemilih dengan sengaja.

Ketidakpadanan di sini kelihatan seperti kegagalan penghalaan dan memang bukan.

Kunci alamat yang benar-benar dilihat oleh AWS

Penghala di belakang NAT boleh menghantar IKE dari antara muka yang tidak pernah diketahui pihak jauh. Alamat get laluan yang direkodkan dalam AWS mesti yang diperhatikan AWS pada rangkaian, dan penghala mesti dipasak pada alamat setempat yang sama dan bukannya mengikut laluan lalainya.

conn %default
    local_addrs = 203.0.113.10

Dalam strongSwan, local_addrs memilih alamat sumber untuk IKE, dan konfigurasi OpenSwan lama menulis idea yang sama sebagai left. Halakan ia ke antara muka yang memegang alamat awam, kemudian sahkan pada peranti NAT itu sendiri bahawa UDP 500 dan 4500 sampai ke hos tersebut, kerana peraturan yang tinggal dari penghala terdahulu membuangnya secara senyap. Pasangan pemilih yang betul dengan alamat sumber yang salah tetap gagal, dan log akan menyalahkan cadangan. Kesesatan itulah sebabnya alamat sumber wajar diperiksa sendiri.

Sahkan peraturan penghantaran dan jangan anggap ia, kerana peraturan yang betul untuk penghala terdahulu sering tertinggal.

Kendalikan fasa 1 dan fasa 2 secara berasingan

AWS memaparkan pilihan IKE dan ESP sebagai senarai berasingan. Sut IKE yang diterima kedua-dua pihak tidak mengatakan apa-apa tentang cadangan ESP, kerana kedua-dua senarai itu bebas. Baca kedua-duanya daripada konfigurasi yang dijana dan bandingkan satu demi satu.

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

Sintaks tidak berpindah antara pelaksanaan. Pasangan yang berfungsi dalam OpenSwan, misalnya phase2alg=aes_gcm dengan ike=aes256-sha1;modp1024, perlu diterjemahkan ke bentuk esp= dan ike= strongSwan, dan nama algoritma berbeza. Oleh sebab GCM mengesahkan semasa menyulitkan, ia tidak memerlukan transformasi integriti berasingan, tidak seperti sut CBC yang dipasangkan dengan SHA. Baris fasa 2 yang ditampal dari satu daemon ke daemon lain tanpa terjemahan menghasilkan penolakan yang terbaca seperti ketidakpadanan pemilih.

Periksa persatuan anak, bukan penunjuk terowong

Jika sambungan dimuatkan tetapi tiada persatuan anak muncul, cadangan atau pemilih telah ditolak. Jika anak muncul dan pemilihnya mengecualikan awalan anda, paket ditapis sebelum sampai ke terowong. Penunjuk konsol hanya meliputi tahap IKE, jadi ia tidak dapat memberitahu yang mana antara kedua-duanya berlaku.

ipsec statusall

Cari persatuan keselamatan anak dan baca pemilih trafik yang dicetak di sebelahnya, kemudian bandingkan dengan awalan daripada konfigurasi yang dijana.

Uji dari hos dalam awalan setempat ke hos dalam awalan VPC, dan periksa laluan balik serta mana-mana kumpulan keselamatan atau ACL rangkaian di pihak AWS. Pemilih yang betul tidak melindungi paket daripada dibuang kemudian.

Apabila masih gagal selepas pemilih sepadan

Sahkan laluan pada kedua-dua pihak menuju terowong, kemudian sahkan peranti NAT tidak menulis semula trafik dengan cara yang tidak dijangka oleh dasar. Terowong berasaskan dasar memadankan alamat paket, jadi terjemahan yang digunakan selepas keputusan dasar mengubah hasilnya.

Catatkan satu paket masuk dan satu paket keluar pada setiap pihak sebelum menukar cadangan lain.

Catatkan pemilih, cadangan fasa 1 dan fasa 2 serta alamat sumber dalam tiket. Empat nilai itu menerangkan kebanyakan kegagalan site-to-site tanpa panggilan.