Yuxarı VPN arxasındakı aşağı axın müştəriləri: marşrut, yoxsa NAT?

Bir şlüz öz cihazlarınız üçün WireGuard, başqasının şəbəkəsinə isə OpenVPN müştərisi işlədir. İki daxili interfeys arasında yönləndirmə işləyir və belə nəticəyə gəlmək asandır ki, aşağı alt şəbəkə artıq yuxarı xidmətin bir hissəsidir. Belə deyil. Müştərinin çəkdiyi marşrut şlüzünüzə sorğuları hara göndərəcəyini deyir; uzaq şəbəkənin heç vaxt eşitmədiyi cihazlara trafiki necə qaytaracağı barədə isə heç nə demir. Tək bir qayda əlavə etməzdən əvvəl yuxarı xidmətin həqiqətən dəstəklədiyi qaytarma modelini seçin.

Marşruta toxunmadan əvvəl qaytarma modelini müəyyənləşdirin

Bu nümunədə aşağı müştərilər 10.90.0.0/24 istifadə edir, şlüzə verilən yuxarı tunel ünvanı 10.80.0.6-dır və təsdiqlənmiş uzaq resurs 172.20.0.30-dur. Bu formaya iki model uyğun gəlir: aşağı mənbəyi qoruyub uzaq tərəfin onu marşrutlaşdırmasını təmin etmək, ya da mənbəni şlüzün öz tunel ünvanına çevirmək. Bu qərardan sonrakı hər şey mexanikidir və qərarın özü xidmətin sahibini tələb edir. Yuxarıdakı sətirlərdən biri uzaq tərəflə marşrut razılaşmasıdır; digəri təkbaşına edə biləcəyiniz yerli siyasət dəyişikliyidir. İkisini qarışdırmaq on dəqiqəlik dəyişikliyi danışıqlara çevirir.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Bir sətir seçin və ona sadiq qalın. Sətirlər addımlar deyil, alternativlərdir və onları qarışdırmaq baxış zamanı heç kimin izah edə bilməyəcəyi bir dizayn yaradır.

Marşrutla mənbənin qorunması

Uzaq tərəf aşağı ünvandan sorğu alır, ona görə həmin alt şəbəkə üçün dəstəklənən marşrut və peer sahibliyi, üstəlik onu qəbul etmək üçün icazə lazımdır. Bunlar uzaq tənzimləmələrdir və heç bir yerli Linux marşrutu onları yaratmır. Onları açıq şəkildə, yazılı istəyin, prefiks və onu daşıyacaq tunel peer-i ilə birlikdə, və cavabın xidmətin saytlararası quruluşları ümumiyyətlə dəstəkləməsindən asılı olacağını gözləyin.

Cavab bəlidirsə, yerli konfiqurasiya kiçikdir: yönləndirmə aktiv, aşağı aralığı əhatə edən WireGuard peer allowed-ips-i və keçidi hər iki istiqamətdə icazə verən firewall siyasəti.

Qəsdən mənbə çevrilməsi

Xidmət trafiki yalnız qoşulmuş müştəri ünvanına qaytarırsa, çıxışda mənbəni həmin ünvana çevirin və cavablar üçün onu tərsinə çevirən conntrack vəziyyətini saxlayın. Qaydanı nəzərdə tutulan aşağı mənbələrə, nəzərdə tutulan uzaq təyinat nöqtələrinə və yuxarı interfeysə məhdudlaşdırın. Hər interfeysdən çıxan hər şeyi çevirən qayda bu tələbdən qat-qat böyük siyasətdir və sonra sizi təəccübləndirəcək.

IPv6 öz dizaynını tələb edir; IPv4 masquerade sətrini kopyalamaq memarlıq deyil. Çevrilmiş yolu keşlənmiş deyil, təzə bağlantı ilə sınayın.

Yerli məlumat yolu hələ də işləməlidir

Çevrilmə yerli işi aradan qaldırmır: şlüz hələ də aşağı təyinatlar üçün marşruta, düzgün WireGuard peer mənbə sahibliyinə, aktiv yönləndirməyə və interfeyslər arası dar firewall siyasətinə ehtiyac duyur. Şlüzün özündə yaranan sorğu bu icazələrin heç birini sınaqdan keçirmir, buna görə şlüz daxilindəki testlər keçir, aşağı cihazlar isə yenə də uğursuz olur.

Şlüzdən deyil, real aşağı cihazdan sınayın. Mənbə ünvanı bu məşqin bütün mahiyyətidir.

Bir mənbə bir sessiya kimliyi deməkdir

Uzaq xidmət hər aşağı cihaz üçün ayrıca autentifikasiya deyil, şlüzün autentifikasiya olunmuş sessiyasını və çevrilmiş ünvanını görür. Cihaz başına icazələri və tətbiq kimliklərini açıq saxlayın və xidmətin sahibindən bir neçə cihaz adından çıxış edən şlüzün ümumiyyətlə icazəli olduğunu təsdiqləyin. Çevrilmə cihaz başına qeydiyyat tələbini yan keçmək üsulu deyil; xidmət hər cihazın qeydiyyatını tələb edirsə, həmin modeli istifadə edin və ya saytlararası quruluş barədə danışıqlar aparın.

Bu təsdiqi qaydanın yanında runbook-a yazın, çünki növbəti rəyçi dizaynın təsdiqləndiyini, yoxsa sadəcə rahat olduğunu soruşacaq.

Əlaqənin kəsildiyi vəziyyəti müəyyənləşdirin, sonra üç sorğu sınayın

Yuxarı tunel düşəndə nə olacağına qərar verin. İcazəli uzaq trafik qadağan olunduğu yerdə adi WAN ehtiyat yolunu səssizcə izləməməlidir, ona görə keçidi icazə verən firewall siyasəti də bağlı vəziyyətdə uğursuz olmalıdır. Sonra real aşağı cihazdan üç halı sınayın: işləyən icazəli sorğu, uğursuz olan icazəsiz sorğu və icazəli sorğunu dayandıran yuxarı nasazlıq.

Geri qaytarmanı hər qayda üçün bir sətirdə qeyd edin ki, dəyişiklik niyyəti yenidən qurmadan ləğv edilə bilsin.