JConsole reyestrə qoşulur, sonra RMI onu başqa yerə göndərir

Tunel vasitəsilə reyestr portuna qoşulun, əl sıxışmasının başlamasını izləyin və sonra JConsole-un yenə də vaxt aşımına düşdüyünü görün. Bu, ilk TCP bağlantısının idarəetmə bağlantısı deyil, axtarış olması səbəbindən baş verir. RMI reyestri host və ikinci port göstərən bir istinadla cavab verir və JConsole sonra ona deyilən yerə gedir. Əgər tunel yalnız serverin ilk portuna çatırsa və ya istinad yalnız serverin öz lokal şəbəkəsində mövcud olan ünvanı göstərirsə, müştəri zahirən müvəffəqiyyətli olduqdan sonra ilişib qalır.

Mif: bir açıq port bir bağlantıdır

RMI üzərindən uzaq JMX ən azı iki son nöqtəni əhatə edir və onlar sistemin müxtəlif hissələri tərəfindən seçilir. Reyestr portu müştəriyə yazdığınız portdur və real konnektoru təsvir edən stub-u vermək üçün mövcuddur. İlk uğurlu soketi idarəetmə yolunun açıq olmasının sübutu saymaq iki dəqiqəlik diaqnozu firewall biletləri ilə dolu bir günorta çevirir.

Serverin dinləyici siyahısına deyil, müştərinin öz xətasına baxın. Əl sıxışması başladıqdan sonra yaranan xəta birinci deyil, ikinci bağlantının tamamlanmadığını bildirir.

Reyestr nə qaytarır

Stub konnektor yaradılan anda seriyalaşdırılmış ünvan və port saxlayır. Bir neçə interfeysi olan serverdə yığın lokal şəbəkədən əldə olunan, sizinkindən isə olmayan bir ünvan seçmiş ola bilər. Müştəri fərqi bilmir; sadəcə aldığı dəyəri yığır və paket həmin ünvan üçün mövcud olan marşrutu izləyir, VPN müştərisində bu çox vaxt heç biri deyil. İkinci bağlantının cəhd edildiyi an budur.

Xətanın mühitlər arasında qeyri-sabit olmasının səbəbi də budur: eyni server JMX konfiqurasiyasında heç bir dəyişiklik olmadan lokal şəbəkədəki istifadəçi üçün və tuneldəki istifadəçi üçün fərqli davrana bilər.

İki port və onları bərkidən iki xassə

Reyestr portu com.sun.management.jmxremote.port parametrindən gəlir və konnektor yığının ayırdığına buraxılmaq əvəzinə com.sun.management.jmxremote.rmi.port ilə bərkidilə bilər. Müştəri ilə server arasında firewall və ya təhlükəsizlik qrupu varsa, ikisini də açıq şəkildə təyin edin, çünki gözlənilməz ikinci portu əvvəlcədən icazə vermək mümkün deyil və onu qarşılamaq üçün açılan geniş diapazon bir dəyəri bərkidməkdən pisdir.

Sonra serverdə ss -ltn və ya netstat -an ilə hər iki portun dinlədiyini və hansı ünvanlarda olduğunu təsdiqləyin. Loopback-ə bağlanmış dinləyici yalnız lokal yerləşdirmə üçün düzgündür və bunun üçün yararsızdır.

Elan olunan ad səhv olduqda

Uzaq istinaddakı host adı java.rmi.server.hostname tərəfindən təyin edilir. Stub-un nə elan etdiyinə təsir edir; özlüyündə hər dinləyicini bir interfeysə bağlamaq əmri deyil, buna görə də onun təyini həmişə gözlənilən tək port davranışını vermir. Onu təyin edin, prosesi yenidən başladın və sonra stub-un həqiqətən nə saxladığını yoxlayın. Müştərinin həll edə və tuneldən çata biləcəyi ad və ya ünvan seçin və stub-un yenidən qurulması üçün prosesi yenidən başladın.

Konteyner şəbəkələri bunu daha da pisləşdirir, çünki prosesin gördüyü ünvan konteynerdən kənarda heç nənin marşrutlaşdıra bilmədiyi daxili ünvan ola bilər. Platformanın seçməsinə imkan vermək əvəzinə nəzərdə tutulan host adını açıq şəkildə dərc edin.

VPN əvəzinə SSH ilə tunel qurursunuzsa, eyni problem başqa libasda görünür: yalnız reyestr portunu yönləndirmək ikinci son nöqtəni müştərinizin çata bilmədiyi ünvana yönəldilmiş qoyur. Hər iki portu yönləndirin və elan olunan adın müştərinin lokal olaraq çata biləcəyi bir şeyə həll olunmasını təmin edin.

Sadələşdirmək üçün idarəetmə təhlükəsizliyini söndürməyin

Autentifikasiyanı və TLS-i söndürən fraqmentlər asan tapılır və bağlantını sonradan geri qaytarmalı olacağınız şəkildə işlədir. Uzaq JMX yoxladığı proseslə eyni imtiyazlara malik idarəetmə interfeysidir; giriş nəzarətlərini saxlayın və müştəri etimadnamə təqdim edə bilmirsə, məhz bunu düzəldin.

Son nöqtələr düzgün olduqda, gördüyünüz növbəti xətanı saxlayın. Etibarlılıq anbarı və ya hesab tərəfindən rədd əlçatmaz konnektordan daha sonrakı mərhələdir və şəbəkə işinin bitdiyini bildirir.