Newsgroup: it.comp.os.linux.sys
Titolo: VPN Vs SSH, quali differenze?

Una curiosita':
che differenza c'e' nella vita pratica fra una connessione VPN e un 
tunnel SSH? Mi e' capitato di usarli entrambi e mi sembra facciano 
grosso modo la stessa cosa, ma mi sembra di vedere che gli utenti win 
preferiscono la VPN mentre quelli linux vanno con ssh.
 
Ci sono dei motivi per preferire una o l'altra? Io preferisco ssh comunque.

 comunque.
 
Sono due strumenti diversi per compiti diversi. Se devi collegarti a più
host con più protocolli certamente la VPN è preferibile e spesso è anche
l'unica scelta. Se la tua necessità è quella di ottenere un terminale su
un host remoto sono indifferenti.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 Dipende da come sono configurati.
 
 
 
ti ringrazio per la spiegazione,
ciao.


ti consiglio di dare una lettura ai tipi di vpn:
 
VPN SSL
VPN IPSEC (net to net, host to net)
VPN PPTP
 
di differenze cen e sono moltissime, in una vpn ipsec definisci 
autonomamente i protocolli di crittografia da utilizzare per entrambe le 
due fasi autenticative, questo può essere molto comodo se hai 
connessioni lente, ad esempio.
con ipsec puoi fare un collegamento tra due sedi in maniera tradizionale 
o hub&spoke, etc..
 
le vpn ssl (i tunnel ssh ne sono un esempio) sono ottimi in caso di 
telelavoratori e vengono spesso utilizzati con dei software frontend via 
webinterface o client della casa madre dell'apparato che fa da 
terminatore. in *genere* sono utilizzate per collegamenti host to net 
perchè molto comode.
 
le vpn pptp stanno gradualmente cadendo in disuso a favore di tecnologie 
più sicure, ma hanno il vantaggio di creare un bridge molto rapidamente 
con la rete di destinazione, una indubbia comodità che le tiene ancora 
in vita proprio per via della semplicità configurativa (e di una 
propensione all'utilizzo in ambiente microsoft server).
 
Insomma, il campo è vasto, questa è giusto una scrematura molto 
approssimativa!
 
Buona lettura!

 di differenze cen e sono moltissime, 
 
[CUT]
 
estendo la domanda, con una cosa che mi interessa particolarmente.
Cosa si può fare, disponendo solo di un proxy http?
 
- teamviewer ha un funzionalità VPN, ma solo nella versione per windows.
- ho visto che si può fare un reverse tunnel SSH, ma bisogna disporre di 
un "gateway" SSH su internet
- stavo guardando adesso "httptunnel"
- Altro???
 
Come fareste voi? Al momento non ho avuto tempo a disposizione e mi sto 
limitanto ad usare teamviewer, che è veramente poco pratico per quello che 
devo fare io.... per trasferire un file devo fare due passaggi, per aprire 
un SSH devo farlo attraverso il display grafico remoto di windows... 
insomma, non mi trovo molto bene.
 
 
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo


 
se devi solo fare qualche transazione ogni tanto puoi fare un tunnel con 
openssh o openssl.
 
poi in genere quasi tutte le soluzioni hanno connotazioni commerciali e 
costicchiamo.
 
Hamachi esiste ancora? potrebbe tornare utile

 Come fareste voi?
 
Io uso openvpn che va da Dio.


Io uso openvpn che va da Dio.
 
E' arrivata fin lassu' l'IPv6?
 
Leonardo
 
-- 
Tell us whether you spy, in the light of the morn,
what saluted was fiercely at the fall of the past day:
whose pips and whose bands in the very heart of the fray
bravely floated from the bulwarks to which we were sworn?


 
Lassù stanno all'IPv8 ed è in draft l'IPv10 :P

 Io uso openvpn che va da Dio.
 
Allora mi metto subito all'opera e vediamo se riesco ad installare il 
tutto, da remoto, con teamviewer.
 
Ma usi openVPN in congiunzione con httptunnel (come mi pare di aver letto 
in giro) o openvpn liscio?


 E' arrivata fin lassu' l'IPv6?
 
Of course (Di corsa, per i non anglofoni).
http://www.greenie.net/ipv6/openvpn.html
 
 
La versione in Debian è già patchata


 in giro) o openvpn liscio?
 
