fwmark ilə bir Linux hostunda iki OpenVPN klientini zəncirləmək

Bir Linux hostunda ikinci OpenVPN klientini üst-üstə qoymaq iki yerdən birində uğursuz olur. Ya daxili klient öz serverinə çata bilmir, çünki xarici tunel həmin nəqli tutub, ya da ikinci klient marşrut cədvəlini yenidən yazır və birinci tunel işləməyi dayandırır. Hər iki problem şifrələmədə deyil, marşrutlaşdırmadadır və yeni tunel hər hansı tətbiq trafikini daşımazdan əvvəl həll olunur. Buradakı ünvanlar nümunəvidir: tun0 xarici tunel, 203.0.113.9 daxili server, TCP 9999 isə daxili yoldan keçməli olan axındır.

İki uğursuzluq rejimi, bir marşrut cədvəli

Daxili klient öz serverinə UDP soketi açır və bu soket hər hansı digəri kimi cari marşrut cədvəlinə uyğun gedir. Əgər xarici tunel artıq standart marşruta sahibdirsə, əl sıxma paketləri xarici tunelə düşür. Bu yalnız xarici server daxili serverə çata bildikdə və qarşı tərəf axını daşımağa razılaşdıqda işləyir; əks halda əl sıxma dayanır və klient yenidən cəhd edir.

İkinci uğursuzluq serverin push əmrindən gəlir. Adi push redirect-gateway def1-dir və standart marşrutu əvəz etmək yerinə 0.0.0.0/1 və 128.0.0.0/1 quraşdırır. Buna görə hər biri öz /1 cütünü quraşdıran iki klient toqquşur və ən yeni cüt demək olar ki, hər təyinat üçün qalib gəlir. İkinci tunel qoşulduqdan sonra bir tunel ölürsə, cədvəldə bu iki prefiksi axtarın, çünki standart marşrutun özü heç vaxt dəyişməmiş ola bilər.

Axını işarələyin və ona cədvəl verin

Seçilmiş trafiki mangle cədvəlində işarələyərək və həmin işarəni siyasət qaydasında uyğunlaşdıraraq yönləndirin. Qayda standart marşrutu daxili qurğu olan xüsusi cədvələ işarə edir, buna görə daxili yoldan yalnız işarələnmiş paketlər keçir.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Bu qayda dəstindəki uğursuzluqların çoxu iki səhvdən qaynaqlanır. Firewall-un qoyduğu işarə dəyəri ilə qaydanın uyğunlaşdırdığı dəyər eyni olmalıdır, çünki uyğunsuzluq nə xəta, nə də təsir yaradır. PREROUTING isə yalnız xaricdən gələn paketləri görür, buna görə bu hostda başlayan bağlantının işarələnməsi üçün əvvəlcə eyni uyğunlaşdırmaya malik OUTPUT qaydası lazımdır.

Marşrut sahibliyini ikinci klientdən alın

İkinci klientin cədvəli redaktə etməsinin qarşısını iki seçim alır və onlar müxtəlif nöqtələrdə işləyir. route-nopull push edilən marşrut seçimlərini nəzərə almır, buna görə heç nə quraşdırılmır. route-noexec push edilən seçimləri klientin mühitinə qəbul edir, lakin cədvəl dəyişikliyini qarmağa buraxır; serverin nə təklif etdiyini görmək lazım olduqda istədiyiniz də məhz budur.

Qarmaq push edilən dəyərlərlə öz mühitində işləyir və yalnız təsdiqlədiyiniz qeydləri əlavə etməlidir. Onu idempotent edin: yenidən qurmadan əvvəl sahib olduğu cədvəli təmizləyin və əvvəlki işin təmiz vəziyyət qoyduğunu güman etməyin. Yenidən qoşulma qarmağı yenidən çağırır və təmizləmədən əlavə edən qarmaq dublikat marşrutlar yığacaq.

Bir sahib seçin və onu yazın. Hər iki seçimi quran profil və ya əl ilə skriptlə rəqabət aparan qarmaq, sonradan heç kimin izah edə bilməyəcəyi cədvəl yaradır.

Hər iki server ünvanını bərkidin

Daxili serverin daxili klient qoşulmazdan əvvəl xarici qurğudan keçən host marşrutuna ehtiyacı var. Daxili nəqli standart marşruta uyması əvəzinə xarici tunelin içində saxlayan qeyd elə budur.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Xarici server üçün də əsas cədvəldə uyğun host marşrutu əlavə edin, əks halda yenidən qoşulma xarici klientin öz nəqlini öz tunelinə yönləndirə bilər. Sıra məcburidir: bu qeydləri müvafiq interfeys mövcud olduqdan sonra əlavə edin, yəni qoşulmadan sonra işləyən qarmaq və ya skriptlə. Söndürülmüş qurğuya işarə edən marşrut silinir və ya nəzərə alınmır, buna görə yükləmə zamanı yazılan qeyd gözlədiyiniz ardıcıllıqdan sağ çıxmır.

Bütün cədvəli oxumaq yerinə axtarışı yoxlayın. Marşrut axtarışının çıxışı nüvənin istifadə edəcəyi qurğunu və mənbə ünvanını göstərir ki, bu da klientin soketini açanda aldığı şeyin eynisidir.

Zənciri sınaqdan keçirin və uğursuzluğu görünən edin

Daxili klient qoşularkən xarici interfeysdə tutun. Daxili əl sıxma xarici tunelin içində şifrələnmiş yük kimi görünməlidir; əgər 203.0.113.9-a adi UDP kimi görünürsə, host marşrutu yoxdur və zəncir heç qurulmayıb.

Səssizcə fiziki yuxarı bağlantıya qayıdan zəncir ən pis nəticədir, çünki interfeys vəziyyəti heç nə bildirmir və daxili trafik səhv mənbə ünvanından çıxır. Xarici tunel düşəndə ikinci klient birbaşa yenidən qoşula bilirsə, həmin yolu söndürün və ya xarici interfeysə bağlayın ki, uğursuzluq görünsün.

İki axın və bir qayda çıxarışı ilə bitirin: işarələnmiş bağlantı ilə işarələnməmiş biri fərqli yollardan getməlidir və ip rule show nəzərdə tutduğunuz prioriteti göstərməlidir. Əgər hər iki axın eyni yoldan gedirsə, işarə gözlədiyiniz yerdə tətbiq olunmur.