OpenVPN itələdiyi marşrutlar quraşdırılmır: vaxt, hüquqlar və ya siyasət

Server marşrutu itələdiyini deyir, müştəri qoşulduğunu deyir, lakin təyinat hələ də əlçatan deyil. Üç səbəb məhz bu mənzərəni yaradır. Marşrutun əlavə edilməsi cihaz mövcud olmadan əvvəl işlədi, müştərinin cədvəli dəyişmək hüququ yox idi və ya siyasət müştəriyə itələnmiş seçimləri nəzərə almamağı əmr etdi.

Onlar xaricdən eyni görünür və fərqli düzəlişlər tələb edir. Marşrut qərarının verildiyi nöqtədə müştəri jurnalını oxuyun.

Marşrutun sadəcə pozulduğunu deyil, olmadığını sübut edin

Marşrutun pozulduğunu deyil, olmadığını sübut etməklə başlayın. Linux-da ip route show dev tun0 müştərinin tunel cihazında quraşdırdığını sadalayır. Windows-da route print və ya Get-NetRoute eyni şeyi cədvəl formasında göstərir.

Mövcud olan, lakin trafiki ötürməyən marşrut başqa problemdir. Bu, araşdırmanı marşrut quraşdırmasına deyil, ötürmə və firewall qaydalarına yönəldir.

Vaxt: əlavə etmə cihaz mövcud olmadan əvvəl işlədi

Müştəri serverin PUSH_REPLY cavabını idarə kanalı qurulduqdan və interfeysi konfiqurasiya etdikdən sonra təhlil edir. Yalnız bundan sonra platformanın təqdim etdiyi mexanizmlə marşrut cədvəlinə toxunur. Linux netlink vasitəsilə işləyir; Windows yüksəldilmiş token tələb edən API istifadə edir. Konfiqurasiyanı oxuyan kimi marşrutları əlavə edən skript və ya müştəri TUN/TAP cihazı mövcud olmadan əvvəl işləyə bilər və kernel əlavə etməni rədd edir.

Eyni yarış əllə yazılmış marşrutun işləməsini, avtomatik olanın isə işləməməsini izah edir: siz onu yazana qədər interfeys artıq qalxır.

route-delay bu hal üçün mövcuddur və route-up interfeys və marşrutlar konfiqurasiya edildikdən sonra işləyən skripti göstərir. Tunel ünvanından asılı olan marşrutları erkən mərhələdə deyil, həmin qarmağa qoyun.

Hüquqlar: cədvəli kim dəyişə bilər

Windows marşrut cədvəlini dəyişmək üçün yüksəldilmiş token tələb olunur. Standart istifadəçi tərəfindən başladılmış GUI adapter ünvanını xidmət vasitəsilə təyin edə və yenə də marşrut əlavə edə bilməyə bilər. Jurnal sonra itələmənin olmaması əvəzinə girişə icazə verilmədi tipli xəta göstərir.

GUI-ni administrator kimi başlatmaq və ya xidmət əsaslı müştəridən istifadə etmək bu nəticəni dəyişir. Tələb olunan token olmadan müştərini işə salan planlaşdırılmış tapşırıq isə dəyişmir.

Nəyisə dəyişməzdən əvvəl müştərinin əslində hansı hesabla işlədiyini yoxlayın. Versiya və xidmət rejimi hansı səbəblərin ümumiyyətlə mümkün olduğunu müəyyən edir, ona görə ikisini də marşrut çıxışının yanında qeyd edin.

Siyasət: itələnmiş marşrutlar qəsdən atıla bilər

route-nopull müştərinin serverin itələdiyi marşrutları, o cümlədən itələnmiş default marşrutu, nəzərə almamasına səbəb olur, tunel ünvanı isə yenə qəbul edilir. İtələnmiş DNS və DHCP seçimləri eyni direktivlə atılır. Belə müştəri qüsurlu deyil; o, öz konfiqurasiyasında açıq marşrut sətirləri gözləyir.

route-noexec fərqli bir nəzarətdir: müştərinin marşrut dəyişikliklərini ümumiyyətlə icra etməsini dayandırır. Müştərinin xəritələyə bilmədiyi topologiya oxşar nəticə yarada bilər və marşrut əlavə edilmiş deyil, rədd edilmiş kimi qeyd olunur. Üç səbəbdən hansının tətbiq olunduğunu təxmin etmək əvəzinə qərarı bildirən jurnal sətrini oxuyun. Sonra effektiv profili yoxlayın, çünki idxalçı və ya idarəetmə aləti istifadəçinin heç vaxt redaktə etmədiyi seçimləri əlavə edə bilər.

Mətn redaktorunda təmiz görünən profil icra zamanı əlavə edilmiş direktiv daşıya bilər.

İtələmə siyahısını cədvəllə müqayisə edin

Qoşulduqdan sonra serverin itələmə siyahısını müştərinin cədvəlinin yanına qoyun. Linux-da bu ip route show dev tun0; Windows-da isə route print və ya Get-NetRoute. Marşrut yoxdursa, əvvəlcə quraşdırmanı düzəldin. Mövcuddursa və trafik uğursuz olursa, ötürmə və firewall siyasətinə keçin.

Müştərinin versiyasını, hansı hesabla işlədiyini və xidmət əsaslı olub-olmadığını qeyd edin. Bu üç fakt növbəti şəxsə hansı səbəblərin istisna edildiyini bildirir.