Bir Linux hostunda iki OpenVPN tuneli: marşruta kim sahibdir?

İki profil qoşulub və onlardan biri səssizcə digəri üçün nəzərdə tutulmuş trafiki daşıyır. Bir Linux hostu hər iki OpenVPN müştərisini eyni vaxtda çətinlik çəkmədən işlədə bilər. Edə bilmədiyi şey hansı prosesin hansı prefiksi iddia edə biləcəyini sizin əvəzinizə qərar verməkdir. Bu qərar ikinci tunel qalxmazdan əvvəl verilməlidir, hansısa resurs cavab verməyi dayandırdıqdan sonra deyil.

İkinci keçidin görməli olduğu işdən başlayın

Bir profillə əlçatan ofis və digəri ilə əlçatan laboratoriya hər iki tunelin işləməsini və heç birinin hər şeyi iddia etməməsini tələb edir. İkinci profildən çıxması mütləq olan bir inadkar tətbiq ikinci standart marşrut deyil, siyasət qaydası tələb edir. Ehtiyat keçid eyni vaxtda yalnız bir tunelin işləməsini tələb edir, ona görə ehtiyat maşınla birlikdə başlamamalıdır.

Bunlar üç fərqli konfiqurasiyadır və onlar qarışdırılır, çünki hər üçü eyni cür başlayır: ikinci profil və uğurlu bağlantı. Əvvəlcə nəzərdə tutulan düzülüşü yazın, sonra ona doğru konfiqurasiya edin. Bir cümlə niyyət bir saatlıq paket tutmağa qənaət edir.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Birinci əmr işləyən nüsxələri sadalayır, o cümlədən menecerdən kənarda əl ilə başladılanları. İkincisi cari standart iddianı çap edir, bu da sonradan izah etməli olacağınız vəziyyətdir.

Üst-üstə düşən hovuzlar marşrutlaşdırmadan əvvəl pozulur

İki server eyni 10.8.0.0/24-dən rahatca ünvan paylayacaq. Sonra müştəri bir prefiks daxilində iki interfeys saxlayır və hansı təyinatın hansına aid olduğunu deyən heç nə olmur, nəticədə yaranan davranış marşrutlaşdırma xətası kimi görünür, amma əslində nömrələmə xətasıdır. Hovuzun nömrələnməsini dəyişmək bir konfiqurasiya redaktəsinə başa gəlir; sonrakı hər marşrut hiyləsi bir həftəsonuna başa gəlir. Ona marşrut əlavə etməzdən əvvəl hovuzu yoxlayın.

Yerli LAN-a da baxın. Bir tunelin də açdığı 192.168.1.0/24 nömrəli ev LAN-ı eyni qeyri-müəyyənliyi yaradır və simptom bağlantı heç vaxt tamamlanmadan həll olunan host adıdır. Bu, marşrutları çap edənə qədər ad həlli xətası kimi görünür.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Müştəriyə toxunmazdan əvvəl hər iki çıxışı iki server konfiqurasiyası ilə müqayisə edin. Prefikslər üst-üstə düşürsə, dayanın və yenidən nömrələyin, çünki nə qədər yenidən başlatma olsa da onları ayırmayacaq.

Hər profilə öz bölməsini, hər prefiksə sahibini verin

Hər profil öz nüsxə adını və öz konfiqurasiya faylını alır, beləliklə office adlı nüsxə office.conf, lab adlı nüsxə isə lab.conf yükləyir. Bu uyğunluğu qovluq siyahısına güvənmək əvəzinə xidmət meneceri vasitəsilə təsdiqləyin, çünki drop-in hansı faylın yükləndiyini dəyişə bilər. Uyğunluğu səhv salmaq işləməyən profili tənzimlədiyiniz deməkdir.

Sonra marşrutları kimin quraşdırdığını həll edin. Serverlər uyğunsuz dəstlər ötürdükdə, ya ötürməni rədd edin və prefiksləri özünüz sadalayın, ya bir profilin standartı saxlamasına icazə verin və digərini siyasət qaydaları ilə yönləndirin. Hər ikisi standart quraşdıran iki proses səssiz qalib və qərarın yazılı qeydi olmadan bitir.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Birincisi bölməni arqumentlərini dəyişən hər hansı əvəzləmə ilə göstərir. İkincisi profilin ötürülən marşrutları ümumiyyətlə qəbul edib-etmədiyini göstərir, bu da sonrakı hər şeyi təyin edən açar.

İşarələr cavabları gəldikləri interfeysdə saxlayır

Hər tunel fərqli mənbələrə xidmət etdikdə, cavab səhv keçidlə çıxa bilər və bağlantı ilk paketdən sonra ölür. Davamlı nümunə gələn paketləri giriş interfeysinə görə işarələmək, həmin işarəni cavabda bərpa etmək və hər işarəyə öz standart şlüzü olan cədvəl verməkdir.

Gevşək tərs yol filtrləməsi adətən təsirlənən interfeyslər üçün yumşaldılmalıdır, çünki cavab əsas cədvəlin heç vaxt seçməyəcəyi keçidlə qanuni şəkildə gəlir. İşarələri dar saxlayın ki, heç vaxt tunellərin öz şifrələnmiş trafikini tutmasınlar, çünki bu tuneli öz içindən göndərərdi.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Başqa bir qayda əlavə etməzdən əvvəl mövcud qaydaları oxuyun. Təkrarlanan prioritetlər və unudulmuş cədvəllər işarə siyasətinin heç bir təsiri yoxmuş kimi görünməsinin adi səbəbidir.

Bir keçidi dayandıraraq təcridi sübut edin

Hər iki tunel işləyərkən hər interfeys ünvanını, hər tunelin arxasındakı bir hosta marşrutu və əlaqəsiz təyinatın getdiyi yolu qeyd edin. Tək bir cədvəl oxumaq əvəzinə axtarışı kerneldən soruşun, çünki bir cədvəl heç vaxt son qərarı göstərmir.

Sonra bir nüsxəni dayandırın və digəri davam edərkən onun interfeysinin və marşrutlarının yox olduğunu izləyin. Sağ qalanda yaranan qırılma ikisinin hələ də heç kimin ayırmadığı cihaz adını, marşrutu və ya firewall qaydasını paylaşdığını göstərir.

Dayandırılmış profili geri qaytarın və eyni yoxlamaları təkrarlayın. Tunel yalnız yenidən başlatmadan sonra ilk işə salmada sağ qalırsa, siz marşrutlaşdırma dizaynına deyil, həyat dövrü qüsuruna baxırsınız.