OpenVPN redirect-gateway: hər bayraq marşrutlara nə edir

Profilə redirect-gateway əlavə edib qoşulun və maşınınızın standart marşrutu yox ola, iki yerə bölünə və ya tam olduğu yerdə qala bilər — bu, heç kimin iki dəfə oxumadığı bayraqlardan asılıdır. Seçim yalnız marşrutlaşdırma vəziyyətini dəyişir, başqa heç nəyi yox, ona görə də onun nə etdiyinin yeganə etibarlı sübutu müştərinin sonradan quraşdırdığı cədvəldir. Bundan sonra gələn, qoşulmadan sonrakı cədvəl, tunelin özünü canlı saxlayan marşrut və direktivanın heç vaxt əhatə etdiyini iddia etmədiyi IPv6 trafikidir. Hər addım tunel açıqkən müştəridə işlədə biləcəyiniz bir əmrdir.

Hər bayraq standart marşruta nə edir

Heç bir bayraq olmadan seçim adi standart marşrutu silir və tuneli onun yerinə qoyur, beləliklə köhnə şlüz qoşulma açıqkən cədvəldən yox olur. def1 əlavə edin və həmin standart siyahıda qalır, işi yerinə yetirən iki daha dar marşrut olur. bypass-dhcp əlavə edin və DHCP marşrutu da yaşayır, bu, müştərinin hələ də yerli DHCP serverinə çatmalı olduğu şəbəkədə vacibdir. OpenVPN 2.6 təlimat səhifəsindəki bayraq siyahısı bir dəfə oxumaq üçün kifayət qədər qısadır və hər bənd cədvəldə hansı marşrutların qalacağını dəyişir.

İtilənmiş seçim gəldikdən sonra eyni şəkildə davranır, ona görə də müştəri profilində heç nə olmaya bilər, halbuki cədvəl tam yönləndirilmiş görünür. Bu normaldır: server bayraqları göndərdi, müştəri onları tətbiq etdi və yerli fayl direktivanı heç xatırlatmadı. İtmə heç nə etmirmiş kimi görünəndə çəkilmiş seçimləri qəbul edən və ya atan müştəri tərəfi filtrini yoxlayın, çünki atılmış seçim iki tərəfin heç birində xəta yaratmır.

def1 standartınıza toxunmadan dəqiqliyə görə qalib gəlir

İki yarım-standart marşrut birlikdə IPv4 fəzasını əhatə edir, 0.0.0.0/1 və 128.0.0.0/1. Hər biri 0.0.0.0/0-dan daha dəqiqdir, ona görə axtarış onlara üstünlük verir, real standart isə ən az dəqiq uyğunluq istəyən hər şey üçün cədvəldə qalır.

Profili deyil, cədvəli oxuyun, çünki bu hallardan hansında olduğunuzu yalnız cədvəl göstərir. Onları ayırmaq üçün iki sətir kifayətdir:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Hər sətirdə yalnız təyinatı deyil, interfeysi və metrikanı da qeyd edin. Tunelə baxan standart və tunelə baxan yarım-standart cütü eyni niyyəti təsvir edir və tunel düşəndə fərqli şəkildə uğursuz olur, çünki bir halda ehtiyat variant hələ də mövcuddur. Hər iki sahəni dəyişiklik qeydinə yazın. Qalan ehtiyat variant bəzən uzaq sessiyanı tuneli təmir etmək üçün kifayət qədər uzun saxlayan şeydir və niyyət tam tunel olanda trafiki sızdıran da elə odur.

Tunelin son nöqtəsini əlçatan saxlayın

Müştəriyə tunelin uzaq ucuna, özü tuneldən keçməyən bir marşrut lazımdır. OpenVPN həmin host marşrutunu başqa heç nəyi dəyişməzdən əvvəl quraşdırır və əl ilə marşrut redaktəsi və ya ikinci VPN müştərisi onu apara bilər. Sonrakı simptom qoşulduğunu bildirən, sonra heç nə ötürməyən bir əlaqədir.

Tunel açıqkən kerneldən son nöqtə ünvanı üçün hansı interfeysi istifadə edəcəyini soruşun. Cavab fiziki interfeysi və onun şlüzünü adlandırmalıdır, heç vaxt tun0 yox:

ip route get 198.51.100.20

Əgər bu axtarış tunel cihazını qaytarırsa, tunel öz nəqliyyatını daşıyır və hər hansı paketin çıxması lazım olan kimi dağılacaq. Yerli prefikslər, ikinci adapter və siyasət əsaslı marşrutlaşdırma burada hələ də vacibdir, buna görə təmiz noutbukda işləyən yönləndirmə idarəetmə interfeysi və iki standartı olan hostda uğursuz ola bilər. Adətən profili günahlandırırlar, halbuki bunu ünvan planı edib.

IPv6 trafiki öz cədvəlini işlətməyə davam edir

IPv4-ü yönləndirmək IPv6-ya toxunmur və iki ailə fərqli bayraqlarla dəyişdirilir. İşləyən v6 standartı olan iki yığınlı hostda v4 trafiki tam tunelin içində qala bilər, halbuki v6 qabiliyyətli hər təyinat fiziki kanaldan çıxır. Bir cədvəldə düzgün görünən host digərində sızır.

Qoşulduqdan sonra tunelin onu əhatə etdiyini güman etmək əvəzinə v6 cədvəlini yoxlayın. Direktiva ünvan ailəsi bayraqlarını məhz bu səbəbdən daşıyır və onları buraxan profil platformanın standart olaraq etdiyini miras alır:

ip -6 route show default
ip -6 route get 2001:db8::10

Tətbiqin hansı interfeysi işlətdiyini sübut edin

Qoşulmuş vəziyyət blok deyil, marşrut dəyişikliyi də qəti dayandırma açarı deyil. Əgər tunel uğursuz olanda birbaşa trafik dayanmalıdırsa, bu siyasət güvəndəlik divarında yaşayır və öz testini tələb edir.

Profilin təsvir etdiyi yolu deyil, tətbiqin həqiqətən getdiyi yolu sınayın. Əvvəlcə marşrutu soruşun, sonra sorğunu növbə ilə hər interfeysə bağlayın və qarşı tərəfin bildirdiyini müqayisə edin:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Əgər iki sorğu eyni ünvanı qaytarırsa, marşrut cədvəli belə deməsinə baxmayaraq tətbiq tuneldən istifadə etmir. Əgər yalnız tunelə bağlı sorğu uğurlu olursa, fiziki yol həmin təyinat üçün filtrlənib və tunel sizin istədiyinizi edir. Bayraqları, quraşdırılmış marşrutları, son nöqtə axtarışını və iki çıxış nəticəsini dəyişiklik qeydinə yazın ki, növbəti adam ekran şəkli deyil, faktlar miras alsın.