Profil WireGuard untuk gateway IPsec: apa yang sebaiknya ditanyakan

Batas waktu handshake dengan gateway yang diam biasanya berarti dua protokol yang tidak pernah bertemu. Peer WireGuard berbicara Noise sementara gateway IPsec menunggu IKE. Alamat dan port yang benar tidak mengubahnya.

Menggunakan ulang endpoint dalam profil tidak menjembatani keduanya. Langkah berikutnya adalah permintaan kepada pihak yang menjalankan gateway.

Permintaan pertama: versi protokol

IPsec menamai sebuah keluarga, bukan satu alur kerja. IKEv2 dan IKEv1 berbeda dalam pertukaran, pilihan autentikasi, dan perilakunya saat jaringan berubah. Gateway yang hanya mengakhiri IKEv1 akan berperilaku sangat berbeda dari gateway yang menawarkan IKEv2. Konfigurasi klien ikut berbeda.

Tanyakan versi mana yang diakhiri layanan dan apakah ia menjalankan implementasi berbasis standar atau varian vendor dengan klien sendiri. Menu sistem operasi sering menyembunyikan jawaban itu di balik satu label. Label bukanlah protokol.

Permintaan kedua: metode autentikasi klien

Autentikasi adalah tempat sebagian besar pekerjaan nyata berada. Layanan mungkin mengharapkan sertifikat mesin dengan penggunaan kunci diperluas tertentu, sertifikat pengguna, metode EAP di atas IKEv2, atau kunci yang dibagikan sebelumnya dan terikat pada identitas. Yang mana yang berlaku menentukan apa yang dibutuhkan klien.

Kunci privat WireGuard bukanlah salah satu dari itu. Itu adalah kunci Curve25519 yang dipakai dalam satu handshake tertentu. Tidak ada konversi yang menjadikannya sertifikat atau kredensial EAP. Alat yang mengklaim sebaliknya sedang mengganti nama berkas atau menghasilkan sesuatu yang tidak terkait.

Spesifikasi IKEv2 dalam RFC 7296 menjelaskan apa yang harus didukung implementasi versi itu. Itu adalah rujukan untuk jawaban operator yang kabur, bukan panduan konfigurasi klien.

Permintaan ketiga: identitas tepercaya dan tujuan

Mintalah identitas gateway seperti yang harus dilihat klien, ditambah jangkar kepercayaan yang memvalidasinya. Lalu tanyakan rentang privat dan resolver mana yang didorong layanan. Dua jawaban itu menentukan apa yang sebenarnya dibawa terowongan.

Tanpa keduanya, koneksi yang berfungsi tetap bisa gagal menyelesaikan tugas. Terowongan yang naik tanpa resolver yang didorong membiarkan nama internal tidak terjawab. Pemilih lalu lintas yang hilang membiarkan tujuan di luar terowongan meskipun handshake berhasil.

Penyelidikan endpoint menjawab pertanyaan yang berbeda dari kesalahan klien. Port yang dapat dijangkau tanpa asosiasi menunjuk ke autentikasi, sedangkan port yang tidak dapat dijangkau menunjuk ke jalur.

# 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 penyelidikan itu sebelum mengubah apa pun di klien. Jika port menjawab dan asosiasi masih gagal, masalahnya ada pada kredensial atau kebijakan. Jika tidak menjawab sama sekali, tidak ada penyuntingan profil yang akan membantu.

Ketika kedua protokol harus hidup berdampingan

Mengelola kedua jaringan adalah alasan sah untuk mempertahankan kedua protokol. Desain yang biasa mengakhiri WireGuard dan IPsec pada antarmuka terpisah atau gateway terpisah. Lalu lintas yang disetujui kemudian dirutekan di antara keduanya.

Desain itu memperkenalkan batas kepercayaan dan otorisasi, dan batas itu harus dicatat sebagai demikian. Peer mana yang boleh menyeberang, ke arah mana, dan di bawah kebijakan siapa adalah keputusan perutean dan firewall. Tidak ada protokol yang menyediakannya.

Yang bukan merupakan konversi transparan. Lalu lintas yang tiba melalui WireGuard dibuat ulang ke dalam terowongan IPsec, dan setiap kebijakan di antaranya berlaku padanya.

Jelaskan dulu persyaratan protokol dan autentikasi server. Lalu gunakan klien dan jalur pendaftaran yang didukung operator, dan jauhkan kunci privat dari konverter web selama itu berlangsung.