Bir OpenVPN müştərisində iki xidmət ünvanı: iroute və lo

Tətbiq öz tunel ünvanında cavab verir, ona sənədləşdirdiyiniz ünvan isə heç yerə getmir. OpenVPN jurnalında heç nə şikayət etmir, qarşı tərəf qoşulmuş görünür və mərkəz dəqiq bir müştəri sadalayır. Boşluq budur ki, müştəridə ikinci ünvan iki ayrı faktdır: host onu sahiblənməlidir və mərkəz hansı qarşı tərəfin sahib olduğunu bilməlidir. Birini digəri olmadan həll etsəniz, trafik ya mərkəzdə ölür, ya da evə marşrutsuz gəlir.

Ləqəb lokaldır, sahiblik uzaqdadır

Tunel ünvanı razılaşdırılır, ona görə də hər iki tərəf onu əl sıxma zamanı öyrənir. Əlavə xidmət ünvanı heç razılaşdırılmır, buna görə də onu əlavə etmək mərkəzdə təkbaşına heç nəyi dəyişmir. Müştəri ünvanı dərhal sahiblənə bilər və server yenə də o trafiki öz standart yoluna göndərəcək və ya atacaq. İki qeyd, iki fərqli yerdə yaradılmalıdır.

Müştəridə ünvan hosta aiddir və loopback fiziki keçiddə heç vaxt görünməməli olan xidmət kimliyi üçün təbii evdir. Mərkəzdə isə qarşı tərəfin prefiksə xəritələnməsi yalnız serverin oxuduğu ayrı bəyandır. Qeydlərin heç biri digərini şərtləndirmir.

Qeydlərinizdə iki diapazonu fərqli saxlayın. Nümunədəki ünvanlar sənədləşmə dəyərləridir və onları real LAN ilə üst-üstə salmaq işləyən qurğunu sınıq göstərməyin ən sürətli yoludur.

Ünvanı müştəriyə davamlı şəkildə əlavə edin

Xidmət ünvanını loopback üzərinə host prefiksi ilə yerləşdirin ki, host ona çatılmalı subnet kimi deyil, yerli giriş kimi yanaşsın. ip address add 10.66.0.10/32 dev lo bunu bir ünvan üçün edir, əmri ikinci ünvan üçün təkrar etmək isə iki xidməti modelləşdirir.

Bunu birdəfəlik sınaq kimi işə salın, sonra hostun şəbəkə konfiqurasiyasına sahib olan şeyə köçürün, çünki işləmə vaxtı əlavəsi yenidən başlatmada yox olur və təkrar qoşulmalarda dublikatlar yığılır. Şəbəkədən sonra sıralanan systemd vahidi bir seçimdir, distributiv şəbəkə meneceri isə digəri. Hansını seçsəniz də, ünvan tətbiq qoşulmadan əvvəl mövcud olmalıdır, əks halda xidmət səhv soketdə qalxır. Yenidən başlatmadan sonra əl əmri ilə deyil, ip address show dev lo ilə yoxlayın.

Bağlama ünvanlamadan ayrı bir qərardır. Hər ünvanda dinləyən tətbiq heç vaxt nəzərdə tutmadığınız interfeyslərdə trafik qəbul edir, ona görə də onu konkret xidmət ünvanına yönəldin. Onda yerli giriş siyasətinin dəqiq uyğunlaşdıracağı bir şeyi olur.

Onu mərkəzin həqiqətən oxuduğu CCD faylında tələb edin

Serverdə sahiblik bəyanı autentifikasiyadan keçmiş ümumi adla seçilən müştəri faylına gedir, client-config-dir ilə adlandırılan qovluğun içində. Sətir iroute 10.66.0.10 255.255.255.255-dir, hər ünvan üçün bir dənə, və serverə hansı qarşı tərəfin bu təyinat üçün trafik almalı olduğunu deyir.

İki detal bunu səssizcə poza bilər. Fayl adı serverin həqiqətən istifadə etdiyi adla uyğun olmalıdır, bu isə username-as-common-name işlədikdə fərqlənir. Və iroute yalnız TUN rejimində, müştəri konfiqurasiya qovluğu qurulmuş halda qüvvəyə minir, ona görə də eyni sətir körpülənmiş yerləşdirmədə heç nə etmir. Sətirləri mövcud fayla əlavə edin, onu əvəz etməyin, çünki o, artıq sabit ünvan və ya push seçimləri daşıya bilər. OpenVPN 2.6 arayışı həm qovluğu, həm də sahiblik direktivini sənədləşdirir.

Mərkəzin öz nüvəsi də həmin təyinatlar üçün yol tələb edir ki, yerli yaradılan trafik tunel prosesinə daxil olsun. Server konfiqurasiyasındakı route 10.66.0.10 255.255.255.255 serverin özünün yaratdığı trafiki əhatə edir, digər müştərilər isə təyinatı özləri öyrənmək üçün push "route 10.66.0.10 255.255.255.255"-ə ehtiyac duyur.

Marşrutlaşdırma və avtorizasiya ayrı qalır. Göndərilən marşrut müştəriyə paketləri hara göndərəcəyini deyir və heç nə vermir; xidmət yenə də çağıranı öz şərtləri ilə qəbul etməlidir.

Giriş siyasətini və cavab yolunu yoxlayın

Ləqəbə ünvanlanmış paket sahib hosta yerli giriş kimi gəlir, ona görə sual budur: yerli firewall həmin mənbəyə və porta icazə verirmi. Bütün ünvanı açmaq əvəzinə VPN mənbə diapazonundan konkret xidmət portuna icazə verin.

Cavabların çağırana geri yol lazımdır. Adi tunel hovuzunun içindəki çağıran üçün o yol artıq mövcuddur, çünki tunel cihazı onu daşıyır. Başqa marşrutlaşdırılmış şəbəkənin arxasındakı çağıran həmin şəbəkənin geri marşrutuna da ehtiyac duyur və asimmetrik qurğular məhz burada paket itirir.

Eyni portda fərqli ünvana bağlanmış ikinci dinləyiciyə diqqət edin, çünki nüvə uyğun gələn hansı soketə olsa çatdırır və nəticələr təsadüfi görünür. ss -lntp ilə yoxlayın və bağlanmış ünvanın xidmət ləqəbi olduğunu təsdiqləyin. Mənbə NAT burada tələb olunmur və onu əlavə etmək jurnallarınızın asılı olduğu çağıran kimliyini gizlədir.

Ünvanları və sahibliyi ayrı-ayrılıqda sınayın

İki addımda sınayın. Əvvəlcə sahib hostun xidmətə öz ləqəbi üzərindən özündən çata bildiyini təsdiqləyin, bu bağlama və firewall problemlərini marşrutlaşdırmadan ayırır. Sonra tətbiqin öz autentifikasiyası ilə real VPN çağıranından sınayın. Birinci keçəndə və ikinci uğursuz olanda, çatışmayan hissə mərkəz tərəfindədir.

Bağlantıdan sonra da qalan nasazlıq rejimlərini yoxlayın: tunel söndükdə ləqəb təyin olunmuş qalır və qarşı tərəf yox olduqda mərkəz öz marşrutunu saxlayır. Heç bir obyekt tək başına xidmətin əlçatan olduğunu sübut etmir, buna görə iki addımlı sınaq noutbukdan bir ping-dən üstündür.