OpenVPN UDP cavabı niyə yanlış ünvandan çıxır

OpenVPN müştərisi bir ünvana qoşulur, server başqa ünvandan cavab verir və tunel heç vaxt qalxmır. Server jurnalı paketin gəldiyini, paket tutumu isə cavabın çıxdığını göstərir, ona görə də nasazlıq müştərinin üzərinə atılır. Bir neçə interfeysi olan və ya bir interfeysdə bir neçə ünvanı olan hostda tərəflər sadəcə hansı ünvanın istifadə olunduğu barədə razılaşmır. Cavab IP qatında düzgündür, lakin bir çox müştəri mənbəyi əlaqə saxladıqları ünvan olmayan datagramı rədd edir.

Mənbə dəyişdikdə müştəri nə görür

Müəyyən yerli ünvana bağlanmayan UDP soketinin sabit mənbəyi yoxdur, ona görə də nüvə göndərmə anında onu özü seçir. Bu seçim müştərinin ünvanına doğru marşrut axtarışından gəlir və mənbə axtarışın seçdiyi interfeysin ünvanı olur. Bir interfeysli maşında seçim görünməzdir; idarəetmə ünvanı, ictimai ünvan və eyni şəbəkə kartında ikinci dərəcəli ünvanı olan hostda isə hər şey marşrut metrikalarından və siyasətindən asılıdır. Siyasət əsaslı marşrutlaşdırma uyğunsuzluğu azaltmaq əvəzinə daha ehtimallı edir, çünki qayda müştərinin heç vaxt çatmadığı bir yuxarı kanalı seçə bilər. Bir provayderdən öyrənilmiş standart marşrutla başqa birinə işarə edən mənbə qaydası bunu yaratmaq üçün kifayətdir.

Cavabları filtrləyən müştərilər və dəqiq dördlüyü və mənbəni gözləyən bağlantı izləmə cavabı faydalı mesaj olmadan atacaq. Sonra tunel sanki heç nə gəlməmiş kimi vaxt aşımına uğrayır və buna görə də bu, müştəri tərəfindəki firewall problemi ilə səhv salınır. Yalnız serverdə götürülmüş tutum səhvi izah etmək əvəzinə təsdiqləyir, çünki cavab həqiqətən çıxır. Başqa heç nəyi dəyişməzdən əvvəl cavabın mənbəyini müştərinin zəng etdiyi ünvanla müqayisə edin.

multihome seçimi əslində nə edir

Direktiva konfiqurasiya faylında multihome, əmr sətrində isə --multihome kimi yazılır və UDP serverini müştərinin paketinin çatdığı ünvandan cavab verməyə məcbur edir. Nüvə qəbul zamanı orijinal təyinat ünvanını əlavə məlumat kimi ötürür və OpenVPN bu dəyəri cavabın mənbəyi kimi istifadə edir. Beləliklə, ümumi ünvanda, yəni IPv4 üçün local 0.0.0.0 və ya onun IPv6 ekvivalentində dinləyən server hər müştərinin ayrıca dinləyiciyə çatdığı kimi davranır. İctimai ünvandan gələn müştərilər ictimai ünvandan, daxili ünvanda olan müştərilər isə həmin ünvandan cavab alır. Paket yolunda başqa heç nə tərpənmir: marşrut, filtr qaydaları və tunel konfiqurasiyası olduğu kimi qalır.

Bu son xüsusiyyət seçimin artıq işləyən serverə əlavə edilməsinin təhlükəsiz olmasının səbəbidir və həm də yalnız bir ünvana icazə verən filtri bərpa edə bilməməsinin səbəbidir. Paket yenə də keçdiyi yolda qəbul edilməlidir, ona görə də mənbə düzəlişi cavabın mənşəyini dəyişir və başqa heç nəyi yox. Bu həm də yalnız UDP üçündür: TCP dinləyicisi bu problemi eyni formada yaşamır, çünki bağlantı cavabın mənbə ünvanı ilə deyil, dördlüklə müəyyən edilir.

Sabit yerli ünvan nə vaxt yanlış standartdır

