Collegamenti a singhiozzo con il protocollo Ssh
Dopo anni di connessione a Internet via modem analogico ho sottoscritto un abbonamento Adsl a consumo. Tutto ha funzionato bene fino a quando ho tentato di connettermi al server aziendale tramite Ssh (Secure shell), cosa che facevo regolarmente con le connessioni dial-up. Con l’Adsl la connessione non era ottenibile e veniva riportato un errore di time-out. Ho tracciato il percorso dei pacchetti tra il mio indirizzo Ip e il sito di destinazione per verificare se si trattasse di un problema di instradamento, ma l’utilità Traceroute ha confermato che il collegamento era possibile e funzionava correttamente.
Ho provato anche in ambiente Linux a esaminare i pacchetti inviati sull’interfaccia assegnata alla connessione Adsl ma anche in questo caso non sono state riscontrate anomalie. Stranamente, dopo alcuni giorni la connessione tramite Ssh è stata stabilita regolarmente ma a un successivo collegamento il problema si è ripresentato. Dopo aver investigato un po’, ho scoperto che quando l’Ip assegnato appartiene a un certo gruppo la connessione Ssh è possibile, mentre quando l’assegnazione viene eseguita a partire da un gruppo diverso il protocollo non funziona.
Dopo vari contatti al servizio clienti di Tin.it un tecnico mi ha riferito che, probabilmente, c’è un errore di configurazione in uno dei router che instradano i pacchetti: in un caso, la connessione Ssh viene filtrata mentre nell’altro caso è regolarmente instradata. Purtroppo, il protocollo per questo tipo di connessioni non è utilizzato da un grande numero di utenti ed è quindi improbabile che il provider si prenderà il disturbo di sistemare le configurazioni errate che non ne consentono l’utilizzo. Cosa posso fare?
Ho provato anche in ambiente Linux a esaminare i pacchetti inviati sull’interfaccia assegnata alla connessione Adsl ma anche in questo caso non sono state riscontrate anomalie. Stranamente, dopo alcuni giorni la connessione tramite Ssh è stata stabilita regolarmente ma a un successivo collegamento il problema si è ripresentato. Dopo aver investigato un po’, ho scoperto che quando l’Ip assegnato appartiene a un certo gruppo la connessione Ssh è possibile, mentre quando l’assegnazione viene eseguita a partire da un gruppo diverso il protocollo non funziona.
Dopo vari contatti al servizio clienti di Tin.it un tecnico mi ha riferito che, probabilmente, c’è un errore di configurazione in uno dei router che instradano i pacchetti: in un caso, la connessione Ssh viene filtrata mentre nell’altro caso è regolarmente instradata. Purtroppo, il protocollo per questo tipo di connessioni non è utilizzato da un grande numero di utenti ed è quindi improbabile che il provider si prenderà il disturbo di sistemare le configurazioni errate che non ne consentono l’utilizzo. Cosa posso fare?
Franco Bollei, via internet
Nella maggior parte dei contratti che i service provider italiani propongono ai clienti, il collegamento a Internet è offerto come un servizio unico piuttosto che come una raccolta di funzionalità diverse. Spesso nelle condizioni del contratto non è specificato quali protocolli siano realmente disponibili e quali no, per cause tecniche o per espressa volontà. Per chiarire meglio il problema facciamo un esempio: con una connessione Adsl flat (a canone fisso) è teoricamente possibile gestire un file server o un piccolo sito Web sul proprio computer e permetterne l’accesso a utenti esterni che siano a conoscenza dell’indirizzo Ip. Questo utilizzo è assolutamente lecito e previsto sia dal sistema operativo sia dalle applicazioni. Molti provider scelgono però di non consentire il traffico sulle porte normalmente utilizzate per gli scopi appena descritti, rendendo impossibile l’utilizzo del computer in modalità server.
Se l’utente riportasse il problema al servizio clienti riceverebbe spesso una risposta scoraggiante del tipo: “Questo disservizio non è considerato dal provider un malfunzionamento o una limitazione, quanto piuttosto una scelta implementativa”. La maggioranza degli utenti si accontenta infatti di navigare con un browser, leggere la posta elettronica, accedere ad altri servizi quali le chat, videoconferenze e così via. Il provider può limitarsi a garantire questi servizi senza preoccuparsi di attivare altre funzionalità, assolutamente legittime. I motivi che portano i provider a questo comportamento dipendono dal fatto che, in molti casi, forniscono servizi di hosting (possibilità di caricare il proprio sito Web su un server per consentire a chiunque di collegarsi anche quando si è off-line) o di file serving. Se l’utente avesse la possibilità di gestire questi servizi dal proprio computer, potrebbe evitare il pagamento del canone richiesto dal provider per queste funzionalità aggiuntive. Spesso la volontà di non rendere disponibili le porte necessarie a questi servizi viene descritta come un beneficio per l’utente: impedendo il transito dei pacchetti si contribuisce a proteggere il computer da accessi indesiderati.
Effettivamente, il fatto che alcuni provider non rendano disponibili le porte per i servizi Rpc (Remote procedure call) e Upnp (Universal plug and play) ha contribuito a proteggere i computer dall’attacco dei più recenti cavalli di Troia, ma le limitazioni che ne derivano non sono trascurabili. Tin.it è, tra i provider italiani, uno dei più liberali: non vengono applicate politiche per impedire l’utilizzo del computer in modalità server ed è possibile raggiungere tutte le porte di un determinato indirizzo Ip dall’esterno. Viene così garantita la piena funzionalità di tutti i programmi di file sharing, di videoconferenza e altri peer-to-peer.
L’unica controindicazione è, come spiegato, la necessità di installare un firewall software per garantire la sicurezza del computer da eventuali attacchi esterni.
Nel caso specifico del lettore, non essendovi una specifica lista di servizi garantiti nel contratto stipulato con il service provider non è probabilmente possibile operare alcuna pressione per ottenere il ripristino del protocollo Ssh. Riteniamo comunque che durante i periodici adeguamenti della Rete del fornitore (operazioni che richiedono la riconfigurazione dei router) il problema sarà probabilmente risolto.
Se l’utente riportasse il problema al servizio clienti riceverebbe spesso una risposta scoraggiante del tipo: “Questo disservizio non è considerato dal provider un malfunzionamento o una limitazione, quanto piuttosto una scelta implementativa”. La maggioranza degli utenti si accontenta infatti di navigare con un browser, leggere la posta elettronica, accedere ad altri servizi quali le chat, videoconferenze e così via. Il provider può limitarsi a garantire questi servizi senza preoccuparsi di attivare altre funzionalità, assolutamente legittime. I motivi che portano i provider a questo comportamento dipendono dal fatto che, in molti casi, forniscono servizi di hosting (possibilità di caricare il proprio sito Web su un server per consentire a chiunque di collegarsi anche quando si è off-line) o di file serving. Se l’utente avesse la possibilità di gestire questi servizi dal proprio computer, potrebbe evitare il pagamento del canone richiesto dal provider per queste funzionalità aggiuntive. Spesso la volontà di non rendere disponibili le porte necessarie a questi servizi viene descritta come un beneficio per l’utente: impedendo il transito dei pacchetti si contribuisce a proteggere il computer da accessi indesiderati.
Effettivamente, il fatto che alcuni provider non rendano disponibili le porte per i servizi Rpc (Remote procedure call) e Upnp (Universal plug and play) ha contribuito a proteggere i computer dall’attacco dei più recenti cavalli di Troia, ma le limitazioni che ne derivano non sono trascurabili. Tin.it è, tra i provider italiani, uno dei più liberali: non vengono applicate politiche per impedire l’utilizzo del computer in modalità server ed è possibile raggiungere tutte le porte di un determinato indirizzo Ip dall’esterno. Viene così garantita la piena funzionalità di tutti i programmi di file sharing, di videoconferenza e altri peer-to-peer.
L’unica controindicazione è, come spiegato, la necessità di installare un firewall software per garantire la sicurezza del computer da eventuali attacchi esterni.
Nel caso specifico del lettore, non essendovi una specifica lista di servizi garantiti nel contratto stipulato con il service provider non è probabilmente possibile operare alcuna pressione per ottenere il ripristino del protocollo Ssh. Riteniamo comunque che durante i periodici adeguamenti della Rete del fornitore (operazioni che richiedono la riconfigurazione dei router) il problema sarà probabilmente risolto.
Ancora nessun commento.