Gestione IT

Il nuovo controllo remoto di Kaseya: cosa ci sta dietro – parte III

07 Luglio 2014

In un precedente post abbiamo visto alcune tecnologie utilizzate dal nuovo controllo remoto di Kaseya.

Probabilmente l’aspetto che ha i risvolti pratici più importanti in un controllo remoto veloce e affidabile risiede nelle tecniche di connettività usate dal software.
I tipi di connessione che usa Kaseya e il mix del loro utilizzo rendono il nuovo controllo remoto iperveloce: vediamo come e perché.
 
Connettività P2P
 
La connettività peer-to-peer è il collegamento di rete preferenziale per un viewer quando si deve connettere a un agente per controllarlo in remoto. Generalmente offre performance e latenza da primato.
Inoltre poiché il viewer e il target sono in collegamento diretto, non vengono introdotti ritardi al framework Kaseya.
Il nuovo controllo remoto utilizza un protocollo chiamato ICE (Interactive Connectivity Establishment) per stabilire connessioni P2P. ICE è progettato per testare tutti i tipi di connessioni possibili al fine di trovare quello che funziona meglio nell’ambiente in cui si trova a operare.
Se parlo di TCP, UDP, IPv4, IPv6, VPN, Teredo… sapete di cosa parlo.
Inoltre ICE si fa carico di attraversare i firewall e di lavorare anche con i NAT. Per raggiungere questo scopo sfrutta il fatto che la maggior parte dei firewall e dei NAT consenta la "reverse connectivity" sulle porte che sono state usate per aprire connessioni in uscita: voglio dire che se si apre una connessione in uscita da un LAN, si può rientrare su quella stessa connessione dallo stesso punto da cui si è usciti.
Questo assicura che non ci siano configurazioni da fare sui firewall per supportare la nuova soluzione di controllo remoto.
ICE seleziona la miglior connessione P2P sulla connettività disponibile in quel momento e in base a diversi altri fattori.
In pratica questo significa che in LAN si lavorerà in TCP, in WAN, in UDP e in VPN quando non ci sono altri path disponibili.
Però testare tutti le connessioni e i percorsi possibili è un’attività che può richiedere parecchi secondi e in alcuni ambienti addirittura non sarà possibile instaurare connessioni P2P, il che ci porta a parlare di connessioni "relayed".
 
Connessioni "relayed"
 
Come alternativa alle connessioni P2P, il controllo remoto di Kaseya può utilizzare connessioni con il server Kaseya come relay. Le sessioni "relayed" o "proxate" sono più veloci e difficilmente soffrono la presenza di firewall o NAT. Inoltre su connessioni lunghe tendono a essere più stabili delle sessioni P2P eseguite su UDP.
In termini pratici le connessioni relayed vengono eseguite facendo, sia dal viewer sia dall’agent, una connessione in uscita verso il server Kaseya dove i due endpoint si trovano e il traffico viene scambiato.
Per minimizzare l’impatto sulla rete, le connessioni di controllo remoto lavorano sulla stessa porta su cui lavora l’agente per collegarsi al server Kaseya, il che significa che ogni volta che un agent fa check-in, sarà disponibile per una sessione di controllo remoto.
 
Connessioni P2P e "relayed" usate insieme
 
E’ chiaro che le connessioni P2P e le connessioni "proxate" hanno entrambe vantaggi e svantaggi quindi sarebbe vergognoso dire che sono uguali ed è indifferente quale usare.
Per trarre il meglio da entrambe, il controllo remoto di Kaseya usa entrambi i tipi di connessione in parallelo.
In particolare:
 
  • quando viene avviata una sessione di controllo remoto, Kaseya cerca di stabilire una connessione di entrambi i tipi;
  • non appena una connessione è disponibile, la sessione inizia; in genere la connessioni "proxata" è quella che si stabilisce per prima; questo si traduce in un tempo di connessione pressoché nullo.
  • Con la sessione stabilita e una volta iniziata la sessione remota, Kaseya cerca di stabilire una connessione migliore e generalmente riesce a stabilirne una P2P nel giro di qualche secondo;
  • quando la sessione P2P è stabilita, cambia automaticamente da "proxata" a P2P in maniera totalmente trasparente per l’utente e quindi senza interruzioni video o senza latenze di mouse e tastiera;
  • anche se si stabilisce una connessione P2P, la sessione "proxata" viene in ogni caso mantenuta attiva; se infatti la sessione P2P dovesse avere problemi o cadere, il controllo remoto cambierebbe nuovamente veicolo e andrebbe avanti con la sessione "proxata", sempre in background mentre Kaseya tenta di ristabilire la sessione migliore.

La sintesi di tutto è che a partire da Kaseya 7 le connessioni remote sono molto più veloci, anche su reti a scarsa latenza, e più robuste, ossia cadono molto raramente.

Buon divertimento allora con il controllo remoto di Kaseya!
Autore
Claudio Panerai
Gli ultimi prodotti che vi ho portato, nel 2020: Vade Secure Il primo sistema antispam/antihishing/antimalware basato sull'intelligenza artificiale e appositamente progettato per Office 365. Naturalmente a misura di MSP. ID Agent Piaffaforma che consente agli MSP di monitorare le credenziali (proprie e dei clienti) che sono in vendita nel dark web.
Nato a Ivrea nel 1969, è sposato e padre di due figlie. Laureato in Scienze dell’Informazione nel 1993, ha dapprima svolto numerose consulenze e corsi di formazione per varie società per poi diventare responsabile IT per la filiale italiana del più grande editore mondiale di informatica, IDG Communications. Dal 2004 lavora in Achab dapprima come Responsabile del Supporto Tecnico per poi assumere dal 2008 la carica di Direttore Tecnico. Giornalista iscritto all’albo dei pubblicisti, dal 1992 pubblica regolarmente articoli su riviste di informatica e siti web di primo piano. E' stimato da colleghi e clienti per la schiettezza e onestà intellettuale. Passioni: viaggi, lettura, cinema, Formula 1, sviluppo personale, investimenti immobiliari, forex trading. Claudio è anche su LinkedIn e Facebook.
Commenti (0)

Lascia un commento

Il tuo indirizzo e-mail non verrà pubblicato, lo utilizzeremo solamente per inviarti la notifica della pubblicazione del tuo commento. Ti informiamo che tutti i commenti sono soggetti a moderazione da parte del nostro staff.