WireGuard müştərisi OpenVPN müştərisinə çata bilmir?

Hər iki tunel qoşulur, hər müştəri şlüzə çata bilir və biri digərinin ünvanını sınadığı anda paketlər yox olur. Heç bir əl sıxışmada qüsur yoxdur və açarların yenidən verilməsi bunu dəyişmir. Şlüz öz interfeyslərindən ikisi arasında adi şifrənməmiş IP paketlərini ötürür, yəni protokolların bir-birini başa düşməsi heç vaxt tələb olunmur; onlara lazım olan üç şeydir ki, heç bir əl sıxışma bunları vermir. Çıxış müştərisində hədəf əhatəsi, şlüzdə mənbə sahibliyi və qarşı tərəfdə qayıdış yolu. Simptom hər üçü üçün eynidir, buna görə də birlikdə diaqnoz edilirlər.

Simptomda hər dəfə bir parça çatışmır

Bu dizayn wg1 üzərində 10.71.0.0/24 WireGuard hovuzundan və tun1 üzərində 10.72.0.0/24 OpenVPN hovuzundan istifadə edir və hər ikisi bir şlüzdə sonlanır. Sınaqdan keçən sorğu 10.71.0.5 ünvanından 10.72.0.30 üzərindəki HTTPS-ə gedir. Aşağıdakı hər addım həmin bir axınla bağlıdır. Hər yoxlamanın fərqli uğursuzluq imzası var, baxmayaraq ki istifadəçi onları eyni cür yaşayır və adətən hər dəfə üçündən yalnız biri çatışmır.

Hər iki hovuzun həqiqətən bu şlüzdə olduğunu və tunellərin yaşadığı ad məkanında yönləndirmənin aktiv olduğunu təsdiqləyərək başlayın. Hər iki protokolu fərqli ad məkanlarında sonlandıran şlüz onlar arasında heç nə yönləndirmir və hər hansı peer konfiqurasiyasını oxumadan əvvəl bunu istisna etməyə dəyər.

Budaq tərəfin hədəf əhatəsini genişləndirin

WireGuard müştərisində mövcud peer qeydi OpenVPN hədəfi üçün şlüzü seçməlidir, yəni hədəf prefiksi həmin peer-in icazəli siyahısında görünməlidir. Onu əlavə etmək ikinci tunel yaratmır; müştərinin həmin ünvanı axtararkən hansı peer-i seçdiyini dəyişir və wg-quick ilə marşrut adətən siyahını avtomatik izləyir.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Əsl açar və endpoint sətirlərinə toxunmayın və unutmayın ki, Table = off istifadə edən menecer bu siyahıdan heç bir marşrut götürmür. Bu halda həmin prefiksi sistemin marşrut cədvəlinə onun sahibi olan komponent quraşdırmalıdır və orada çatışmayan marşrut tam olaraq çatışmayan icazəli prefiks kimi görünür.

Mənbə sahibliyini şlüzdə saxlayın

Şlüzün bu müştəri üçün peer qeydi məhz həmin müştərinin mənbə ünvanına sahib olmağa davam etməlidir. İcazəli ünvanlar hər iki istiqamətdə yoxlanılır: çıxan trafik üçün peer seçir və gələn paketin mənbəyinin onu göndərən peer-ə aid olduğunu təsdiqləyir. OpenVPN hovuzunu budağın qeydinə yerləşdirmək, çünki budaq ona çatmaq istəyir, trafiki səhv iştirakçıya yönəldən səhvdir.

AllowedIPs = 10.71.0.5/32

Bu qeydi marşrut rahatlığı deyil, sahiblik bəyanı kimi oxuyun. Müştərinin çatmalı olduğu hər şey müştərinin hədəf siyahısına aiddir, şlüzün bu peer-in nə göndərə biləcəyi barədə təsəvvürünə deyil.

OpenVPN tərəfinə qayıdış marşrutu verin

Hədəfin artıq WireGuard mənbəyinə qayıdan marşruta ehtiyacı var və hovuz müştəriləri üçün bu adətən OpenVPN serverindən itələnən marşrut kimi gəlir. Onu yalnız malik olmalı müştərilərə itələyin və direktivin tətbiq olunduğunu güman etmək əvəzinə müştəridə qəbul edildiyini təsdiqləyin.

push "route 10.71.0.0 255.255.255.0"

Marşrut paylanması avtorizasiya deyil. Hədəf hovuzda deyil, başqa bir OpenVPN müştərisinin arxasında olduqda, həmin müştərinin öz LAN sahibliyi və yönləndirmə tələbləri dizayna qoşulur, və itələnən marşrut yalnız birinci yarıdır. Direktivlər əlavə etməzdən əvvəl tələbi qraf kimi yenidən ifadə edin: hansı düyün hansı prefiksə sahibdir və hansı düyün ona doğru yönləndirir.

İcazə vermək istədiyiniz tək xidmətə icazə verin

Yönləndirmə aktiv və hər iki hovuz marşrutlaşdırıla bilən olduqda qalan sual siyasətdir. Qaydanı ümumilikdə interfeys cütü üçün deyil, konkret axın üçün yazın, tətbiqdən əvvəl önizləyin və cavabların yeni bağlantı kimi bloklanmaması üçün vəziyyət saxlayan qayıdış yolunu qoruyun. Sınaq işə salma heç bir şeyə başa gəlmir və dəqiq nəyin əlavə olunacağını göstərir.

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

Bunlar yönləndirilən qaydalardır və şlüzün iki VPN xidməti üçün dinləmə qaydalarından fərqlidir. Xarici UDP portlarını açmaq daxili sorğuya icazə vermir və daxili sorğuya icazə vermək şlüzə məhdudiyyətsiz SSH və ya yönləndirmədə defolt icazə tələb etmir. Hədəfin öz firewall-u və dinləmə ünvanı da uyğun olmalıdır, çünki loopback-ə bağlanmış xidmət ən diqqətlə marşrutlaşdırılmış paketi belə rədd edir. Söhbətin yalnız bir istiqamətini əhatə edən siyasət adətən uğurlu sorğu və səssiz cavabla uğursuz olur ki, bu da üç nəticənin ən çaşdırıcısıdır.

Qarşılıqlı marşrutlar adətən mənbə tərcüməsinə ehtiyac olmadığını bildirir, bu da WireGuard ünvanını hədəfdə qoruyur və jurnalları oxunaqlı edir. İki protokol iştirak etdiyi üçün ümumi masquerading əlavə etməyin və mövcud tərcümə qaydasını nədən asılı olduğunu bilmədən silməyin. Sonra tək axını başdan-başa yoxlayın və bir icazəsiz mənbə və ya portu da sınayın: hər tərəfdə işləyən əl sıxışma nə çarpaz marşrutu, nə də izolyasiyanı sübut edir.