Seçimə əl atmaqdan əvvəl serverin bir konkret yerli ünvanı bağlayıb-bağlamadığını yoxlayın, çünki bağlanmış dinləyici həmişə həmin ünvandan cavab verir. Bu, bir interfeysli yerləşdirmə üçün düzgündür və müştərilər qanuni olaraq birdən çox ünvan istifadə etdiyi anda yanlış olur. Əgər bağlama qəsdən edilibsə, serverin ümumiyyətlə əlavə ünvanlarda trafiki qəbul edib-etməməsini qərarlaşdırın. Bağlamanın silinməsi məruz qalmanı artırır, ona görə də icazə verilən interfeysləri və mənbə şəbəkələrini yalnız bağlama ünvanı deyil, xidmət və filtr tətbiq etməlidir.

OpenVPN arayışı seçimi UDP serverləri ilə məhdudlaşdırır, paket yolundakı əlavə emalı qeyd edir və onu hansı platformaların dəstəklədiyini göstərir. Planlaşdırmadan əvvəl bunu quraşdırılmış buraxılışda təsdiqləyin. Dəstəklənmədiyi yerlərdə konkret ünvanı bağlamaq və ya qayıdış marşrutunu düzəltmək alternativdir və ikisi də ilk baxışdan göründüyündən daha dar dəyişikliklərdir. Ümumi dinləmənin cavablardan kənar nəticələri də var: bütün ünvanlarda işləyən server hostun qoşulduğu hər şəbəkədən əlçatandır və bu, heç kimin nəzərdə tutmadığı məruz qalma ola bilər.

Cavabın mənbəyini kənardan sübut edin

Serverdən kənarda sınaqdan keçirin və heç nə tutmazdan əvvəl müştərinin istifadə etdiyi dəqiq ünvanı və nəqliyyatı qeyd edin. Aşağıdakı üç yoxlama üç fərqli suala cavab verir və ardıcıllıq vacibdir.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Tutum cavabdakı mənbə ünvanını göstərir və bütün məqalə məhz bu fakta əsaslanır. Soket siyahısı serverin əslində nəyi bağladığını göstərir, çünki ümumi dinləyici ilə konkret dinləyici konfiqurasiya faylında eyni görünür və şəbəkədə fərqli davranır. Marşrut axtarışı nüvənin həmin axın üçün seçəcəyi mənbəni göstərir və bu, heç nəyi dəyişməzdən əvvəl tutumu izah edir. Üçünü də IPv4 və IPv6 üçün ayrıca təkrarlayın, çünki onlar ayrı dinləyicilər və ayrı axtarışlardır və bir ailə üçün ümumi qeyd digəri haqqında heç nə demir.

Marşrutlaşdırma, aşkarlama və filtrləmə ayrı qalır

Cavabın mənbəyini qorumaq gedən marşrut quraşdırmır, dinamik DNS-i yeniləmir və bir ünvan ailəsini digərini qəbul etməyə məcbur etmir. Bir neçə yuxarı kanalı olan serverdə hər mənbə üçün qayıdış yolu qəsdən razılaşdırılmalıdır, əks halda cavablar müştərinin filtri heç vaxt icazə vermədiyi interfeysdən çıxır. Eyni şəkildə, prefiks dəyişdikdən sonra yeni ünvan köhnə qeyd vasitəsilə deyil, aşkarlama və dəstəklənən yenidən qoşulma axını vasitəsilə müştərilərə çatmalıdır.

Server kimliyi yoxlamalarını və sertifikat doğrulamasını olduğu kimi buraxın, çünki dəyişmiş ünvan təsdiqlənməmiş həmyaşıdın qəbulunu əsaslandırmır. Cavab indi nəzərdə tutulan mənbədən çıxır və tunel yenə də uğursuz olursa, mənbə problemini həll olunmuş sayın və davam edin. Müşahidə olunan növbəti xəta marşrutlaşdırmaya, filtrləməyə və ya autentifikasiyaya aiddir və dinləyicini yenidən dəyişmək ona çatmayacaq. Cavabın mənbəyini müştərinin zəng etdiyi ünvanın yanında biletdə yazın ki, növbəti şəxs eyni faktı bir əmrlə yoxlaya bilsin.