VPN müştərisi üçün sabit daxili ünvanı üç yer saxlaya bilər və onlardan yalnız biri ona sahib olmalıdır. RADIUS ünvanı Access-Accept cavabında qaytara bilər, şlüz hesab üçün statik xəritə saxlaya bilər, müştəri adapteri isə əl ilə qurula bilər. İlk ikisi siyasətdir, üçüncüsü isə şlüzün laqeyd qala və ya üzərinə yaza biləcəyi yerli təxmindir. İlk ikisi arasında seçim əsl qərardır və şəbəkə giriş serverinin həqiqətən nə icra etdiyindən asılıdır.

Sabit ünvanın yerləşə biləcəyi üç yer

RADIUS ünvana o zaman sahib olur ki, cavab Framed-IP-Address daşıyır və şlüz həmin dəyəri sessiyaya tətbiq edir. Şlüz ünvana o zaman sahib olur ki, administrator hesabı hovuzun içindəki statik ünvana xəritələyir. Müştəri heç nəyə sahib deyil, hətta adapteri əl ilə ünvan göstərsə də, çünki server daxili ünvanı danışıqlar zamanı təyin edir və yerli parametr yalnız server heç nə göndərmədikdə əhəmiyyət kəsb edir. İşləyən bağlantıda hər üçü eyni görünür, buna görə toqquşmalar gec üzə çıxır. Fərq yenidən qoşulmada, ikinci cihazda və siyasət dəyişikliyindən sonra görünür.

İki sahib — dağılan konfiqurasiya budur. RADIUS cavabı 172.28.4.77 təyin edir, şlüz isə 172.28.4.90 üçün statik xəritə saxlayır; nəticədə satıcının kodu hansı dəyəri əvvəl yoxlayırsa, o qalır, uduzan isə jurnal sətri olmadan atılır. Eyni hesab ikinci cihazda təkrar ünvan alır və simptom təyinat toqquşmasından çox marşrutlaşdırma nasazlığı kimi oxunur. İkinci mexanizmi əlavə etməzdən əvvəl sahibi müəyyənləşdirin.

Müştəri tərəfindəki variantı yalnız onu istisna etmək üçün adlandırmağa dəyər. Əl ilə qurulan adapter ünvanı əməliyyat sisteminin təqdim edə biləcəyi üstünlükdür, rezervasiya deyil və başqa sessiyanın həmin ünvanı almasının qarşısını ala bilməz.

RADIUS cavabının nə vəd edə biləcəyi və bilmədiyi

RFC 2865Framed-IP-Address atributunu istifadəçi üçün konfiqurasiya ediləcək IPv4 ünvanı kimi müəyyən edir və o, Access-Accept cavabına aiddir. Access-Request içindəki eyni atribut yalnız serverin laqeyd qala biləcəyi bir işarədir; bu, müştəri və ya şlüz üstünlük verilən ünvan təklif etdikdə önəm kəsb edir. Protokolda şlüzü cavaba riayət etməyə məcbur edən heç nə yoxdur, çünki onu sessiyaya tətbiq edən komponent şəbəkə giriş serveridir.

Dəstək protokol deyil, məhsul məsələsidir. Bəzi şlüzlər çərçivələnmiş ünvanları susmaya görə tətbiq edir, bəziləri bunun üçün əvvəlcə qrup səviyyəsində açarın açılmasını tələb edir, bəziləri isə atributu qəbul edir və onu heç vaxt uzaqdan giriş sessiyaları üçün istifadə etmir. Bu son hal təhlükəlidir, çünki uçot qeydi cavabı göstərə bilər, müştəri isə hovuz ünvanı alır. Davranışı qardaş məhsulun sənədlərində deyil, işlətdiyiniz dəqiq şlüz modelində və proqram təminatında təsdiqləyin.

Şlüzün laqeyd qaldığı cavab, heç vaxt göndərilməmiş cavabla tam eyni görünür. Access-Accept cavabını və sessiya ünvanını yan-yana oxumaq iki halı ayırmağın yeganə yoludur.

