Bir kiçik lövhədə iki tunel ünvanı səhv kimi görünür və refleks onlardan birini silməkdir. Bu refleks nizama salmaq üçün nəzərdə tutulan şeyi pozur. İki atlamanı daşıyan host hər qoşulma üçün bir ünvan saxlayır və hər ünvan fərqli marşrutla seçilir. Sual verməyə dəyər olan budur: hansı marşrut hansı daşıyıcını hansı təyinat üçün seçir, nə qədər ünvan olduğu deyil.

Fərqli daşıyıcı tələb edən üç təyinat

İki atlamalı zəncir üst-üstə yığılmış üç təyinat sinfidir və hər birini fərqli qoşulma daşıyır. Xarici peer-ə fiziki link üzərindən çatmaq lazımdır. Daxili peer-ə xarici tunel vasitəsilə çatmaq lazımdır. Əhatə olunan tətbiqin təyinatına isə daxili tunel vasitəsilə çatmaq lazımdır, onun öz nəqliyyatını xarici tunel daşıyır.

Destination classView that names the carrierCommand that proves itSymptom when the wrong carrier wins
Outer peer, 198.51.100.10the main table, by destinationip route get 198.51.100.10the outer handshake never completes
Inner peer, 203.0.113.7the main table once the outer tunnel is upip route get 203.0.113.7the inner handshake leaves over the physical link
Application destination, 172.30.9.1the table the inner client's traffic is selected intoip route get 172.30.9.1 from 10.8.0.2the exit address looks right and the traffic never crossed the outer hop
Parallel tunnels, one per source groupone policy per group, not the main tableip rule show beside a marked test connectionboth tunnels are up and one steals the other's traffic

Cədvəl konkret hala gəlməmişdən faydalı olmadığı üçün marşruta toxunmazdan əvvəl sətirləri oxucunun real ünvanları ilə doldurun. İşləyən zəncir dörd sətri eyni vaxtda ödəyir, yarım işləyən zəncir isə adətən onlardan birini səhv daşıyıcı ilə ödəyir. Səhv sətri nasazlıq kimi oxumaq, marşrutlaşdırma problemini bütün bir axşam redaktəsinə çevirən şeydir.

Ünvanların sayı deyil, rolu var

Linux bir interfeysdə bir neçə ünvana və bir hostda bir neçə tunelə icazə verir, ona görə say düzgünlük barədə heç nə demir. Vacib olan hansı ünvanın hansı qoşulmaya aid olduğu və müəyyən peer üçün marşrutun nəzərdə tutduğunuz qoşulmanı seçib-seçmədiyidir. Üç görünüş buna üç istiqamətdən cavab verir və onları hər dəfə eyni qaydada oxumağa dəyər.

Ünvan inventarı nəyin mövcud olduğunu və hansı qoşulmanın ona sahib olduğunu göstərir. Marşrut cədvəli adi təyinat trafiki üçün daşıyıcı sualına cavab verir. Siyasət görünüşü isə mənbə və ya işarə ilə seçilən trafik üçün yenə cavab verir, iki müştəri bir hostu paylaşdıqda bu normal quruluşdur.

ip -4 addr show
ip -4 route show table all
ip rule show

Siyahı uzun göründüyü üçün ünvanı silmək yolun bir hissəsini çıxara bilər və lazımsız göründüyü üçün marşrutu silmək eyni şeyi daha səssiz edir. Heç biri xəta yaratmır; peer sadəcə nəzərdə tutduğunuz yolda cavab verməyi dayandırır, başqa yol ilə əlçatan qalır. Daxili peer-in çıxış ünvanını bildirən tətbiq trafikin xarici tuneldən keçdiyini sübut etmir, çünki birbaşa giriş eyni müşahidəni yaradır. Müşahidə ilə sübut arasındakı bu boşluq daşıyıcının marşrutlaşdırma qatında yoxlanmasının səbəbidir.

Aktivləşmə sırası sabit yuxudan üstündür

