Klien WireGuard tidak dapat mencapai klien OpenVPN?

Kedua-dua terowong bersambung, setiap klien boleh mencapai gateway, dan pada saat satu cuba alamat yang lain, paket hilang. Tiada apa yang salah pada mana-mana jabat tangan, dan mengeluarkan semula kunci tidak mengubahnya. Gateway membawa paket IP biasa yang tidak disulitkan antara dua antara muka miliknya sendiri, jadi protokol tidak perlu saling memahami; apa yang mereka perlukan ialah tiga perkara yang tidak diberikan oleh mana-mana jabat tangan. Liputan destinasi pada klien asal, pemilikan sumber di gateway dan laluan balik di sisi jauh. Gejalanya sama bagi ketiga-tiganya, sebab itu ia didiagnosis bersama.

Gejala kekurangan satu bahagian pada satu masa

Reka bentuk ini menggunakan kolam WireGuard 10.71.0.0/24 pada wg1 dan kolam OpenVPN 10.72.0.0/24 pada tun1, kedua-duanya berakhir pada satu gateway. Permintaan yang diuji bergerak dari 10.71.0.5 ke HTTPS pada 10.72.0.30. Setiap langkah di bawah adalah tentang satu aliran itu. Setiap semakan mempunyai tandatangan kegagalan yang berbeza walaupun pengguna mengalaminya sama, dan biasanya hanya satu daripada tiga yang hilang pada satu masa.

Mulakan dengan mengesahkan kedua-dua kolam benar-benar berada pada gateway ini dan pemajuan diaktifkan dalam ruang nama tempat terowong itu hidup. Gateway yang menamatkan kedua-dua protokol dalam ruang nama berbeza tidak memajukan apa-apa antaranya, dan itu wajar diketepikan sebelum membaca mana-mana konfigurasi rakan sebaya.

Luaskan liputan destinasi pada jejari

Pada klien WireGuard, entri rakan sebaya yang ada mesti memilih gateway untuk destinasi OpenVPN, bermakna awalan destinasi mesti muncul dalam senarai dibenarkan rakan sebaya itu. Menambahnya tidak mencipta terowong kedua; ia mengubah rakan sebaya mana yang dipilih klien apabila mencari alamat itu, dan dengan wg-quick laluan biasanya mengikut senarai secara automatik.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Biarkan baris kunci dan titik akhir sebenar tidak disentuh, dan ingat bahawa pengurus yang menggunakan Table = off tidak mengambil mana-mana laluan daripada senarai ini sama sekali. Dalam kes itu awalan yang sama mesti dipasang dalam jadual laluan sistem oleh sesiapa yang memilikinya, dan laluan yang hilang di situ kelihatan tepat seperti awalan dibenarkan yang hilang.

Kekalkan pemilikan sumber di gateway

Entri rakan sebaya klien ini di gateway harus terus memiliki tepat alamat sumber klien itu. Alamat dibenarkan diperiksa dalam kedua-dua arah: ia memilih rakan sebaya untuk trafik keluar dan ia mengesahkan bahawa sumber paket masuk milik rakan sebaya yang menghantarnya. Meletakkan kolam OpenVPN ke dalam entri jejari kerana jejari mahu mencapainya ialah kesilapan yang menghala trafik ke peserta yang salah.

AllowedIPs = 10.71.0.5/32

Baca entri itu sebagai pernyataan pemilikan dan bukan sebagai kemudahan laluan. Apa-apa lagi yang perlu dicapai klien tergolong dalam senarai destinasi klien, bukan dalam gambaran gateway tentang apa yang dibenarkan dihantar oleh rakan sebaya ini.

Beri sisi OpenVPN laluan balik

Destinasi kini memerlukan laluan kembali ke sumber WireGuard, dan bagi klien kolam ia biasanya tiba sebagai laluan yang ditolak dari pelayan OpenVPN. Tolak ia hanya kepada klien yang sepatutnya memilikinya, dan sahkan pada klien bahawa ia diterima dan bukan menganggap arahan itu telah digunakan.

push "route 10.71.0.0 255.255.255.0"

Pengagihan laluan bukan kebenaran. Apabila destinasi berada di belakang klien OpenVPN lain dan bukan di dalam kolam, pemilikan LAN klien itu sendiri dan keperluan pemajuannya turut masuk ke dalam reka bentuk, dan laluan yang ditolak hanyalah separuh pertama. Rumuskan semula keperluan sebagai graf sebelum menambah arahan: nod mana memiliki awalan mana, dan nod mana memajukan ke arahnya.

Benarkan hanya satu perkhidmatan yang anda maksudkan untuk dibenarkan

Dengan pemajuan diaktifkan dan kedua-dua kolam boleh dilalui, persoalan yang tinggal ialah dasar. Tulis peraturan untuk aliran tertentu dan bukan untuk pasangan antara muka secara umum, pratonton ia sebelum digunakan, dan kekalkan laluan balik yang menyimpan keadaan supaya balasan tidak disekat sebagai sambungan baharu. Ujian kering tidak memerlukan kos dan menunjukkan dengan tepat apa yang akan ditambah.

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 peraturan untuk trafik yang dimajukan, berasingan daripada peraturan mendengar gateway untuk kedua-dua perkhidmatan VPN. Membuka port UDP luar tidak membenarkan permintaan dalam, dan membenarkan permintaan dalam tidak memerlukan SSH tanpa had ke gateway atau kebenaran lalai pada pemajuan. Firewall destinasi sendiri dan alamat mendengarnya juga mesti sepadan, kerana perkhidmatan yang terikat pada loopback menolak paket yang paling teliti dilalui. Dasar yang hanya meliputi satu arah perbualan biasanya gagal dengan permintaan berjaya dan balasan senyap, dan itulah hasil paling mengelirukan daripada ketiga-tiganya.

Laluan timbal balik biasanya bermakna tiada terjemahan sumber diperlukan, yang mengekalkan alamat WireGuard di destinasi dan menjadikan log mudah dibaca. Jangan tambah masquerading menyeluruh kerana dua protokol terlibat, dan jangan buang peraturan terjemahan sedia ada tanpa mengetahui apa yang bergantung padanya. Kemudian sahkan aliran tunggal itu dari hujung ke hujung, dan uji juga satu sumber atau port yang tidak dibenarkan: jabat tangan yang berfungsi di kedua-dua belah tidak membuktikan laluan silang mahupun pengasingan.