Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
vpn per usare un software da remoto
138 views
Skip to first unread message
Ammammata
Jun 21, 2018, 10:17:17 AM6/21/18
to
ordunque, c'è questo windows server 2016 (nome: SERVER) per il gestionale,
roba sql server 2016, con una decina di utenti
dalla rete locale i vari client accedono senza problemi cercando \\SERVER
ora c'è pure un portatile (ma poi saranno anche di più) che dovrebbe
collegarsi da fuori e usare il gestionale di cui sopra
i personaggi del gestionale mi dicono di usare RDP ma poi, dico io, mi
perdo tutte le interazioni con altri programmi installati sul notebook (un
paio di esempi banali: invio un documento in pdf tramite outlook o esporto
una tabella verso excel o un listino verso word o una immagine di prodotto
verso il programma di gestione immagini)
office *non* è installato sul server ma solo sui pc
leggendo qua e là, se si implementasse una vpn, problemi di velocità a
parte - cha magari sono solo teorici e non effettivi, la cosa dovrebbe
funzionare
e qui arriva la domanda:
è meglio attivare la vpn sul server e aprire le necessarie porte sul router
oppure attivare la funzione vpn-peer-to-peer implementata sul router stesso
(un centro business 2.0 di swisscom)? che differenze ci sono? qual è
meglio, considerando che questa vpn dovrebbe servire allo stato attuale
solo ed esclusivamente per l'utilizzo del gestionale?
grazie
ho esposto a grandi linee, se servono altre informazioni ditemi quali
--
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
>>>>> http://www.bb2002.it :) <<<<<
........... [ al lavoro ] ...........
roba sql server 2016, con una decina di utenti
dalla rete locale i vari client accedono senza problemi cercando \\SERVER
ora c'è pure un portatile (ma poi saranno anche di più) che dovrebbe
collegarsi da fuori e usare il gestionale di cui sopra
i personaggi del gestionale mi dicono di usare RDP ma poi, dico io, mi
perdo tutte le interazioni con altri programmi installati sul notebook (un
paio di esempi banali: invio un documento in pdf tramite outlook o esporto
una tabella verso excel o un listino verso word o una immagine di prodotto
verso il programma di gestione immagini)
office *non* è installato sul server ma solo sui pc
leggendo qua e là, se si implementasse una vpn, problemi di velocità a
parte - cha magari sono solo teorici e non effettivi, la cosa dovrebbe
funzionare
e qui arriva la domanda:
è meglio attivare la vpn sul server e aprire le necessarie porte sul router
oppure attivare la funzione vpn-peer-to-peer implementata sul router stesso
(un centro business 2.0 di swisscom)? che differenze ci sono? qual è
meglio, considerando che questa vpn dovrebbe servire allo stato attuale
solo ed esclusivamente per l'utilizzo del gestionale?
grazie
ho esposto a grandi linee, se servono altre informazioni ditemi quali
--
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
>>>>> http://www.bb2002.it :) <<<<<
........... [ al lavoro ] ...........
Skywalker Senior
Jun 21, 2018, 2:37:09 PM6/21/18
to
Nel suo scritto precedente, Ammammata ha sostenuto :
>
> e qui arriva la domanda:
> è meglio attivare la vpn sul server e aprire le necessarie porte sul router
> oppure attivare la funzione vpn-peer-to-peer implementata sul router stesso
> (un centro business 2.0 di swisscom)? che differenze ci sono? qual è
> meglio, considerando che questa vpn dovrebbe servire allo stato attuale
> solo ed esclusivamente per l'utilizzo del gestionale?
>
>
> grazie
> ho esposto a grandi linee, se servono altre informazioni ditemi quali
VPN (scegli tu) + RDP, non ci sono scorciatoie. SQL non è progettato
per funzionare bene via internet. Il gestionale sarebbe lentissimo, al
limite della non usabilità
>
> e qui arriva la domanda:
> è meglio attivare la vpn sul server e aprire le necessarie porte sul router
> oppure attivare la funzione vpn-peer-to-peer implementata sul router stesso
> (un centro business 2.0 di swisscom)? che differenze ci sono? qual è
> meglio, considerando che questa vpn dovrebbe servire allo stato attuale
> solo ed esclusivamente per l'utilizzo del gestionale?
>
>
> grazie
> ho esposto a grandi linee, se servono altre informazioni ditemi quali
per funzionare bene via internet. Il gestionale sarebbe lentissimo, al
limite della non usabilità
Ammammata
Jun 22, 2018, 2:19:11 AM6/22/18
to
Il giorno Thu 21 Jun 2018 08:37:05p, *Skywalker Senior* ha inviato su
it.comp.reti.locali il messaggio news:pggr8i$svd$1...@gioia.aioe.org. Vediamo
cosa ha scritto:
> SQL non è progettato
> per funzionare bene via internet. Il gestionale sarebbe lentissimo, al
> limite della non usabilità
>
hai sottomano un link dove spieghino pr benino questa cosa, con magari
qualche esempio pratico?
mi dicono che la mole di dati non è quella di una compagnia telefonica con
milioni di utenti e miliardi di transazioni, sono tabelle con max 5000
record, i dati nel loro complesso non arrivano a più di 150MB totali
it.comp.reti.locali il messaggio news:pggr8i$svd$1...@gioia.aioe.org. Vediamo
cosa ha scritto:
> SQL non è progettato
> per funzionare bene via internet. Il gestionale sarebbe lentissimo, al
> limite della non usabilità
>
qualche esempio pratico?
mi dicono che la mole di dati non è quella di una compagnia telefonica con
milioni di utenti e miliardi di transazioni, sono tabelle con max 5000
record, i dati nel loro complesso non arrivano a più di 150MB totali
Skywalker Senior
Jun 22, 2018, 4:03:35 AM6/22/18
to
Ammammata scriveva il 22/06/2018 :
perché non è pensato per essere usato da remoto. Si possono eseguire
degli interventi su alcuni parametri della rete (l'MTU ad esempio, ma
non chiedermi come), in modo da aumentare la dimensione dei pacchetti
trasmessi.
Io ho solo esperienze personali, anche con database relativamente
piccoli, le prestazioni erano imbarazzanti e spesso il programma andava
in errore per mancata risposta del database. Poi, magari, se si ha una
connessione veloce, può anche funzionare meglio.
Nel caso, le porte da aprire sono la 1433 e 1434
> Il giorno Thu 21 Jun 2018 08:37:05p, *Skywalker Senior* ha inviato su
> it.comp.reti.locali il messaggio news:pggr8i$svd$1...@gioia.aioe.org. Vediamo
> cosa ha scritto:
>
>> SQL non è progettato
>> per funzionare bene via internet. Il gestionale sarebbe lentissimo, al
>> limite della non usabilità
>>
>
> hai sottomano un link dove spieghino pr benino questa cosa, con magari
> qualche esempio pratico?
>
> mi dicono che la mole di dati non è quella di una compagnia telefonica con
> milioni di utenti e miliardi di transazioni, sono tabelle con max 5000
> record, i dati nel loro complesso non arrivano a più di 150MB totali
Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
> it.comp.reti.locali il messaggio news:pggr8i$svd$1...@gioia.aioe.org. Vediamo
> cosa ha scritto:
>
>> SQL non è progettato
>> per funzionare bene via internet. Il gestionale sarebbe lentissimo, al
>> limite della non usabilità
>>
>
> hai sottomano un link dove spieghino pr benino questa cosa, con magari
> qualche esempio pratico?
>
> mi dicono che la mole di dati non è quella di una compagnia telefonica con
> milioni di utenti e miliardi di transazioni, sono tabelle con max 5000
> record, i dati nel loro complesso non arrivano a più di 150MB totali
perché non è pensato per essere usato da remoto. Si possono eseguire
degli interventi su alcuni parametri della rete (l'MTU ad esempio, ma
non chiedermi come), in modo da aumentare la dimensione dei pacchetti
trasmessi.
Io ho solo esperienze personali, anche con database relativamente
piccoli, le prestazioni erano imbarazzanti e spesso il programma andava
in errore per mancata risposta del database. Poi, magari, se si ha una
connessione veloce, può anche funzionare meglio.
Nel caso, le porte da aprire sono la 1433 e 1434
ObiWan
Jun 22, 2018, 5:08:55 AM6/22/18
to
It was Thu, 21 Jun 2018 14:17:15 +0000 (UTC) when
(es. PPTP) e senza installare nulla, oppure puoi usare il supporto VPN
del router (da vedere se in quel caso dovrai installare qualcosa sul
laptop); in qualsiasi caso, in quel modo avrai accesso a "\\SERVER"
come se fossi in rete, anche se ovviamente con prestazioni inferiori
dovute alla banda disponibile per il link internet
Considerando che mettere in piedi una VPN non ti costa nulla, credo sia
il caso di fare una prova, valutare le prestazioni e poi decidere se
siano accettabili o meno
Per quanto riguarda il mettere in piedi la VPN, leggi qui
https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-server-2016/
ciao :)
Ammammata <amma...@tiscalinet.it> wrote:
> ordunque, c'è questo windows server 2016 (nome: SERVER) per il
> gestionale, roba sql server 2016, con una decina di utenti
>
> dalla rete locale i vari client accedono senza problemi cercando
> \\SERVER
>
> ora c'è pure un portatile (ma poi saranno anche di più) che dovrebbe
> collegarsi da fuori e usare il gestionale di cui sopra
>
> i personaggi del gestionale mi dicono di usare RDP ma poi, dico io,
> mi perdo tutte le interazioni con altri programmi installati sul
> notebook (un paio di esempi banali: invio un documento in pdf tramite
> outlook o esporto una tabella verso excel o un listino verso word o
> una immagine di prodotto verso il programma di gestione immagini)
Usa una VPN, puoi implementarla usando il supporto nativo di windows
> ordunque, c'è questo windows server 2016 (nome: SERVER) per il
> gestionale, roba sql server 2016, con una decina di utenti
>
> dalla rete locale i vari client accedono senza problemi cercando
> \\SERVER
>
> ora c'è pure un portatile (ma poi saranno anche di più) che dovrebbe
> collegarsi da fuori e usare il gestionale di cui sopra
>
> i personaggi del gestionale mi dicono di usare RDP ma poi, dico io,
> mi perdo tutte le interazioni con altri programmi installati sul
> notebook (un paio di esempi banali: invio un documento in pdf tramite
> outlook o esporto una tabella verso excel o un listino verso word o
> una immagine di prodotto verso il programma di gestione immagini)
(es. PPTP) e senza installare nulla, oppure puoi usare il supporto VPN
del router (da vedere se in quel caso dovrai installare qualcosa sul
laptop); in qualsiasi caso, in quel modo avrai accesso a "\\SERVER"
come se fossi in rete, anche se ovviamente con prestazioni inferiori
dovute alla banda disponibile per il link internet
Considerando che mettere in piedi una VPN non ti costa nulla, credo sia
il caso di fare una prova, valutare le prestazioni e poi decidere se
siano accettabili o meno
Per quanto riguarda il mettere in piedi la VPN, leggi qui
https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-server-2016/
ciao :)
Andrea B.
Jun 22, 2018, 5:25:56 AM6/22/18
to
Il 21/06/2018 16:17, Ammammata ha scritto:
> i personaggi del gestionale mi dicono di usare RDP ma poi, dico io, mi
> perdo tutte le interazioni con altri programmi installati sul notebook (un
> paio di esempi banali: invio un documento in pdf tramite outlook o esporto
> una tabella verso excel o un listino verso word o una immagine di prodotto
> verso il programma di gestione immagini)
>
> office *non* è installato sul server ma solo sui pc
RDP supporta copia/incolla clipboard e file locale/remoto.
> i personaggi del gestionale mi dicono di usare RDP ma poi, dico io, mi
> perdo tutte le interazioni con altri programmi installati sul notebook (un
> paio di esempi banali: invio un documento in pdf tramite outlook o esporto
> una tabella verso excel o un listino verso word o una immagine di prodotto
> verso il programma di gestione immagini)
>
> office *non* è installato sul server ma solo sui pc
Dai retta a quelli del gestionale.
Mirko Borsari
Jun 22, 2018, 6:01:06 AM6/22/18
to
Il Thu, 21 Jun 2018 14:17:15 +0000 (UTC), Ammammata ha scritto:
> i personaggi del gestionale mi dicono di usare RDP ma poi, dico io, mi
> perdo tutte le interazioni con altri programmi installati sul notebook (un
> paio di esempi banali: invio un documento in pdf tramite outlook o esporto
> una tabella verso excel o un listino verso word o una immagine di prodotto
> verso il programma di gestione immagini)
alla fine con la possibilità di reindirizzare le risorse forse non è
> i personaggi del gestionale mi dicono di usare RDP ma poi, dico io, mi
> perdo tutte le interazioni con altri programmi installati sul notebook (un
> paio di esempi banali: invio un documento in pdf tramite outlook o esporto
> una tabella verso excel o un listino verso word o una immagine di prodotto
> verso il programma di gestione immagini)
neanche così scomodo.
Io per fare le cose più semplici possibili uso il gestionale via RDP e
poi salvo in una cartella sincronizzata via internet tra server e pc.
Dipende molto dalla banda che c'è a disposizione.
> leggendo qua e là, se si implementasse una vpn, problemi di velocità a
> parte - cha magari sono solo teorici e non effettivi, la cosa dovrebbe
> funzionare
Se hai molta banda puoi anche pensare di usare il client locale su
VPN, ma preferisco sempre l'RDP. Eviti anche che in caso di
disconnessione si rimanga appesi.
> e qui arriva la domanda:
> è meglio attivare la vpn sul server e aprire le necessarie porte sul router
> oppure attivare la funzione vpn-peer-to-peer implementata sul router stesso
vieta di farlo direttamente dal server.
--
MirkoB. ne...@bsi-net.it
Motoretta BMW R1200R Lightgrey
L'indirizzo ema@il non è da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente
Ammammata
Jun 22, 2018, 6:17:59 AM6/22/18
to
Il giorno Fri 22 Jun 2018 10:03:30a, *Skywalker Senior* ha inviato su
it.comp.reti.locali il messaggio news:pgiagk$12ea$1...@gioia.aioe.org. Vediamo
cosa ha scritto:
> Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
> perché non è pensato per essere usato da remoto.
ohibò :/
il gestionale vecchio era un falso server/client in quanto nel momento in
cui p.e. veniva chiesta una stampa di elenco fatture con determinate scelte
il software sul client leggeva *tutto* il file e tutti i collegamenti
necessari (anagrafiche clienti, prodotti, tabelle varie, eccetera)
filtrando i dati, e solo alla fine mostrava il risultato, magari solo due
righe: un traffico di rete notevole soprattutto per i client collegati in
wireless, centinaia di MB a fronte di due righe di stampa
questo nuovo lo hanno venduto come un essere _intelligente_ : il cliente
dice mi serve questo e quello, il server elabora in loco questo e quello (e
sbggrfrtn se deve passarsi qualche centinaio di MB di dati) e alla fine
restituisce le poche righe che ha trovato: diciamo pochi kappa per la
richiesta e ancor meno per la risposta... non vedo (teoricamente) tutto sto
gran traffico di cui mi parli
ho partecipato alla preparazione delle query, lo sviluppatore ha sempre
messo a fuoco la preparazione *completa* dei dati al momento della
richiesta, evitando sempre eventuali ulteriori richieste in fase di stampa
(che come dici tu avrebbero causato un traffico aggiuntivo di dati, a
questo punto incontrollabile)
cmq, come hanno risposto in altri punti del 3ad, faremo queste prove "per
vedere che effetto che fa"
e grazie per le risposte e il tempo che mi hai dedicato :)
it.comp.reti.locali il messaggio news:pgiagk$12ea$1...@gioia.aioe.org. Vediamo
cosa ha scritto:
> Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
> perché non è pensato per essere usato da remoto.
il gestionale vecchio era un falso server/client in quanto nel momento in
cui p.e. veniva chiesta una stampa di elenco fatture con determinate scelte
il software sul client leggeva *tutto* il file e tutti i collegamenti
necessari (anagrafiche clienti, prodotti, tabelle varie, eccetera)
filtrando i dati, e solo alla fine mostrava il risultato, magari solo due
righe: un traffico di rete notevole soprattutto per i client collegati in
wireless, centinaia di MB a fronte di due righe di stampa
questo nuovo lo hanno venduto come un essere _intelligente_ : il cliente
dice mi serve questo e quello, il server elabora in loco questo e quello (e
sbggrfrtn se deve passarsi qualche centinaio di MB di dati) e alla fine
restituisce le poche righe che ha trovato: diciamo pochi kappa per la
richiesta e ancor meno per la risposta... non vedo (teoricamente) tutto sto
gran traffico di cui mi parli
ho partecipato alla preparazione delle query, lo sviluppatore ha sempre
messo a fuoco la preparazione *completa* dei dati al momento della
richiesta, evitando sempre eventuali ulteriori richieste in fase di stampa
(che come dici tu avrebbero causato un traffico aggiuntivo di dati, a
questo punto incontrollabile)
cmq, come hanno risposto in altri punti del 3ad, faremo queste prove "per
vedere che effetto che fa"
e grazie per le risposte e il tempo che mi hai dedicato :)
Ammammata
Jun 22, 2018, 6:36:11 AM6/22/18
to
Il giorno Fri 22 Jun 2018 11:25:48a, *Andrea B.* ha inviato su
it.comp.reti.locali il messaggio news:pgifb3$1aoc$1...@gioia.aioe.org. Vediamo
cosa ha scritto:
>> office *non* è installato sul server ma solo sui pc
>
> RDP supporta copia/incolla clipboard e file locale/remoto.
> Dai retta a quelli del gestionale.
>
passi il copia/incolla dal gestionale a excel/word (ma a questo punto
chiederanno perchè hanno speso soldi per avere il pulsantino se devono fare
ancora a mano come prima), ma per inviare allegati per posta la procedura
manuale anteprimadistampa-salvainpdfsulserver-iniziaunamailsulcliente-
vaacercareilpdfeallegalo-inserisciildestinatario-compilaloggetto-
scrividuerigheditesto fatta ancora col vecchio metodo... sento già le
madonne e i santi per aver buttato via i soldi :(
no, quelli del gestionale lo hanno venduto come fattibile, lo sapevano fin
dall'inizio che avrebbe dovuto funzionare così e non cosà, mo' son pnmmv
loro, carta canta e villan non dorme
it.comp.reti.locali il messaggio news:pgifb3$1aoc$1...@gioia.aioe.org. Vediamo
cosa ha scritto:
>> office *non* è installato sul server ma solo sui pc
>
> RDP supporta copia/incolla clipboard e file locale/remoto.
> Dai retta a quelli del gestionale.
>
chiederanno perchè hanno speso soldi per avere il pulsantino se devono fare
ancora a mano come prima), ma per inviare allegati per posta la procedura
manuale anteprimadistampa-salvainpdfsulserver-iniziaunamailsulcliente-
vaacercareilpdfeallegalo-inserisciildestinatario-compilaloggetto-
scrividuerigheditesto fatta ancora col vecchio metodo... sento già le
madonne e i santi per aver buttato via i soldi :(
no, quelli del gestionale lo hanno venduto come fattibile, lo sapevano fin
dall'inizio che avrebbe dovuto funzionare così e non cosà, mo' son pnmmv
loro, carta canta e villan non dorme
Ammammata
Jun 22, 2018, 6:36:25 AM6/22/18
to
Il giorno Fri 22 Jun 2018 11:08:54a, *ObiWan* ha inviato su
it.comp.reti.locali il messaggio
appena posso metto in pratica
it.comp.reti.locali il messaggio
news:20180622110...@albasani.net. Vediamo cosa ha scritto:
> Per quanto riguarda il mettere in piedi la VPN, leggi qui
>
> https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-serve
> r-2016/
>
>
link già visto, grazie
> Per quanto riguarda il mettere in piedi la VPN, leggi qui
>
> https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-serve
> r-2016/
>
>
appena posso metto in pratica
Ammammata
Jun 22, 2018, 6:41:47 AM6/22/18
to
Il giorno Fri 22 Jun 2018 12:01:01p, *Mirko Borsari* ha inviato su
it.comp.reti.locali il messaggio news:1uw7fe6iieu6g$.dlg@mirkonews.bsi-
net.it. Vediamo cosa ha scritto:
> la VPN è obbligatoria, poi sopra ci fai passare RDP al limite.
cosa significa?
che il programma si blocca e mi fotte tutto il sistema windows?
che il programma si chiude e non posso ricollegarmi se prima qualcun'altro
non va sul server a chiudere a mano la connessione?
che altro che non mi viene in mente?
it.comp.reti.locali il messaggio news:1uw7fe6iieu6g$.dlg@mirkonews.bsi-
net.it. Vediamo cosa ha scritto:
> la VPN è obbligatoria, poi sopra ci fai passare RDP al limite.
> Eviti anche che in caso di
> disconnessione si rimanga appesi.
>
che in termini che posso spiegare a una persona senza le tue conoscenze
> disconnessione si rimanga appesi.
>
cosa significa?
che il programma si blocca e mi fotte tutto il sistema windows?
che il programma si chiude e non posso ricollegarmi se prima qualcun'altro
non va sul server a chiudere a mano la connessione?
che altro che non mi viene in mente?
Andromeda
Jun 22, 2018, 8:35:49 AM6/22/18
to
Il 22/06/2018 11:25, Andrea B. ha scritto:
> RDP supporta copia/incolla clipboard e file locale/remoto.
> Dai retta a quelli del gestionale.
Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere
> RDP supporta copia/incolla clipboard e file locale/remoto.
> Dai retta a quelli del gestionale.
superflua nel secondo no.
--
Mai mettersi a discutere con un idiota:
- prima ti porta al suo livello e poi ti batte con l'esperienza;
- chi ascolta potrebbe non capire la differenza.
ObiWan
Jun 22, 2018, 10:22:05 AM6/22/18
to
It was Fri, 22 Jun 2018 10:36:24 +0000 (UTC) when
non ho capito, SQL Server sta su "server", ma
l'applicativo che accede ai dati, è installato sui
vari client o cosa ?
Nel primo caso (sui client) se l'applicativo è fatto
bene, non vedo problemi nell'utilizzarlo da remoto
tramite VPN
Ammammata <amma...@tiscalinet.it> wrote:
> Il giorno Fri 22 Jun 2018 11:08:54a, *ObiWan* ha
> inviato su it.comp.reti.locali il messaggio
> news:20180622110...@albasani.net. Vediamo
> cosa ha scritto:
>
> > Per quanto riguarda il mettere in piedi la VPN,
> > leggi qui
> >
> > https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-server-2016/
> link già visto, grazie
> appena posso metto in pratica
fai una prova, verifica la velocità e via; una cosa
> Il giorno Fri 22 Jun 2018 11:08:54a, *ObiWan* ha
> inviato su it.comp.reti.locali il messaggio
> news:20180622110...@albasani.net. Vediamo
> cosa ha scritto:
>
> > Per quanto riguarda il mettere in piedi la VPN,
> > leggi qui
> >
> > https://www.thomasmaurer.ch/2016/10/how-to-install-vpn-on-windows-server-2016/
> link già visto, grazie
> appena posso metto in pratica
non ho capito, SQL Server sta su "server", ma
l'applicativo che accede ai dati, è installato sui
vari client o cosa ?
Nel primo caso (sui client) se l'applicativo è fatto
bene, non vedo problemi nell'utilizzarlo da remoto
tramite VPN
Mirko Borsari
Jun 22, 2018, 10:37:52 AM6/22/18
to
Il Fri, 22 Jun 2018 10:41:46 +0000 (UTC), Ammammata ha scritto:
>> la VPN è obbligatoria, poi sopra ci fai passare RDP al limite.
>> Eviti anche che in caso di
>> disconnessione si rimanga appesi.
>>
>
> che in termini che posso spiegare a una persona senza le tue conoscenze
> cosa significa?
>
> che il programma si blocca e mi fotte tutto il sistema windows?
> che il programma si chiude e non posso ricollegarmi se prima qualcun'altro
> non va sul server a chiudere a mano la connessione?
> che altro che non mi viene in mente?
dipende da come è fatto il software. di solito succede la seconda.
>> la VPN è obbligatoria, poi sopra ci fai passare RDP al limite.
>> Eviti anche che in caso di
>> disconnessione si rimanga appesi.
>>
>
> che in termini che posso spiegare a una persona senza le tue conoscenze
> cosa significa?
>
> che il programma si blocca e mi fotte tutto il sistema windows?
> che il programma si chiude e non posso ricollegarmi se prima qualcun'altro
> non va sul server a chiudere a mano la connessione?
> che altro che non mi viene in mente?
Valerio Vanni
Jun 22, 2018, 5:16:28 PM6/22/18
to
On Fri, 22 Jun 2018 10:03:30 +0200, Skywalker Senior
<s...@SPAMMATUAMAMMA.com> wrote:
>
>Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
>perché non è pensato per essere usato da remoto. Si possono eseguire
>degli interventi su alcuni parametri della rete (l'MTU ad esempio, ma
>non chiedermi come), in modo da aumentare la dimensione dei pacchetti
>trasmessi.
>Io ho solo esperienze personali, anche con database relativamente
>piccoli, le prestazioni erano imbarazzanti e spesso il programma andava
>in errore per mancata risposta del database.
Ho lo stesso ricordo anch'io, di una prova fatta una decina d'anni fa:
<s...@SPAMMATUAMAMMA.com> wrote:
>
>Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
>perché non è pensato per essere usato da remoto. Si possono eseguire
>degli interventi su alcuni parametri della rete (l'MTU ad esempio, ma
>non chiedermi come), in modo da aumentare la dimensione dei pacchetti
>trasmessi.
>Io ho solo esperienze personali, anche con database relativamente
>piccoli, le prestazioni erano imbarazzanti e spesso il programma andava
>in errore per mancata risposta del database.
era lontanissimo dal concetto di "usabile".
--
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.
acc
Jun 22, 2018, 5:51:16 PM6/22/18
to
Il 22/06/2018 10.03, Skywalker Senior ha scritto:
> Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
> perché non è pensato per essere usato da remoto.
A me risulta l'esatto contrario, tant'e' vero che e' pratica comune
> Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
> perché non è pensato per essere usato da remoto.
avere server SQL e client su macchine diverse.
Magari e' il programma che e' fatto male e fa query enormi senza motivo,
ma se e' cosi' non e' colpa del database.
--
I'm not anti-social;
I'm just not user friendly
Valerio Vanni
Jun 22, 2018, 9:19:54 PM6/22/18
to
On Fri, 22 Jun 2018 23:52:04 +0200, acc <em...@farlocca.it> wrote:
>> Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
>> perché non è pensato per essere usato da remoto.
>
>A me risulta l'esatto contrario, tant'e' vero che e' pratica comune
>avere server SQL e client su macchine diverse.
Qui per "da remoto" si intende passare per un'ADSL o un collegamento
>> Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
>> perché non è pensato per essere usato da remoto.
>
>A me risulta l'esatto contrario, tant'e' vero che e' pratica comune
>avere server SQL e client su macchine diverse.
3G.
>Magari e' il programma che e' fatto male e fa query enormi senza motivo,
>ma se e' cosi' non e' colpa del database.
acc
Jun 23, 2018, 6:30:35 AM6/23/18
to
Il 23/06/2018 3.19, Valerio Vanni ha scritto:
> Qui per "da remoto" si intende passare per un'ADSL o un collegamento
> 3G.
Cioe' per un canale piu' lento, esattamente come avviene in ambito LAN.
> Qui per "da remoto" si intende passare per un'ADSL o un collegamento
> 3G.
Ammammata
Jun 25, 2018, 2:27:32 AM6/25/18
to
Il giorno Fri 22 Jun 2018 04:22:04p, *ObiWan* ha inviato su
it.comp.reti.locali il messaggio news:20180622162...@albasani.net.
Vediamo cosa ha scritto:
> una cosa
> non ho capito, SQL Server sta su "server", ma
> l'applicativo che accede ai dati, è installato sui
> vari client o cosa ?
>
> Nel primo caso (sui client) se l'applicativo è fatto
> bene, non vedo problemi nell'utilizzarlo da remoto
> tramite VPN
>
>
sul server c'è il database e sql server e il programma "grosso"
poi ci sono i client, con il loro programmino appunto client, che in teoria
(cioé come la hanno venduta) manda una query al server che la elabora e
restituisce i risultati: il grosso del lavoro lo fa il server, le
interrogazioni, fatte bene, non chiedono (spero) mai di avere in risposta
milioni di righe: nessuno si mette a controllare a mano anche solo
centinaia di righe, si guardano i totali prima e si scende nel dettaglio
dopo aver individuato dove sta il problema per cui il traffico in arrivo
dal server è sempre molto limitato
it.comp.reti.locali il messaggio news:20180622162...@albasani.net.
Vediamo cosa ha scritto:
> una cosa
> non ho capito, SQL Server sta su "server", ma
> l'applicativo che accede ai dati, è installato sui
> vari client o cosa ?
>
> Nel primo caso (sui client) se l'applicativo è fatto
> bene, non vedo problemi nell'utilizzarlo da remoto
> tramite VPN
>
>
poi ci sono i client, con il loro programmino appunto client, che in teoria
(cioé come la hanno venduta) manda una query al server che la elabora e
restituisce i risultati: il grosso del lavoro lo fa il server, le
interrogazioni, fatte bene, non chiedono (spero) mai di avere in risposta
milioni di righe: nessuno si mette a controllare a mano anche solo
centinaia di righe, si guardano i totali prima e si scende nel dettaglio
dopo aver individuato dove sta il problema per cui il traffico in arrivo
dal server è sempre molto limitato
Skywalker Senior
Jun 25, 2018, 3:43:41 AM6/25/18
to
Sembra che acc abbia detto :
allora forse non si noterebbe la differenza con una LAN (che, male che
vada, è una 100 Mb full duplex), ma se parliamo di ADSL "classiche" (20
Mb in DL lato client e 2 Mb in UL lato server) allora non va più tanto
bene.
Poi, per carità, se il DB è progettato bene e, come si diceva, le query
sono "razionali", magari si può usare anche così.
> Il 23/06/2018 3.19, Valerio Vanni ha scritto:
>
>> Qui per "da remoto" si intende passare per un'ADSL o un collegamento
>> 3G.
>
> Cioe' per un canale piu' lento, esattamente come avviene in ambito LAN.
Forse avendo una linea recente (fibra) sia lato server che lato client,
>
>> Qui per "da remoto" si intende passare per un'ADSL o un collegamento
>> 3G.
>
> Cioe' per un canale piu' lento, esattamente come avviene in ambito LAN.
allora forse non si noterebbe la differenza con una LAN (che, male che
vada, è una 100 Mb full duplex), ma se parliamo di ADSL "classiche" (20
Mb in DL lato client e 2 Mb in UL lato server) allora non va più tanto
bene.
Poi, per carità, se il DB è progettato bene e, come si diceva, le query
sono "razionali", magari si può usare anche così.
Skywalker Senior
Jun 25, 2018, 3:47:25 AM6/25/18
to
Nel suo scritto precedente, Andromeda ha sostenuto :
> Il 22/06/2018 11:25, Andrea B. ha scritto:
>> RDP supporta copia/incolla clipboard e file locale/remoto.
>> Dai retta a quelli del gestionale.
>
> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere superflua
> nel secondo no.
Nno è mai saggio esporre direttamente una macchina in RDP
>> RDP supporta copia/incolla clipboard e file locale/remoto.
>> Dai retta a quelli del gestionale.
>
> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere superflua
> nel secondo no.
Andromeda
Jun 25, 2018, 3:53:48 AM6/25/18
to
in internet.
Sono intervenuto sperando in una risposta come la tua e... è arrivata ;-)
Mirko Borsari
Jun 25, 2018, 4:32:13 AM6/25/18
to
Il Mon, 25 Jun 2018 09:53:46 +0200, Andromeda ha scritto:
>>> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere
>>> superflua nel secondo no.
>>
>> Nno è mai saggio esporre direttamente una macchina in RDP
>
> Ne sono straconvinto ma mi scontro sempre con gente che va di RDP liscio
> in internet.
bhe però bisogna vedere se è veramente liscio...
>>> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere
>>> superflua nel secondo no.
>>
>> Nno è mai saggio esporre direttamente una macchina in RDP
>
> Ne sono straconvinto ma mi scontro sempre con gente che va di RDP liscio
> in internet.
perchè se è blindato per accettare connessioni solo da determinati IP,
la cosa cambia.
Skywalker Senior
Jun 25, 2018, 5:48:44 AM6/25/18
to
Il 25/06/2018, Mirko Borsari ha detto :
standard e, soprattutto, origini prefissate) diventa un po' più sicuro
> Il Mon, 25 Jun 2018 09:53:46 +0200, Andromeda ha scritto:
>
>
>>>> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere
>>>> superflua nel secondo no.
>>>
>>> Nno è mai saggio esporre direttamente una macchina in RDP
>>
>> Ne sono straconvinto ma mi scontro sempre con gente che va di RDP liscio
>> in internet.
>
> bhe però bisogna vedere se è veramente liscio...
> perchè se è blindato per accettare connessioni solo da determinati IP,
> la cosa cambia.
Si, diciamo che aggiungendo un paio di accorgimenti (cambio porta
>
>
>>>> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere
>>>> superflua nel secondo no.
>>>
>>> Nno è mai saggio esporre direttamente una macchina in RDP
>>
>> Ne sono straconvinto ma mi scontro sempre con gente che va di RDP liscio
>> in internet.
>
> bhe però bisogna vedere se è veramente liscio...
> perchè se è blindato per accettare connessioni solo da determinati IP,
> la cosa cambia.
standard e, soprattutto, origini prefissate) diventa un po' più sicuro
Valerio Vanni
Jun 25, 2018, 6:27:58 AM6/25/18
to
On Mon, 25 Jun 2018 09:43:39 +0200, Skywalker Senior
<s...@SPAMMATUAMAMMA.com> wrote:
>Forse avendo una linea recente (fibra) sia lato server che lato client,
>allora forse non si noterebbe la differenza con una LAN (che, male che
>vada, è una 100 Mb full duplex), ma se parliamo di ADSL "classiche" (20
>Mb in DL lato client e 2 Mb in UL lato server) allora non va più tanto
>bene.
Con la fibra potrebbe diventare usabile. La mia prova risale a diversi
<s...@SPAMMATUAMAMMA.com> wrote:
>Forse avendo una linea recente (fibra) sia lato server che lato client,
>allora forse non si noterebbe la differenza con una LAN (che, male che
>vada, è una 100 Mb full duplex), ma se parliamo di ADSL "classiche" (20
>Mb in DL lato client e 2 Mb in UL lato server) allora non va più tanto
>bene.
anni fa, e gli upload erano a 512 kbps (in pratica il canale vpn era
una 512 simmetrica). E andava così male che era fuori luogo che
parlare di lentezza era un complimentone.
>Poi, per carità, se il DB è progettato bene e, come si diceva, le query
>sono "razionali", magari si può usare anche così.
acc
Jun 25, 2018, 9:15:17 AM6/25/18
to
Il 25/06/2018 9.43, Skywalker Senior ha scritto:
> Forse avendo una linea recente (fibra) sia lato server che lato client,
> allora forse non si noterebbe la differenza con una LAN (che, male che
> vada, è una 100 Mb full duplex), ma se parliamo di ADSL "classiche" (20
> Mb in DL lato client e 2 Mb in UL lato server) allora non va più tanto
> bene.
> Poi, per carità, se il DB è progettato bene e, come si diceva, le query
> sono "razionali", magari si può usare anche così.
Davvero vorresti convincermi che una LAN e' piu' veloce di una ADSL?
> Forse avendo una linea recente (fibra) sia lato server che lato client,
> allora forse non si noterebbe la differenza con una LAN (che, male che
> vada, è una 100 Mb full duplex), ma se parliamo di ADSL "classiche" (20
> Mb in DL lato client e 2 Mb in UL lato server) allora non va più tanto
> bene.
> Poi, per carità, se il DB è progettato bene e, come si diceva, le query
> sono "razionali", magari si può usare anche così.
La luna non il dito!
ObiWan
Jun 25, 2018, 11:04:16 AM6/25/18
to
:: On Mon, 25 Jun 2018 06:27:31 +0000 (UTC)
:: (it.comp.reti.locali)
:: <XnsA90C560BF3644am...@148.251.67.112>
classico applicativo a tre strati; data, business e presentation, in
pratica il data layer è SQL server, il business layer è quello che tu
chiami "programma grosso", mentre il presentation layer è la parte che
viene installata sui client e che, in un'architettura del genere, di
norma, dialoga con il business layer (e quest'ultimo, a sua volta
dialoga con il data layer); niente di che, ovvio che dipende da come il
tutto è stato messo in piedi
> elabora e restituisce i risultati: il grosso del lavoro lo fa il
> server, le interrogazioni, fatte bene, non chiedono (spero) mai di
in teoria si, in pratica, ho visto anche delle immani porcate, ad
esempio, nel caso di parti dell'applicativo che permettevano di fare
"browsing" di dati, tabulandoli, un'applicazione scritta bene, farebbe
paginazione lato server, ritornando al client solo i dati relativi alla
pagina corrente, una fatta MALE, potrebbe anche ritornare al client
TUTTI i dati lasciando che sia il client a paginare ... immagina cosa
succede se i records sono dell'ordine di migliaia o più :P
Ad ogni modo, se l'applicazione è scritta bene, potrebbe esserti
sufficiente anche una /semplice/ connessione VPN, in quel caso basterà
assicurarsi che il "puntamento" della parte client verso il server sia
sempre corretto e dovrebbe funzionare tutto; ovviamente, la velocità
sarà direttamente correlata alla banda "internet" disponibile, ma, come
ti ho scritto, considerando che fare una prova in merito non ti costerà
nulla, credo valga la pena procedere in tal senso
ciao
:: (it.comp.reti.locali)
:: <XnsA90C560BF3644am...@148.251.67.112>
:: Ammammata <amma...@tiscalinet.it> wrote:
> sul server c'è il database e sql server e il programma "grosso"
> poi ci sono i client, con il loro programmino appunto client, che in
> teoria (cioé come la hanno venduta) manda una query al server che la
Ok, ammesso e non concesso che io abbia capito, si tratterebbe del
> sul server c'è il database e sql server e il programma "grosso"
> poi ci sono i client, con il loro programmino appunto client, che in
> teoria (cioé come la hanno venduta) manda una query al server che la
classico applicativo a tre strati; data, business e presentation, in
pratica il data layer è SQL server, il business layer è quello che tu
chiami "programma grosso", mentre il presentation layer è la parte che
viene installata sui client e che, in un'architettura del genere, di
norma, dialoga con il business layer (e quest'ultimo, a sua volta
dialoga con il data layer); niente di che, ovvio che dipende da come il
tutto è stato messo in piedi
> elabora e restituisce i risultati: il grosso del lavoro lo fa il
> server, le interrogazioni, fatte bene, non chiedono (spero) mai di
esempio, nel caso di parti dell'applicativo che permettevano di fare
"browsing" di dati, tabulandoli, un'applicazione scritta bene, farebbe
paginazione lato server, ritornando al client solo i dati relativi alla
pagina corrente, una fatta MALE, potrebbe anche ritornare al client
TUTTI i dati lasciando che sia il client a paginare ... immagina cosa
succede se i records sono dell'ordine di migliaia o più :P
Ad ogni modo, se l'applicazione è scritta bene, potrebbe esserti
sufficiente anche una /semplice/ connessione VPN, in quel caso basterà
assicurarsi che il "puntamento" della parte client verso il server sia
sempre corretto e dovrebbe funzionare tutto; ovviamente, la velocità
sarà direttamente correlata alla banda "internet" disponibile, ma, come
ti ho scritto, considerando che fare una prova in merito non ti costerà
nulla, credo valga la pena procedere in tal senso
ciao
Ammammata
Jun 25, 2018, 11:21:07 AM6/25/18
to
Il giorno Mon 25 Jun 2018 12:27:55p, *Valerio Vanni* ha inviato su
it.comp.reti.locali il messaggio
news:0ng1jd5l8424k45rn...@4ax.com. Vediamo cosa ha scritto:
> La mia prova risale a diversi
> anni fa, e gli upload erano a 512 kbps
qui si viaggia VDSL 100/20 mega, la fibra gigabit 1000/1000 è alle porte
del comune e la porteranno da noi in tempi relativamente rapidi
it.comp.reti.locali il messaggio
news:0ng1jd5l8424k45rn...@4ax.com. Vediamo cosa ha scritto:
> La mia prova risale a diversi
> anni fa, e gli upload erano a 512 kbps
del comune e la porteranno da noi in tempi relativamente rapidi
Mirko Borsari
Jun 25, 2018, 11:45:31 AM6/25/18
to
Lorenz
Jun 25, 2018, 12:59:43 PM6/25/18
to
Ammammata ci ha detto :
> Il giorno Mon 25 Jun 2018 12:27:55p, *Valerio Vanni* ha inviato su
> it.comp.reti.locali il messaggio
> news:0ng1jd5l8424k45rn...@4ax.com. Vediamo cosa ha scritto:
>
>> La mia prova risale a diversi
>> anni fa, e gli upload erano a 512 kbps
>
> qui si viaggia VDSL 100/20 mega, la fibra gigabit 1000/1000 è alle porte
> del comune e la porteranno da noi in tempi relativamente rapidi
Che culo!
> it.comp.reti.locali il messaggio
> news:0ng1jd5l8424k45rn...@4ax.com. Vediamo cosa ha scritto:
>
>> La mia prova risale a diversi
>> anni fa, e gli upload erano a 512 kbps
>
> qui si viaggia VDSL 100/20 mega, la fibra gigabit 1000/1000 è alle porte
> del comune e la porteranno da noi in tempi relativamente rapidi
Bruno
Jun 25, 2018, 2:24:27 PM6/25/18
to
Il 25/06/18 11:48, Skywalker Senior ha scritto:
io uso vnc (versione licenziata e criptata) su porte differenti.
Ho attivo anche un RDP con cambio porta standard e check da parte del
router del port forward, permesso ad un solo ip
--
Saluti
Bruno
Ho attivo anche un RDP con cambio porta standard e check da parte del
router del port forward, permesso ad un solo ip
--
Saluti
Bruno
acc
Jun 25, 2018, 3:48:46 PM6/25/18
to
Il 25/06/2018 17.45, Mirko Borsari ha scritto:
> io non capisco cosa stai dicendo... una ADSL più veloce di una LAN??
Se il database sta su una macchina diversa, tra una LAN e una
> io non capisco cosa stai dicendo... una ADSL più veloce di una LAN??
connessione remota non fa differenza.
Non rispondermi anche tu che una connessione LAN in genere e' piu'
veloce di una remota, questo non conta niente, quello che conta e' che
in entrambi i casi si passa per un "canale lento", dove il "quanto" piu'
lento non ha molta rilevanza.
Sotto questo aspetto i database si comportano bene, perche' una delle
loro caratteristiche e' quella di ridurre al minimo il traffico di rete.
Potrei capire una critica rispetto all'impegno di risorse come CPU e
RAM, ma non sul traffico, come aveva detto Sky.
Valerio Vanni
Jun 25, 2018, 5:21:44 PM6/25/18
to
On Mon, 25 Jun 2018 21:50:26 +0200, acc <em...@farlocca.it> wrote:
>> io non capisco cosa stai dicendo... una ADSL più veloce di una LAN??
>
>Se il database sta su una macchina diversa, tra una LAN e una
>connessione remota non fa differenza.
>Non rispondermi anche tu che una connessione LAN in genere e' piu'
>veloce di una remota, questo non conta niente, quello che conta e' che
>in entrambi i casi si passa per un "canale lento", dove il "quanto" piu'
>lento non ha molta rilevanza.
Come non ha rilevanza?
>> io non capisco cosa stai dicendo... una ADSL più veloce di una LAN??
>
>Se il database sta su una macchina diversa, tra una LAN e una
>connessione remota non fa differenza.
>Non rispondermi anche tu che una connessione LAN in genere e' piu'
>veloce di una remota, questo non conta niente, quello che conta e' che
>in entrambi i casi si passa per un "canale lento", dove il "quanto" piu'
>lento non ha molta rilevanza.
Hai detto anche tu:
>Magari e' il programma che e' fatto male e fa query enormi senza motivo,
>ma se e' cosi' non e' colpa del database.
bisogna vedere se con una connessione lenta quel programma è in grado
di funzionare.
acc
Jun 25, 2018, 5:55:31 PM6/25/18
to
Il 25/06/2018 23.21, Valerio Vanni ha scritto:
> Ecco, non è questione di dar la colpa a qualcuno. Semplicemente,
> bisogna vedere se con una connessione lenta quel programma è in grado
> di funzionare.
Non si puo' dare la colpa al database se viene usato male.
> Ecco, non è questione di dar la colpa a qualcuno. Semplicemente,
> bisogna vedere se con una connessione lenta quel programma è in grado
> di funzionare.
Ti faccio notare che il mio intervento e' iniziato quando Sky ha detto:
"Il problema di SQL è che trasferisce pacchetti piuttosto grossi proprio
perché non è pensato per essere usato da remoto."
IMHO questo non e' vero, anzi direi che e' vero il contrario, cioe' che
perché non è pensato per essere usato da remoto."
l'utilizzo di database SQL, rispetto ad altri sistemi, si rivela piu'
efficace proprio con connessioni lente. Tra l'altro io non sono certo un
simpatizzante di questi database, di solito tendo a preferire altre
soluzioni.
Mirko Borsari
Jun 26, 2018, 4:16:50 AM6/26/18
to
Il Mon, 25 Jun 2018 21:50:26 +0200, acc ha scritto:
> Se il database sta su una macchina diversa, tra una LAN e una
> connessione remota non fa differenza.
> Non rispondermi anche tu che una connessione LAN in genere e' piu'
> veloce di una remota, questo non conta niente, quello che conta e' che
> in entrambi i casi si passa per un "canale lento", dove il "quanto" piu'
> lento non ha molta rilevanza.
non sarei così assolutistico...
> Se il database sta su una macchina diversa, tra una LAN e una
> connessione remota non fa differenza.
> Non rispondermi anche tu che una connessione LAN in genere e' piu'
> veloce di una remota, questo non conta niente, quello che conta e' che
> in entrambi i casi si passa per un "canale lento", dove il "quanto" piu'
> lento non ha molta rilevanza.
concordo in linea di massima, ma l'esperienza di uso in wan potrebbe
essere decisamente frustante.
Mi capita di fare delle query su AS400/SQL per esportare su excel
varie anagrafiche o statistiche, farlo in LAN non è come farlo in WAN.
Senza modifiche al timeout nel mio caso non riuscirei proprio a farle
Magari se ci fosse una 100Mb simmetrica invece di 2Mb non avrei queste
difficoltà.
quindi è vero che il tutto funziona anche su canali lenti, ma ci
possono essere dei ma.
Arne Saknussemm
Jun 26, 2018, 4:18:06 AM6/26/18
to
On Mon, 25 Jun 2018 09:47:24 +0200
"Skywalker Senior" wrote in it.comp.reti.locali
<pgq6mc$16lh$1...@gioia.aioe.org>:
> Non è mai saggio esporre direttamente una macchina in RDP
anche perchè, come minimo, ti becchi un tot di tentativi di
bruteforcing, che magari non riescono, ma che comunque ti rompono le
scatole e consumano inutilmente banda; considerando che tool come
questo
https://www.darknet.org.uk/2008/07/tsgrinder-brute-force-terminal-services-server/
sono in giro ormai da anni e che li può usare anche un ragazzino, credo
sia meglio evitare di pubblicare RDP liscio; al minimo, si può cercare
di mitigare il problema cambiando la porta di ascolto, ma è comunque
solo un palliativo; in breve, se devi accedere tramite RDP ed hai un IP
fisso, basta semplicemente usare il firewall per limitare l'accesso
alla porta RDP ai soli IP desiderati, se invece non sai a priori da
quali IP arriveranno le connessioni, allora ti serve una VPN (o anche
un semplice tunnel SSL - con certificati client ovviamente)
"Skywalker Senior" wrote in it.comp.reti.locali
<pgq6mc$16lh$1...@gioia.aioe.org>:
> Non è mai saggio esporre direttamente una macchina in RDP
anche perchè, come minimo, ti becchi un tot di tentativi di
bruteforcing, che magari non riescono, ma che comunque ti rompono le
scatole e consumano inutilmente banda; considerando che tool come
questo
https://www.darknet.org.uk/2008/07/tsgrinder-brute-force-terminal-services-server/
sono in giro ormai da anni e che li può usare anche un ragazzino, credo
sia meglio evitare di pubblicare RDP liscio; al minimo, si può cercare
di mitigare il problema cambiando la porta di ascolto, ma è comunque
solo un palliativo; in breve, se devi accedere tramite RDP ed hai un IP
fisso, basta semplicemente usare il firewall per limitare l'accesso
alla porta RDP ai soli IP desiderati, se invece non sai a priori da
quali IP arriveranno le connessioni, allora ti serve una VPN (o anche
un semplice tunnel SSL - con certificati client ovviamente)
acc
Jun 26, 2018, 6:17:03 AM6/26/18
to
Il 26/06/2018 10.16, Mirko Borsari ha scritto:
> non sarei così assolutistico...
> concordo in linea di massima, ma l'esperienza di uso in wan potrebbe
> essere decisamente frustante.
> Mi capita di fare delle query su AS400/SQL per esportare su excel
> varie anagrafiche o statistiche, farlo in LAN non è come farlo in WAN.
> Senza modifiche al timeout nel mio caso non riuscirei proprio a farle
> Magari se ci fosse una 100Mb simmetrica invece di 2Mb non avrei queste
> difficoltà.
> quindi è vero che il tutto funziona anche su canali lenti, ma ci
> possono essere dei ma.
Si, ma tu non stai facendo un confronto database SQL rispetto ad altro
> non sarei così assolutistico...
> concordo in linea di massima, ma l'esperienza di uso in wan potrebbe
> essere decisamente frustante.
> Mi capita di fare delle query su AS400/SQL per esportare su excel
> varie anagrafiche o statistiche, farlo in LAN non è come farlo in WAN.
> Senza modifiche al timeout nel mio caso non riuscirei proprio a farle
> Magari se ci fosse una 100Mb simmetrica invece di 2Mb non avrei queste
> difficoltà.
> quindi è vero che il tutto funziona anche su canali lenti, ma ci
> possono essere dei ma.
(a parita' di connessione), ma piuttosto di WAN vs LAN.
Questa questione secondo me non si pone, e' ovvio che potendo scegliere
e' sempre meglio avere i dati in locale, meglio sulla stessa macchina o
al piu' in LAN, piuttosto che in remoto. Ma dovendo per forza lavorare
in remoto, siamo sicuri che il collo di bottiglia sia rappresentato dal
database SQL? IMHO no.
Skywalker Senior
Jun 26, 2018, 10:39:30 AM6/26/18
to
Mirko Borsari ha usato la sua tastiera per scrivere :
una WAN 100Mb simmetrica, la latenza non sarebbe come quella di una LAN
di pari velocità
> Il Mon, 25 Jun 2018 21:50:26 +0200, acc ha scritto:
>
>> Se il database sta su una macchina diversa, tra una LAN e una
>> connessione remota non fa differenza.
>> Non rispondermi anche tu che una connessione LAN in genere e' piu'
>> veloce di una remota, questo non conta niente, quello che conta e' che
>> in entrambi i casi si passa per un "canale lento", dove il "quanto" piu'
>> lento non ha molta rilevanza.
>
> non sarei così assolutistico...
> concordo in linea di massima, ma l'esperienza di uso in wan potrebbe
> essere decisamente frustante.
> Mi capita di fare delle query su AS400/SQL per esportare su excel
> varie anagrafiche o statistiche, farlo in LAN non è come farlo in WAN.
> Senza modifiche al timeout nel mio caso non riuscirei proprio a farle
> Magari se ci fosse una 100Mb simmetrica invece di 2Mb non avrei queste
> difficoltà.
> quindi è vero che il tutto funziona anche su canali lenti, ma ci
> possono essere dei ma.
Non dimentichiamo che anche la latenza ha il suo peso. Ammesso di avere
>
>> Se il database sta su una macchina diversa, tra una LAN e una
>> connessione remota non fa differenza.
>> Non rispondermi anche tu che una connessione LAN in genere e' piu'
>> veloce di una remota, questo non conta niente, quello che conta e' che
>> in entrambi i casi si passa per un "canale lento", dove il "quanto" piu'
>> lento non ha molta rilevanza.
>
> non sarei così assolutistico...
> concordo in linea di massima, ma l'esperienza di uso in wan potrebbe
> essere decisamente frustante.
> Mi capita di fare delle query su AS400/SQL per esportare su excel
> varie anagrafiche o statistiche, farlo in LAN non è come farlo in WAN.
> Senza modifiche al timeout nel mio caso non riuscirei proprio a farle
> Magari se ci fosse una 100Mb simmetrica invece di 2Mb non avrei queste
> difficoltà.
> quindi è vero che il tutto funziona anche su canali lenti, ma ci
> possono essere dei ma.
una WAN 100Mb simmetrica, la latenza non sarebbe come quella di una LAN
di pari velocità
ObiWan
Jun 27, 2018, 7:01:54 AM6/27/18
to
:: On Fri, 22 Jun 2018 12:01:01 +0200
:: (it.comp.reti.locali)
:: <1uw7fe6iieu6g$.d...@mirkonews.bsi-net.it>
il software, se è scritto bene, se "cade la linea", la sessione viene
terminata e via, se invece è scritto con i piedi ...
Ad ogni modo quantomeno con applicazioni recenti, non mi è mai capitato
che restasse qualcosa "appeso", certo, 20 o più anni fa poteva anche
succedere, ma la vedo difficile oggi, per un'applicazione scritta con
un minimo di criterio
:: (it.comp.reti.locali)
:: <1uw7fe6iieu6g$.d...@mirkonews.bsi-net.it>
:: Mirko Borsari <ne...@bsi-net.it> wrote:
> Eviti anche che in caso di disconnessione si rimanga appesi.
Beh, ma questo non è un problema relativo alla VPN, ma a come è scritto
> Eviti anche che in caso di disconnessione si rimanga appesi.
il software, se è scritto bene, se "cade la linea", la sessione viene
terminata e via, se invece è scritto con i piedi ...
Ad ogni modo quantomeno con applicazioni recenti, non mi è mai capitato
che restasse qualcosa "appeso", certo, 20 o più anni fa poteva anche
succedere, ma la vedo difficile oggi, per un'applicazione scritta con
un minimo di criterio
Meddix
Jun 27, 2018, 1:06:28 PM6/27/18
to
Il 27/06/2018 13:01, ObiWan ha scritto:
> ma la vedo difficile oggi, per un'applicazione scritta con
> un minimo di criterio
sii benedetto!
> ma la vedo difficile oggi, per un'applicazione scritta con
> un minimo di criterio
ObiWan
Jun 28, 2018, 10:50:07 AM6/28/18
to
:: On Wed, 27 Jun 2018 19:06:27 +0200
:: (it.comp.reti.locali)
:: <ph0g6h$1obe$1...@gioia.aioe.org>
LOL :D
:: (it.comp.reti.locali)
:: <ph0g6h$1obe$1...@gioia.aioe.org>
Andrea B.
Jul 3, 2018, 5:59:19 AM7/3/18
to
Il 25/06/2018 20:24, Bruno ha scritto:
> Il 25/06/18 11:48, Skywalker Senior ha scritto:
>> Il 25/06/2018, Mirko Borsari ha detto :
>>> Il Mon, 25 Jun 2018 09:53:46 +0200, Andromeda ha scritto:
>>>
>>>
>>>>>> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere
>>>>>> superflua nel secondo no.
>>>>>
>>>>> Nno è mai saggio esporre direttamente una macchina in RDP
>>>>
>>>> Ne sono straconvinto ma mi scontro sempre con gente che va di RDP
>>>> liscio in internet.
>>>
>>> bhe però bisogna vedere se è veramente liscio...
>>> perchè se è blindato per accettare connessioni solo da determinati IP,
>>> la cosa cambia.
>>
>> Si, diciamo che aggiungendo un paio di accorgimenti (cambio porta
>> standard e, soprattutto, origini prefissate) diventa un po' più sicuro
>
Aggiungerei anche la limitazione degli utenti abilitati ad RDP,
> Il 25/06/18 11:48, Skywalker Senior ha scritto:
>> Il 25/06/2018, Mirko Borsari ha detto :
>>> Il Mon, 25 Jun 2018 09:53:46 +0200, Andromeda ha scritto:
>>>
>>>
>>>>>> Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere
>>>>>> superflua nel secondo no.
>>>>>
>>>>> Nno è mai saggio esporre direttamente una macchina in RDP
>>>>
>>>> Ne sono straconvinto ma mi scontro sempre con gente che va di RDP
>>>> liscio in internet.
>>>
>>> bhe però bisogna vedere se è veramente liscio...
>>> perchè se è blindato per accettare connessioni solo da determinati IP,
>>> la cosa cambia.
>>
>> Si, diciamo che aggiungendo un paio di accorgimenti (cambio porta
>> standard e, soprattutto, origini prefissate) diventa un po' più sicuro
>
esclusione dell'amministratore, timeout di m minuti dopo n tentativi di
login.
Bruno
Jul 3, 2018, 2:57:14 PM7/3/18
to
Il 03/07/18 11:59, Andrea B. ha scritto:
>
> Aggiungerei anche la limitazione degli utenti abilitati ad RDP,
> esclusione dell'amministratore, timeout di m minuti dopo n tentativi di
> login.
>
Grazie mille per i suggerimenti, sempre ben accetti.
Gli utenti sono già limitati (uno solo, alla fine) e tutti gli accessi
sono "loggati" nel firewall
--
Saluti
Bruno
>
> Aggiungerei anche la limitazione degli utenti abilitati ad RDP,
> esclusione dell'amministratore, timeout di m minuti dopo n tentativi di
> login.
>
Gli utenti sono già limitati (uno solo, alla fine) e tutti gli accessi
sono "loggati" nel firewall
--
Saluti
Bruno
0 new messages