Daxili müştəri xarici müştərinin təqdim etdiyi ünvandan və ya marşrutdan asılıdırsa, aktivləşmə gecikməyə deyil, həmin resursa gözləməlidir. Yuxu xarici tunelin yavaş olduğu günə qədər işləyir və sonra heç kimin təkrarlaya bilmədiyi şəkildə fasilələrlə uğursuz olur. Asılılığa əsaslanan sıralama təxmini aradan qaldırır və asılılığı bir dəfə təsvir etməkdən başqa heç nəyə başa gəlmir. İnterfeys adları da sıralama mexanizmi deyil.

Nüvə tun0 və tun1 kimi adları yaradılma sırası ilə verir və bu sıra yenidən başlatmalar və ya yenidən qoşulmalar arasında dəyişə bilər. Konfiqurasiyanı alətin təqdim etdiyi kimliyə və ya qəsdən təyin etdiyiniz ada bağlayın. Sizin seçdiyiniz ad müqavilədir; nüvənin seçdiyi ad təsadüfdür.

Hər müştərinin nəqliyyatını digərinin tətbiq marşrutundan kənarda saxlayın və OpenVPN 2.6 marşrutlaşdırma seçimlərinin həqiqətən nə vəd etdiyi barədə dəqiq olun. Sənədləşdirilmiş standart yönləndirmə mexanizmi müştərinin öz uzaq peer-inə artıq mövcud olan şlüz vasitəsilə çatma qabiliyyətini saxlayır və bu, bir konkret rekursiya dövrəsini kəsir. O, bir müştərini digər müştərinin daşıyıcısına çevirmir, ona görə zəncirin qalan hissəsi sizin dizaynınız olaraq qalır. Zəncir marşrut yerinə siyasət tələb etdiyi yerlərdə açıq mənbə və ya işarə qaydası yazın və onu uyğunlaşmalı olduğu trafiklə sınayın.

Xarici atlama öləndə nə olur

Zəncir tam sayılmazdan əvvəl xarici atlama yox olduqda nə olacağına qərar verin. Daxili müştərinin nəqliyyatı onunla birlikdə ölür və növbəti addım texniki deyil, siyasət sualıdır: uğursuzluq, yenidən cəhd və ya fiziki link üzərindən birbaşa qoşulma. Üçüncü nəticə düşünməyə dəyər olandır. İstifadəçi əhatənin hələ toxunulmaz olduğuna inandığı anda o, iki atlamalı dizaynı səssizcə bir atlamalı dizayna çevirir.

İki atlama məcburidirsə, xarici atlama yox olduqda daxili müştəri birbaşa yol qura bilməməlidir və bunu bilməyin yolu xarici atlamanı qırıb daxilin nə etdiyinə baxmaqdır. Təsdiqlənmiş ehtiyat variant qanuni cavabdır, lakin yazılmalı, sınanmalı və bildirilməlidir. Heç kimin sənədləşdirmədiyi ehtiyat variant insident araşdırması zamanı sızıntıdan fərqlənmir.

DNS və digər ünvan ailəsi eyni qərara aiddir. Lokal olaraq yaradılan sorğu yönləndirilmiş müştərinin deyil, hostun öz siyasətinə əməl edir, ona görə yönləndirilmiş trafik üçün işləyən həlledici hostun özünün istifadə etdiyi olmaya bilər.

Hər qatı qurduğunuz sıra ilə qəbul edin

Zəncirin qurulduğu sıra ilə sınayın: əvvəlcə yalnız xarici tunel, sonra xarici tuneldən daxili müştərinin nəqliyyatı, sonra daxili tuneldən tətbiq. Hər qəbul əvvəlcədən açıq qalmış səhifə deyil, yeni bağlantı olmalıdır. Sonra hər qatı ayrıca qırın və bərpa edin və növbətinin nə etdiyinə baxın.

Ehtiyat variantın nəticəsi burada ən dəyərli müşahidədir və ictimai IP səhifəsinin heç vaxt göstərmədiyi bir şeydir. Peer yollarını, istifadə etdikləri ünvanları və həmin nəticəni konfiqurasiyanın yanında saxlayın, çünki xoşbəxt yol sonradan sorğulanan hissə deyil.

Əlaqəli məqalələr