Ünvanı artıq marşrutlaşdırdığınız hovuzun içində rezerv edin

Sabit ünvanı şlüzün artıq marşrutlaşdırdığı və firewall-un artıq etimad göstərdiyi hovuz alt şəbəkəsindən seçin. Bu aralıqdan kənarda ünvan siyasət dəyişikliyini marşrutlaşdırma layihəsinə çevirir və VPN qalxacaq, amma arxasında heç nə cavab verə bilməyəcək. Ünvan başına giriş qaydaları varsa, sabit ünvanı həmin dəyişiklikdə onlara əlavə edin.

İkinci eyni vaxtlı sessiyanın nə etməli olduğunu qərarlaşdırın. Bir ünvanı iki dəfə təyin etmək cihaz idarəçiliyi deyil və yaranan toqquşma hər iki sessiya üçün fasiləli bağlantı kimi görünür. Ya cihaz başına fərqli şəxsiyyətlər verin, ya fərqli təyinatlar verin, ya da dəstəklənən yoxlama ilə eyni vaxtlılığı tətbiq edin, məsələn Simultaneous-Use ilə, köhnə sessiyanın vaxtı bitməzdən əvvəl müştərinin bir daha qoşulmayacağına ümid etmək əvəzinə.

Qayıdış marşrutları təyinat qədər diqqətə layiqdir. Şlüzə hovuza marşrut lazımdır, daxili marşrutlaşdırıcılara şlüzə geri marşrut lazımdır və sabit ünvan hər ikisini miras alır. Bir müştərinin işləyib bütün digərlərinin uğursuz olması adətən hovuz marşrutunun mövcud olduğunu, lakin rezerv edilmiş ünvan üçün host marşrutunun olmadığını bildirir.

Lizinqə güvənməzdən əvvəl cavabı yoxlayın

AAA tərəfini və sessiya tərəfini ayrı-ayrılıqda yoxlayın, çünki onlar fərqli səbəblərdən uğursuz olur. Yerli radtest aləti şlüzü işə qatmadan serverin hesab üçün nə qaytardığını göstərir, istifadəçilər faylındakı qeyd isə serverin nə ilə uyğunlaşmalı olduğunu göstərir. Sonra müştərini yenidən qoşun və aldığı ünvanı cavabdakı atributla müqayisə edin.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77
survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Atributsuz Access-Accept serverin qeydi uyğunlaşdırmadığını və ya atributun həmin istifadəçiyə tətbiq olunmadığını bildirir. Atributlu Access-Accept və hovuz ünvanı almağa davam edən müştəri şlüzün ona laqeyd qaldığını bildirir. Access-Reject sizi yenidən etimad məlumatlarına və ya qrup siyasətinə qaytarır və bu nəticələrin heç biri müştəri adapterini redaktə etməklə ayıqlanmamalıdır.

Yenidən qoşulmadan sonra və başqa cihazdan ikinci girişdən sonra yoxlamanı təkrarlayın. Yalnız ilk sessiya üçün qüvvədə qalan rezervasiya baş verəcək hovuz toqquşmasıdır və onu indi tapmaq audit zamanı tapmaqdan daha ucuzdur.

Bir sahib seçin və onu yazın

Əgər şlüz çərçivələnmiş ünvanları etibarlı şəkildə tətbiq edirsə, təyinatın sahibi RADIUS olsun və eyni hesab üçün istənilən statik xəritəni silin. Əgər etmir, sahibi şlüz olsun və atributu cavabdan çıxarın ki, iki mənbə ziddiyyət təşkil edə bilməsin. Hər biri az qala işləyir deyə hər ikisini saxlamaq, gələcək sessiyanı yanlış ünvanla və aşkar səbəb olmadan təmin edir.

Seçilmiş sahibi, rezerv edilmiş ünvanı və onun gəldiyi hovuzu hesab qeydinə yazın. Cihaz əlavə edəcək növbəti şəxs hər ikisini dəyişməzdən əvvəl ünvanın AAA siyasəti, yoxsa şlüz xəritəsi olduğunu görə bilər.

Əlaqəli məqalələr