Liscio. Unica cosa openvpn sfrutta il metodo connect, quindi il demone
lato server deve essere in ascolto sulla 443 e il proxy deve consentire
il connect verso Internet. Finora nella pratica non ho mai trovato
nessuno che filtri tale metodo (che bloccherebbe di fatto anche https).
 
Unica accortezza per consentire al demone openvpn di girare con
privilegi non elevati io l'ho messo in ascolto sulla 8443 e ho usato la
redirect di iptables per rigirare i pacchetti sulla 443.


> E' arrivata fin lassu' l'IPv6?
 
Precisazione: ho testato il tunnel con traffico ipv6 al suo interno, ho
fatto qualche esperimento con endpoint ipv6 ma non ho mai provato a
tirare in piedi un tunnel attraverso proxy usando http su IPv6.


 letto in giro) o openvpn liscio?
 
 
mmhh... momento, momentino:
io non ho il client dietro al proxy. Io ho il server dietro al proxy.
Stiamo parlando della stessa cosa ed il problema è solo che io non ci 
capisco nulla di VPN?
Mi pare di capire che se io ho il client dietro ad un proxy, la questione 
è abbastanza semplice.... il contrario invece potrebbe essere un po' 
diverso.


 diverso.
 
Tale e quale.


 Tale e quale.
 
mi spiego in termini semplici, perché sono io - un po' ignorante sulla 
questione - che ho qualche dubbio.
 
- io sono a casa, oppure sono sul treno con il tablet o al ristorante con 
il mio smartphone.
- io devo collegarmi a un PC (e poi a tutta la rete) che è dentro al mio 
ufficio.
- non ho la possibilità di modificare nulla nella rete. L'unica cosa che 
esiste è un proxy http, che fa uscire su internet i PC/server che stanno 
in quella rete.
 
Ti faccio questa domanda, perché ho visto:
- un howto che parlava di utilizzo di httptunnel in congiunzione con 
openvpn
- diversi forum in cui le persone si chiedevano se esisteva uno strumento 
"teamviewer-like", che facesse solo SSH. In questo caso, teamviewer usa un 
gateway
- altri forum dove si suggeriva di usare "jabber-shell": una shell che si 
apre con google talk (jabsh: peccato che è un codice vecchio del 2008 e 
non si compila più con le attuali versioni di librerie).
- altri forum dove veniva suggerita la soluzione del reverse tunnel, con 
un gateway ssh su internet (uno shell server).


 un gateway ssh su internet (uno shell server).
 
Puoi usare quello che vuoi. OpenVPN funziona a patto che la connessione
parta da chi è dietro proxy. Quindi dovrai mettere openvpn in ascolto
sul tuo tablet o sul tuo smartphone e configurare 
p.es
. DynDNS.
 
Ma sono più che convinto che ciò che tu vuoi fare sia contrario alla
policy aziendale e che verrebbe visto come un maldestro tentativo di far
fesso il Sysadmin da punire con giusta durezza.


 fesso il Sysadmin da punire con giusta durezza.
 
In realtà non è così.
C'è una situazione troppo complessa che non posso spiegare, qui e adesso. 
Ti dico solo che il mio tentativo di fornire supporto con teamviewer è 
stato approvato e lodato dal nostro responsabile. 
 
Ti ringrazio per il resto. Credo di essermi chiarito abbastanza.


Mandi! Ale
  In chel dì si favelave...
 
A> Ci sono dei motivi per preferire una o l'altra? Io preferisco ssh comunque.
 
Cipe è morto, pace all'anima sua
 
 
http://sites.inka.de/bigred/devel/cipe.html
 
 
ma questo documento è ancora valido:
 
 
http://sites.inka.de/bigred/devel/tcp-tcp.html
 
 
-- 
  Raramente chi spara cazzate finisce subito le munizioni.
							(Anonimo)

 Cosa si può fare, disponendo solo di un proxy http?
 
Openvpn.

 se hai connessioni lente, ad esempio.
 
Non capisco il nesso tra velocità e scelta degli algoritmi di hashing e di encryption, su due piedi.


tra blowfish 40bit e 3des ci sarà una differenza, no? altrimenti tutti 
utilizzerebbero l'algoritmo più robusto sempre.
 
