Newsgroup: it.comp.reti.locali
Titolo: vpn per usare un software da remoto

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 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à

 
 
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


 record, i dati nel loro complesso non arrivano a più di 150MB totali
 
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. Poi, magari, se si ha una 
connessione veloce, può anche funzionare meglio.
Nel caso, le porte da aprire sono la 1433 e 1434

 una immagine di prodotto verso il programma di gestione immagini)
 
Usa una VPN, puoi implementarla usando il supporto nativo di windows
(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 :)
 
 

 office *non* è installato sul server ma solo sui pc
 
RDP supporta copia/incolla clipboard e file locale/remoto.
Dai retta a quelli del gestionale.

 oppure attivare la funzione vpn-peer-to-peer implementata sul router stesso 
 
io preferisco sempre attestare le vpn su un firewall. ma nulla ti
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

 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 :)


 
 
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


 
 
link già visto, grazie
appena posso metto in pratica


 
 
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?


 Dai retta a quelli del gestionale.
 
Ma RDP è criptato o è in chiaro ? Nel primo caso la vpn può essere 
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.
 

 appena posso metto in pratica
 
fai una prova, verifica la velocità e via; 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
 

 che altro che non mi viene in mente?
 
dipende da come è fatto il software. di solito succede la seconda.


in errore per mancata risposta del database.
 
Ho lo stesso ricordo anch'io, di una prova fatta una decina d'anni fa:
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.

 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.
 
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

ma se e' cosi' non e' colpa del database.
 
Questo può darsi...


 3G.
 
Cioe' per un canale piu' lento, esattamente come avviene in ambito LAN.


 
 
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


 Cioe' per un canale piu' lento, esattamente come avviene in ambito LAN.
 
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ì.

 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.
Sono intervenuto sperando in una risposta come la tua e... è arrivata ;-)


 in internet.
 
bhe però bisogna vedere se è veramente liscio...
perchè se è blindato per accettare connessioni solo da determinati IP,
la cosa cambia.


 la cosa cambia.
 
Si, diciamo che aggiungendo un paio di accorgimenti (cambio porta 
standard e, soprattutto, origini prefissate) diventa un po' più sicuro

sono "razionali", magari si può usare anche così.
 
Questo può darsi, spesso chi programma un DB conta di avere una LAN.


 sono "razionali", magari si può usare anche così.
 
Davvero vorresti convincermi che una LAN e' piu' veloce di una ADSL?
La luna non il dito!

 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
 

 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



io non capisco cosa stai dicendo... una ADSL più veloce di una LAN??


 del comune e la porteranno da noi in tempi relativamente rapidi
 
Che culo!

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

 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.
 
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.


ma se e' cosi' non e' colpa del database.
 
Ecco, non è questione di dar la colpa a qualcuno. Semplicemente,
bisogna vedere se con una connessione lenta quel programma è in grado
di funzionare.


 di funzionare.
 
Non si puo' dare la colpa al database se viene usato male.
 
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 
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.


 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 è 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)
 

 possono essere dei ma.
 
Si, ma tu non stai facendo un confronto database SQL rispetto ad altro 
(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.

 possono essere dei ma.
 
Non dimentichiamo che anche la latenza ha il suo peso. Ammesso di avere 
una WAN 100Mb simmetrica, la latenza non sarebbe come quella di una LAN 
di pari velocità

 Eviti anche che in caso di disconnessione si rimanga appesi.
 
Beh, ma questo non è un problema relativo alla VPN, ma a come è scritto
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
 

 un minimo di criterio
sii benedetto!



LOL :D
 
 

 
 
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