Profil WireGuard untuk get laluan IPsec: apa yang patut ditanya

Tamat masa jabat tangan dengan get laluan senyap biasanya bermaksud dua protokol yang tidak pernah bertemu. Rakan WireGuard bertutur Noise manakala get laluan IPsec menunggu IKE. Alamat dan port yang betul tidak mengubahnya.

Menggunakan semula titik akhir dalam profil tidak menjambatani keduanya. Langkah seterusnya ialah permintaan kepada pihak yang mengendalikan get laluan.

Permintaan pertama: versi protokol

IPsec menamakan keluarga, bukan satu aliran kerja. IKEv2 dan IKEv1 berbeza dalam pertukaran, pilihan pengesahan dan tingkah laku semasa perubahan rangkaian. Get laluan yang hanya menamatkan IKEv1 akan berkelakuan jauh berbeza daripada yang menawarkan IKEv2. Konfigurasi klien turut berubah.

Tanya versi mana yang ditamatkan oleh perkhidmatan dan sama ada ia menjalankan pelaksanaan berasaskan piawaian atau varian vendor dengan klien sendiri. Menu sistem pengendalian sering menyembunyikan jawapan itu di sebalik satu label. Label bukanlah protokol.

Permintaan kedua: kaedah pengesahan klien

Pengesahan ialah tempat sebahagian besar kerja sebenar berada. Perkhidmatan mungkin menjangkakan sijil mesin dengan penggunaan kunci lanjutan tertentu, sijil pengguna, kaedah EAP di atas IKEv2, atau kunci yang dikongsi terlebih dahulu dan terikat pada identiti. Yang mana terpakai menentukan apa yang diperlukan oleh klien.

Kunci peribadi WireGuard bukanlah mana-mana daripada itu. Ia kunci Curve25519 yang digunakan dalam satu jabat tangan tertentu. Tiada penukaran menjadikannya sijil atau kelayakan EAP. Alat yang mendakwa sebaliknya sedang menukar nama fail atau menjana sesuatu yang tidak berkaitan.

Spesifikasi IKEv2 dalam RFC 7296 menerangkan apa yang mesti disokong oleh pelaksanaan versi itu. Ia rujukan untuk jawapan pengendali yang kabur, bukan panduan konfigurasi klien.

Permintaan ketiga: identiti dipercayai dan destinasi

Minta identiti get laluan seperti yang perlu dilihat oleh klien, serta sauh kepercayaan yang mengesahkannya. Kemudian tanya julat peribadi dan penyelesai mana yang ditolak oleh perkhidmatan. Dua jawapan itu menentukan apa yang sebenarnya dibawa oleh terowong.

Tanpanya, sambungan yang berfungsi masih boleh gagal melaksanakan tugas. Terowong yang naik tanpa penyelesai yang ditolak membiarkan nama dalaman tidak terjawab. Pemilih trafik yang tiada membiarkan destinasi di luar terowong walaupun jabat tangan berjaya.

Penyiasatan titik akhir menjawab soalan yang berbeza daripada ralat klien. Port yang boleh dicapai tanpa persekutuan menunjukkan pengesahan, manakala port yang tidak boleh dicapai menunjukkan laluan.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Jalankan siasatan itu sebelum mengubah apa-apa pada klien. Jika port menjawab dan persekutuan masih gagal, masalahnya ialah kelayakan atau dasar. Jika ia langsung tidak menjawab, tiada suntingan profil akan membantu.

Apabila kedua-dua protokol mesti wujud bersama

Mentadbir kedua-dua rangkaian ialah sebab sah untuk mengekalkan kedua-dua protokol. Reka bentuk biasa menamatkan WireGuard dan IPsec pada antara muka berasingan atau get laluan berasingan. Trafik yang diluluskan kemudian dihalakan antara keduanya.

Reka bentuk itu memperkenalkan sempadan kepercayaan dan kebenaran, dan ia harus dicatat sedemikian. Rakan mana yang boleh melintas, ke arah mana dan di bawah dasar siapa ialah keputusan penghalaan dan tembok api. Tiada satu pun protokol menyediakannya.

Apa yang bukan ialah penukaran telus. Trafik yang tiba melalui WireGuard dijana semula ke dalam terowong IPsec, dan setiap dasar di antaranya terpakai kepadanya.

Jelaskan dahulu keperluan protokol dan pengesahan pelayan. Kemudian gunakan klien dan laluan pendaftaran yang disokong pengendali, dan jauhkan kunci peribadi daripada penukar web sepanjang itu.