la maggiore crittografia introduce un indubbio ritardo, che sia questo 
tradotto in un naturale overhead (Header e Trailer aggiuntivi in base al 
protocollo e per ogni pacchetto, è sempre un "peso" aggiuntivo), o che 
sia un limite "elaborativo" il risultato non cambia. Soprattutto il 
secondo fenomeno, su moltissimi apparati, si fa sentire. A tal punto che 
una connessione voip, che notoriamente è sensibile al fenomeno del 
lagging, *può* (con alcuni apparati poco generosi a livello hardware, 
non con tutti per fortuna) girare bene in blowfish ma male in aes256. E' 
pur sempre un ritardo, anche se hardware.
 
Ma è solo un esempio.
Un altro potrebbe essere la scelta dell'algoritmo anche in base alla 
bontà della connessione wan. In casi di connessioni pessime la 
differenza di rapidità nell'instaurare un tunnel ipsec a seguito di una 
microinterruzione può far la differenza tra N sessioni andate giù oppure 
no. E qui ci si sofferma a capire che livello di DH impostare, che 
coppia di algoritmi in phase 1 e che coppia in phase 2 ma, nello 
specifico, anche il lifetime ed un utilizzo corretto del DPD giocano il 
suo ruolo.

 coppia in phase 2 ma, nello specifico, anche il lifetime ed un utilizzo corretto del DPD giocano il suo ruolo.
 
Ribadisco che per sostenere questa tesi occorrerebbe essere almeno un po' quantitativi.
Di che tempi caratteristici staremmo parlando? Tali tempi sono significativi,a  fronte di
latenze di trasmissione nell'ordine di qualche centinaio di millisecondi?
 
Ricordo inoltre che la tua tesi iniziale era che le vpn ipsec sono migliori perché puoi scegliere gli algoritmi.
Beh, puoi farlo tranquillamente anche con openvpn, --auth e --cipher.

 latenze di trasmissione nell'ordine di qualche centinaio di millisecondi?
 
bhè, ad esempio in caso di caduta di un tunnel ipsec, tutta la procedura 
di rinegoziazione che porta un tunnel dallo stato orphaned allo stato 
estabilish (ammesso che il DPD se ne accorga immediatamente):
 
(testato ora con un tunnel tra due sedi)
 
con
ph1 ssha1-aes256 DH16 (4096bit)
ph2 ssha1-aes256 DH16
circa 5-6 secondi
 
con
ph1 ssha1-blowfish40 DH1
ph2 ssha1-blowfish40 DH1
circa 1-2 secondi
 
 
a parità di apparati e banda, ovviamente.
 
è indubbio che serva un maggiore impegno elaborativo. Se dietro hai un 
apparato che mantiene le sessioni in 1-2 secondi l'utilizzatore finale 
non si accorge di nulla. con 5-6 secondi non c'è sistema che tenga, le 
sessioni cadono.
 
 
ma ripeto, è un calcolo ovviamente e naturalmente empirico, ognuno porta 
la sua esperienza frutto anche di storie positive o meno.
 
inoltre, non c'è che dire, gli apparati in questione nella fattispecie 
giocano un ruolo assolutamente importante.
 
 
 
 
ricordo, inoltre, che in caso di protocollo con più bit la parte di 
overhead del pacchetto è maggiore. forse ricordo male, ma se così fosse 
(ne sono abbastanza sicuro, salvo gradite correzioni) un protocollo più 
pesante significherebbe una parte di "data" inferiore, e quindi 
ovviamente una velocità minore nel trasferimento.
 
come dire: se ho 10 tonnellate da spostare con un treno e vado a 100km/h 
ma ho meno vagoni a disposizione rispetto ad un trasferimento in chiaro, 
il treno dovrà fare più viaggi e quindi metterci più tempo.

 correzioni) un protocollo più pesante significherebbe una parte di "data" inferiore, e quindi ovviamente una velocità minore nel trasferimento.
 
Per quel che ricordo, ci sono overhead comuni e inevitabili, dati dai vari header aggiuntivi, più il padding e lì
più che dalla lunghezza della chiave, l'overhead dipende dal blocksize.
Da qualche parte dovrei avere dei pdf di articoli scientifici sul tema, dovrò ripescarli...

 Da qualche parte dovrei avere dei pdf di articoli scientifici sul tema, dovrò ripescarli...
 
magari, sarebbe molto interessante approfondire questo aspetto un po' 
meno noto dei tunnel vpn