Klien WireGuard tidak dapat menjangkau klien OpenVPN?

Kedua terowongan tersambung, setiap klien dapat menjangkau gateway, dan saat satu mencoba alamat yang lain paketnya menghilang. Tidak ada yang salah pada salah satu jabat tangan, dan menerbitkan ulang kunci tidak mengubahnya. Gateway membawa paket IP biasa yang tidak terenkripsi di antara dua antarmukanya sendiri, jadi protokolnya tidak pernah perlu saling memahami; yang mereka butuhkan adalah tiga hal yang tidak diberikan jabat tangan mana pun. Cakupan tujuan pada klien asal, kepemilikan sumber di gateway, dan jalur balik di sisi jauh. Gejalanya sama untuk ketiganya, karena itu didiagnosis bersama.

Gejalanya selalu kurang satu bagian

Desain ini memakai kumpulan WireGuard 10.71.0.0/24 pada wg1 dan kumpulan OpenVPN 10.72.0.0/24 pada tun1, keduanya berakhir di satu gateway. Permintaan yang diuji berjalan dari 10.71.0.5 ke HTTPS pada 10.72.0.30. Setiap langkah di bawah membahas satu aliran itu. Setiap pemeriksaan punya tanda kegagalan berbeda meski pengguna mengalaminya sama, dan biasanya hanya satu dari ketiganya yang hilang pada satu waktu.

Mulailah dengan memastikan kedua kumpulan benar-benar ada di gateway ini dan penerusan aktif di namespace tempat terowongan itu hidup. Gateway yang mengakhiri kedua protokol di namespace berbeda tidak meneruskan apa pun di antaranya, dan itu layak disingkirkan sebelum membaca konfigurasi peer mana pun.

Perluas cakupan tujuan pada spoke

Pada klien WireGuard, entri peer yang ada harus memilih gateway untuk tujuan OpenVPN, artinya prefiks tujuan harus muncul di daftar yang diizinkan peer itu. Menambahkannya tidak membuat terowongan kedua; itu mengubah peer mana yang dipilih klien saat mencari alamat tersebut, dan dengan wg-quick rutenya biasanya mengikuti daftar secara otomatis.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Biarkan baris kunci dan titik akhir yang sebenarnya tidak tersentuh, dan ingat bahwa pengelola yang memakai Table = off sama sekali tidak mengambil rute dari daftar ini. Dalam kasus itu prefiks yang sama harus dipasang di tabel rute sistem oleh siapa pun yang memilikinya, dan rute yang hilang di sana tampak persis seperti prefiks yang diizinkan yang hilang.

Pertahankan kepemilikan sumber di gateway

Entri peer klien ini di gateway harus tetap memiliki tepat alamat sumber klien tersebut. Alamat yang diizinkan diperiksa di kedua arah: keduanya memilih peer untuk lalu lintas keluar dan memvalidasi bahwa sumber paket masuk milik peer yang mengirimnya. Menaruh kumpulan OpenVPN ke dalam entri spoke karena spoke ingin menjangkaunya adalah kesalahan yang mengarahkan lalu lintas ke peserta yang salah.

AllowedIPs = 10.71.0.5/32

Bacalah entri itu sebagai pernyataan kepemilikan, bukan kemudahan perutean. Apa pun yang perlu dijangkau klien ada di daftar tujuan klien, bukan di bayangan gateway tentang apa yang boleh dikirim peer ini.

Beri sisi OpenVPN rute balik

Tujuan sekarang memerlukan rute kembali ke sumber WireGuard, dan bagi klien dari kumpulan itu biasanya datang sebagai rute yang didorong dari server OpenVPN. Dorong hanya kepada klien yang seharusnya memilikinya, dan pastikan di klien bahwa rute itu diterima, bukan mengasumsikan direktifnya sudah diterapkan.

push "route 10.71.0.0 255.255.255.0"

Distribusi rute bukan otorisasi. Ketika tujuan berada di belakang klien OpenVPN lain alih-alih di dalam kumpulan, kepemilikan LAN klien itu sendiri dan persyaratan penerusannya ikut masuk ke desain, dan rute yang didorong hanyalah separuh pertama. Rumuskan ulang persyaratannya sebagai graf sebelum menambah direktif: simpul mana yang memiliki prefiks mana, dan simpul mana yang meneruskan ke arahnya.

Izinkan hanya satu layanan yang memang ingin Anda izinkan

Dengan penerusan aktif dan kedua kumpulan dapat dirutekan, pertanyaan yang tersisa adalah kebijakan. Tulis aturannya untuk aliran tertentu, bukan untuk pasangan antarmuka secara umum, pratinjau dulu sebelum diterapkan, dan pertahankan jalur balik yang sadar status agar balasan tidak diblokir sebagai koneksi baru. Uji kering tidak memakan biaya dan menunjukkan persis apa yang akan ditambahkan.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Ini aturan untuk lalu lintas yang diteruskan, terpisah dari aturan pendengaran gateway untuk kedua layanan VPN. Membuka port UDP luar tidak mengotorisasi permintaan dalam, dan mengotorisasi permintaan dalam tidak menuntut SSH tanpa batas ke gateway atau izin bawaan pada penerusan. Firewall tujuan dan alamat pendengarannya juga harus cocok, sebab layanan yang terikat ke loopback menolak paket yang paling hati-hati dirutekan sekalipun. Kebijakan yang hanya mencakup satu arah percakapan biasanya gagal dengan permintaan yang berhasil dan balasan yang senyap, dan itulah hasil paling membingungkan dari ketiganya.

Rute timbal balik biasanya berarti tidak perlu terjemahan sumber, yang mempertahankan alamat WireGuard di tujuan dan membuat log mudah dibaca. Jangan menambahkan masquerading menyeluruh karena dua protokol terlibat, dan jangan menghapus aturan terjemahan yang ada tanpa tahu apa yang bergantung padanya. Lalu verifikasi aliran tunggal itu dari ujung ke ujung, dan uji juga satu sumber atau port yang dilarang: jabat tangan yang bekerja di kedua sisi tidak membuktikan rute silang maupun isolasinya.