Müştəri qancası, yoxsa server qancası? OpenVPN skripti harada işləyir

Tapşırıq aydındır: noutbuk qoşulanda noutbukda nəyinsə dəyişməsi lazımdır. Redaktə olunan konfiqurasiya serverə aiddir və fərziyyə məhz burada pozulur. Server faylındakı yol həmin serverdəki faylı göstərir və nə qədər push etsəniz də, prosesin kim tərəfindən icra olunduğu dəyişmir. İki qancaq arasında seçim əsasən işin hansı maşına aid olduğunu qərar vermək və bundan irəli gələn məhdudiyyətləri qəbul etmək məsələsidir.

İki maşın, əvvəlcə cavablandırılmalı iki sual

Əvvəlcə vəziyyət dəyişikliyinin harada baş verməli olduğunu soruşun, sonra ona hansı hadisənin uyğun gəldiyini soruşun. Əgər dəyişiklik hər istifadəçi üçün avtorizasiya və ya hər müştəri üçün konfiqurasiya qərarıdırsa, istifadəçi kataloqunun bilindiyi yerə aiddir: serverə. Əgər dəyişiklik marşrutdursa, resolver parametri və ya son nöqtədəki yerli köməkçi proqramdırsa, son nöqtəyə aiddir və bunu yalnız son nöqtə edə bilər.

Bu iki suala tərs qaydada cavab vermək insanların Windows noutbuka batch faylı push etməyə çalışması ilə nəticələnir. Server kimin qoşulduğunu bilir; noutbuk öz şəbəkə yığınının necə göründüyünü bilir. Heç biri digərinin məlumatına malik deyil və cəhd adətən aydın xəta yerinə səssizcə uğursuz olur.

Hər ikisindən əvvəl üçüncü bir sualı verməyə dəyər: platforma ümumiyyətlə istədiyiniz qancağı təqdim edirmi? Öz konfiqurasiyasını yaradan cihaz eyni hadisə adlarını təklif etməyə bilər və .ovpn faylını idxal edən masaüstü müştəri, faylın onun üçün yazıldığı müştəri ilə eyni olmaya bilər. Platformanı əvvəlcədən təsdiqləmək sizi orada mövcud olmayan qancaq ətrafında dizayn qurmaqdan xilas edir. Həm də qarşınızdakı maşına hansı sənədlərin həqiqətən aid olduğunu göstərir.

Server tərəfi seçimi: hər bağlantı üçün hadisə

client-connect skripti autentifikasiya olunmuş müştəri qoşulduqda server prosesinin kontekstində işləyir və common name və təyin edilmiş ünvan kimi sənədləşdirilmiş bağlantı təfərrüatlarını alır. O, hər müştəri üçün konfiqurasiya fraqmenti yazmaq, siyasət qərarını tətbiq etmək və ya serverə aid vəziyyəti qeyd etmək üçün doğru yerdir.

İnsanların qaçırdığı fərq bu qancaqla server up qancağı arasındakı fərqdir. Up qancağı server öz tunel cihazını açanda işə düşür ki, bu da çoxmüştəri serverdə daemon başlayanda bir dəfə olur. Bu, hər giriş üçün hadisə deyil və ora qoyulan kod istifadəçilər qoşulanda deyil, xidmət başlayanda işləyir.

Veb interfeysi olan cihazda yaradılmış daemon fayllarını redaktə etmək əvəzinə dəstəklənən genişləndirmə mexanizmindən istifadə edin. Yaradılmış fayllar növbəti yadda saxlamada yenidən yazılır və yenidən yazma sizin dəyişikliyinizi ən pis anda səssizcə silir. Genişləndirmə mətninin surətini cihazdan kənarda saxlayın ki, proqram təminatı yenilənməsi niyyəti də itirməsin.

Müştəri tərəfi seçimi: yerli işləməli olan iş

İcma müştərisi tunel cihazı qalxanda və marşrutlar quraşdırılanda yerli skript işlədə bilər. Bunlar iki fərqli məqamdır və yanlış birini seçmək köməkçi proqramın asılı olduğu marşrut hələ mövcud olmamışdan əvvəl başlaması kimi klassik yarış yaradır.

Köməkçi proqram həmin müştəridə mövcud olmalı, müştərini işə salan hesab tərəfindən oxuna və icra oluna bilməli və açıq script-security parametri ilə icazə verilməlidir. Müştərini administrator kimi işə salanda işləyən skript, girişdən əvvəl işləyən xidmət və ya başqa istifadəçinin sessiyası haqqında heç nə demir.

Adlandırma da vacibdir. Up qancağı cihazın yaradılmasına, route-up isə marşrutların quraşdırılmasına uyğun gəlir, lakin şəxsi şəbəkənin əlçatan olmasını tələb edən tapşırıq cihazın yaradılmasının hər marşrutun, resolver qeydinin və tətbiqin hazır olması demək olduğunu fərz etmək əvəzinə əlçatanlığı yoxlamalıdır.

Niyə icra olunan kodun push edilməsi seçimlər arasında deyil

Push edilən parametrlər qəsdən məhdudlaşdırılıb və skript icra edən parametrlər serverin ötürməsinə icazə verilməyən kateqoriyalardandır. Bu məhdudiyyət ona görə var ki, əks halda kompromisə uğramış və ya səhv konfiqurasiya edilmiş server hər qoşulan müştəridə ixtiyari əmrlər işlədə bilərdi.

Skript icrasını yerli olaraq aktivləşdirmək bunu dəyişmir. Sizin script-security parametriniz özünüz seçdiyiniz yerli skriptlərə icazə verir; serverə yenisini təqdim etmək səlahiyyəti vermir.

Məqsəd sadəcə VPN marşrutlarını quraşdırmaqdırsa, uzaqdan icra sxemi uydurmaq əvəzinə dəstəklənən marşrut konfiqurasiyasından istifadə edin. Məqsəd həqiqətən yerli kod tələb edirsə, onu təşkilatın son nöqtə idarəetmə alətləri ilə yayın və istifadəçinin imtiyazları ilə işləyən hər hansı digər proqram kimi nəzərdən keçirin.

Hər iki qancağa güvənməzdən əvvəl nəyi yoxlamalı

Hər qancaq üçün dörd şey yazın: maşın, hadisə adı, hansı hesab altında işlədiyi və yaratmalı olduğu vəziyyət dəyişikliyi. Sonra bağlantını, yenidən qoşulmanı və təmizləmə yolunu sınayın, çünki yenidən qoşulmada vəziyyəti sızdıran qancaq heç işləməmiş qancaqdan pisdir.

Onu həqiqətən icra edəcək hesab altında, həqiqətən icra edəcəyi anda sınayın. openvpn(8) təlimatı hər iki qancaq ailəsini və push məhdudiyyətlərini sənədləşdirir; yerləşdirdiyiniz platforma isə onları ümumiyyətlə təqdim edib-etmədiyini sənədləşdirir. İnteraktiv administrator terminalında uğur qazanan skript fərziyyədir, yoxlama deyil.