JConsole se conectează la registru, apoi RMI o trimite în altă parte

Conectează-te la portul registrului prin tunel, urmărește cum începe negocierea și apoi privește cum JConsole intră totuși în timeout. Se întâmplă pentru că prima conexiune TCP nu este conexiunea de administrare: este o căutare. Registrul RMI răspunde cu o referință care numește un host și un al doilea port, iar JConsole merge apoi oriunde i s-a spus. Dacă tunelul ajunge doar la primul port al serverului, sau dacă referința numește o adresă care există doar în LAN-ul serverului însuși, clientul se blochează după ce pare că a reușit.

Mitul: un port deschis este o conexiune

JMX la distanță prin RMI implică cel puțin două capete, iar ele sunt alese de părți diferite ale sistemului. Portul registrului este cel pe care îl tastezi în client, și există pentru a livra stub-ul care descrie conectorul real. A lua primul socket reușit drept dovadă că calea de administrare este deschisă este ceea ce transformă un diagnostic de două minute într-o după-amiază de tichete pentru firewall.

Uită-te la eroarea clientului însuși, nu la lista de ascultători a serverului. O eroare după ce începe negocierea îți spune că a doua conexiune, nu prima, nu s-a finalizat.

Ce returnează registrul

Stub-ul conține o adresă și un port, serializate în momentul în care a fost creat conectorul. Pe un server cu mai multe interfețe, stiva poate alege o adresă accesibilă din rețeaua locală și inaccesibilă din a ta. Clientul nu cunoaște diferența; pur și simplu apelează valoarea pe care a primit-o, iar pachetul urmează ruta care există pentru acea adresă, care pe un client VPN adesea nu este niciuna. Acesta este momentul în care este încercată a doua conexiune.

Acesta este și motivul pentru care eroarea este intermitentă între medii: același server se poate comporta diferit pentru un utilizator din LAN și pentru unul din tunel, fără nicio modificare a configurației JMX.

Două porturi și două proprietăți care le fixează

Portul registrului vine din com.sun.management.jmxremote.port, iar conectorul poate fi fixat cu com.sun.management.jmxremote.rmi.port în loc să fie lăsat la ce alocă stiva. Stabilește-le pe amândouă explicit când între client și server există un firewall sau un grup de securitate, pentru că un al doilea port imprevizibil nu poate fi permis în avans, iar un interval larg deschis pentru a-l acomoda este mai rău decât fixarea unei singure valori.

Apoi confirmă cu ss -ltn sau netstat -an pe server că ambele porturi ascultă și pe ce adrese. Un listener legat de loopback este corect pentru o implementare doar locală și inutil pentru aceasta.

Când numele anunțat este greșit

Numele de host care apare în referința la distanță este stabilit de java.rmi.server.hostname. Afectează ceea ce anunță stub-ul; nu este în sine o instrucțiune de a lega fiecare listener la o singură interfață, motiv pentru care setarea lui nu produce întotdeauna comportamentul cu un singur port așteptat. Setează-l, repornește procesul și apoi verifică ce conține de fapt stub-ul. Alege un nume sau o adresă pe care clientul o poate rezolva și atinge prin tunel, și repornește procesul pentru ca stub-ul să fie reconstruit.

Rețelele de containere înrăutățesc lucrurile, pentru că adresa pe care o vede procesul poate fi una internă, pe care nimic din afara containerului nu poate ruta. Publică explicit numele de host dorit în loc să lași platforma să aleagă.

Dacă tunelul se face cu SSH în loc de VPN, aceeași problemă apare într-o altă haină: redirecționarea doar a portului registrului lasă al doilea capăt îndreptat spre o adresă pe care clientul tău nu o poate atinge. Redirecționează ambele porturi și fă ca numele anunțat să se rezolve la ceva ce clientul poate atinge local.

Nu dezactiva securitatea administrării pentru a simplifica

Fragmentele care dezactivează autentificarea și TLS sunt ușor de găsit și fac conexiunea să funcționeze într-un mod pe care va trebui să îl anulezi mai târziu. JMX la distanță este o interfață de administrare cu aceleași privilegii ca procesul pe care îl inspectează; păstrează controalele de acces și, dacă clientul nu poate prezenta credențiale, remediază asta în schimb.

După ce capetele sunt corecte, păstrează următoarea eroare pe care o vezi. O respingere din partea truststore-ului sau a contului este o etapă ulterioară unui conector inaccesibil și înseamnă că munca de rețea s-a terminat.