Synology Italia - Forum

davide80 ha scritto:alla base di quanto detto è possibile affermare che:
- meno router ci sono sulla "strada" del pacchetto più la connessione è veloce? (almeno sulla parte ping)

No, la velocità fra due punti corrisponderà a quella della tratta più lenta in assoluto (o per limiti fisici, o per congestione del traffico).
L'aggiunta di svariate apparecchiature fra i due punti contribuirà ad aumentare la latenza (il tempo di ping, il ritardo di propagazione) dovuta alla necessità di ogni apparecchiatura di elaborare il traffico. Poi ovviamente come detto sopra la tratta più lenta sarà per forza determinata da qualche apparecchiatura. E come se fra due punti tu avessi 5 switch di cui uno FastEthernet. Anche se il punto stabilisse la connessione Gigabit con il primo switch la banda (velocità effettiva) non potrebbe che essere 100Mb. Indipendentemente da quanti switch tu aggiunga nel percorso la banda rimarrà la stessa, aumenterà solamente il ritardo (latenza) con il quale il traffico arriverà al partner.
Se hai un PVR è come mettere il film in pausa per 30" (time-shift). Tu lo continui a guardare sempre alla stessa velocità (fotogrammi al secondo) ma con 30 secondi di ritardo introdotto dal PVR.

- una o più rotte statiche semplificano il lavoro dei router e permettono tempi di risposta più veloci dei pacchetti?

Se sono statiche evidentemente qualcuno gliele ha impostate, altrimenti potrebbe averle apprese in automatico (dinamicamente), perché trasmesse in rete, attraverso protocolli come ad esempio il RIP, OSPF, BGP..., se è stato configurato per tale funzione (difficilmente reperibile su routers SOHO).
Statiche o dinamiche non fa differenza. Se c'è almeno una rotta il traffico verrà instradato altrimenti verrà perso. Possono esserci più rotte con percorsi diversi fra due endpoint. Normalmente hanno metriche (costi) diverse e prevale quella con il costo più basso, l'altra è di backup nel caso sul percorso primario ci sia un guasto. Se hanno pesi (metriche) uguali bilanciano il traffico attraverso le varie apparecchiature di rete.
Difficilmente avrai tali configurazioni in ambiente soho, ma in internet tutto è almeno doppio ed è buona prassi anche nelle enterprise onde evitare il singolo punto di rottura.

non vedo una rete con il rip da anni...

burghy86 ha scritto:non vedo una rete con il rip da anni...

Vero, resta però l'unico protocollo nativamente supportato dai sistemi windows client (nelle opzioni di rete puoi installare il "rip listener") e nelle apparecchiature soho (se non assente del tutto). Ad esempio i draytek supportano il RIP ma solo alcuni il BGP. Altrimenti saliamo di classe (routers cisco, fw watchguard) ma soprattuto di prezzo.

Allora ho risolto abbastanza velocemente usando OpenVPN al posto di L2TP.
In effetti una volta scaricato il client sul pc/mac ed esportata la configurazione ci si collega in un attimo.

Tra l'altro attivando la voce "consenti ai client di accedere alla LAN del server" riesco dal client remoto a pingare gli IP locali, che era quello che volevo.
Non ho creato nessuna rotta statica né sul router, né sul NAS (autocreate) ma soprattutto né sul client remoto, probabilmente l'avrà fatto il client OpenVPN?

Grazie per le dritte!

Sul client le fa openvpn, a seconda della configurazione del OS Win potrebbe però richiedere l'esecuzione con diritti amministrativi.
Se fai un "route print" prima e dopo l'attivazione della vpn noterai le rotte aggiunte.

La spunta sul server vpn dovrebbe far la medesima cosa sula nas. L'unica cosa che ancora mancherebbe è la rotta sul router (quello locale al nas) per i nodi locali che hanno come default gateway il router e non il nas ... a meno che non ci pensi quest'ultimo via upnp ... o che la vpn non sia nattata internamente sull'ip locale del nas, ma non avrebbe senso, precluderebbe alcune funzionalità.
Da pc remoto prova pingare il pc locale via vpn ... poi prova fare l'opposto ovvero dal pc locale pingare quello remoto connesso in vpn (al indirizzo 10.x.x.x che gli viene assegnato). A me capita ad esempio di far accedere i client mobili in vpn per poter poi fare una sessione RDP. Con temviewer ad esempio se devi fare qualche operazione amministrativa, quando si apre il prompt di sicurezza win, perdi l'interazione con la macchina e dovresti consegnare le credenziali all'utente per poterle immettere al posto tuo.

Comunque si, l'openvpn è alla fine quella più semplice da configurare, salvo richiedere l'installazione del client ... ed è anche quello più sicuro, basandosi sul certificato che deve essere esportato e trasferito.

dMajo ha scritto: ... poi prova fare l'opposto ovvero dal pc locale pingare quello remoto connesso in vpn (al indirizzo 10.x.x.x che gli viene assegnato).

Hai ragione, non va, ma nel mio caso non mi serve quindi posso omettere giusto?
Grazie infinite.

dMajo ha scritto:Da pc remoto prova pingare il pc locale via vpn ... poi prova fare l'opposto ovvero dal pc locale pingare quello remoto connesso in vpn (al indirizzo 10.x.x.x che gli viene assegnato).

Ciao. Torno sull'argomento perché fatalità mi occorre accedere ad una risorsa della rete locale, in particolare:

- devo accedere DAL NAS REMOTO (ip locale 192.168.10.2) all'IP LOCALE 192.168.0.4
- il gateway REMOTO ha IP 192.168.10.254
- OPENVPN mi ha dato IP 10.8.0.6 con SM 255.255.255.252 (senza GW come avevamo detto)

Da quanto ho capito manca solo la regola statica sul router REMOTO che istradi i pacchetti con destinazione 192.168.0.4 nel Tunnel.
Ho provato a fare così:

IP 192.168.0.4 SM 255.255.255.255 GW 192.168.10.254 (metrica 2)

Ma accedendo al NAS in SSH non riesco a pingare 192.168.0.4.
Dove sbaglio?
Grazie mille.

Ho provato anche a creare un doppio istradamento, anche se dovrebbe bastare la seconda regola sul NAS:

Sul router:
route add 192.168.0.4/32 192.168.10.2 (dove 192.168.10.2 è l'IP locale del NAS)

Sul NAS:
route add -net 192.168.0.4/32 10.8.0.1 (dove 10.8.0.1 è il gateway della VPN)

Ma non va ancora.
Dove sbaglio?

Senti, forse sono un po stanco io, ma non ho capito i tuoi indirizzamenti.

Riepilogo:

192.168.10.0/24 LAN
-192.168.10.254 router
-192.168.10.2 nas

client openvpn
192.168.0.0/24 LAN (remota)
- 192.168.0.254 router (remoto)
- 192.168.0.4 pc client (remoto)
- 10.8.0.6 lease ottenuto via vpn dal nas (senza gw?? che vuol dire)

Quindi ora tu dal client remoto, via openvpn, pinghi il nas e tutti i nodi adiacenti (presenti nella lan locale al nas)
Dal nas (via telnet) dovresti riuscire a vedere il pc remoto via tunnel (ping, tracert) all'ip assegnato 10.x.x.x. In altre parole, il server dovrebbe esse in grado di pingare il client, in quanto direttamente connessi. Verifica che i firewall non blocchino le risposte ai ping.

Da un'altro pc locale al nas dovrebbe esser difficile pingare il pc remoto, come in assenza di rotte, senza qualche accorgimento particolare, in una normale vpn routed (non bridged) dovrebbe esser vero anche il contrario, da pc remoto pingare il locale.
Qui sicuramente una rotta statica sul router (locale al nas), se non aiuta, danni non fa. Dal punto di vista teorico è corretta: Cosi, quando il pc locale (avendo def.gw il router) pinga il pc remoto (10.8.x.x) invia il pacchetto con destinazione esterna alla propria lan, anziche direttamente al destinatario, al router per esser ulteriornente instradato. Il router grazie alla rotta sa che deve consegnarlo al nas il quale lo instraderà ulteriormente secondo le proprie rotte note.
Ho messo 10.0.0.0/8 per coprire tutti e 3 i range di default del server vpn del nas. Pel la sola openvpn puoi usare 10.8.0.0/24.
La mask che indichi tu per l'indirizzo del lease (255.255.255.252) è una /30, che definisce una subnet di soli 4 nodi (.4, .5, .6, .7) di cui il primo è l'indirizzo di sottorete e l'ultimo quello di broadcast. Se 6 è assegnato al pc remoto mi aspetto che il 5 lo usi il nas, quindi pingandolo dal pc remoto dovrebbe esser il nas a rispondere.
A conferma di ciò mi aspetto che nel pc remoto il client openvpn crei una rotta 192.168.10.0/24(255.255.255.0) con gw 10.8.0.5 sull'interfaccia 10.8.0.6.

Quindi per pingare dalla 192.168.10.0/24 unicamente i client remoti la rotta statica sul router (10.254) dovrebbe esser sufficiente, a patto che poi ci siano quelle corrette nel nas (create dal server vpn)

Per pingare invece nodi adiacenti il pc remoto (sulla 192.168.0.0/24) da un qualsiasi nodo della 192.168.10.0/24 il discorso si complica un po'. Il pc remoto deve diventare il gateway per la 192.168.10.0/24 nella sua lan.
Quindi diciamo una rotta statica sul router del pc remoto oppure temporanea sul nodo li adiacente da pingare che indica l'ip locale del pc remoto (192.168.0.4) quale gateway per la 192.168.10.0/24.
Sul PC remoto, nella connessione vpn o l'adattatore virtuale TAP dovresti, nella scheda condivisione delle proprietà, abilitare gli altri client della rete ad usare quella connessione. Ciò configura il routing fra la scheda virtuale TAP ed ad esempio quella di rete della LAN.

Perché tutto ciò funzioni però il tunnel vpn sul nas non deve esser nattato.
Non conosco i dettagli di come syno abbia configurato il server perché salvo aiutare qualche utente del forum per l'accesso remoto di base personalmente non lo uso. E' buona norma configurare ogni servizio sull'apparecchiatura a ciò preposta. Nel caso delle vpn parliamo di routers e/o firewall hardware (es. watchguard, sonicwall, ...). Tali apparecchiature hanno spesso hw dedicato a tale funzione, scaricando la cpu principale dai compiti di crittografia, e le prestazioni delle vpn sono notevolmente superiori.
Se hai sovente di questi problemi perché
- dal lavoro devi dar assistenza a clienti mobili, uffici decentrati ...
- da casa devi dar assistenza, intervenendo remotamente, presso la tua azienda, gruppo di aziende o singoli perché ad esempio sei un consulente
ti consiglio di dotarti di apparecchiature idonee. Acquista un router che possa fare da server vpn (pptp/l2tp/sslvpn) per connessioni client2lan(teleworker) e anche client/server per vpn lan2lan (generalmente ipsec) per la creazione di vpn statiche fra lan geograficamente distribuite. Valuta anche l'uso di un ip statico. E buona norma averlo su almeno un lato della connessione.

Alcune apparecchiature d'esempio tanto per capire di che parliamo:
Routers (con e senza modem xDSL integrato)
- Cisco: Serie 890/880/870
- Draytek: Vigor2860, Vigor2830, Vigor2925(router puro, no xDSL)
- TPLink (router puri, no xDSL): TL-ER6120, TL-ER6020, TL-ER604W
Firewalls HW da inserire fra router e switch della LAN
- Watchguard: XTM33/33-W, XTM26/26-W
- SonicWall: UTM TZ 215, UTM TZ 205

dMajo ha scritto:Dal nas (via telnet) dovresti riuscire a vedere il pc remoto via tunnel (ping, tracert) all'ip assegnato 10.x.x.x. In altre parole, il server dovrebbe esse in grado di pingare il client, in quanto direttamente connessi. Verifica che i firewall non blocchino le risposte ai ping.

Ciao.
Fin qui tutto ok, dal NAS remoto pingo 10.8.0.6 (client OpenVPN) senza rotte statiche necessarie.
Non riesco però, ad esempio, a pingare l'IP LAN dello stesso client (192.168.0.103) nonostante abbia disattivato il firewall su client.

Se evito di creare rotte sul router e le creo direttamente sul NAS? Così evito un routing giusto?
Ho provato a creare questa rotta sul NAS ma non funziona (ipotizzo di istradare per ora solo 192.168.0.103):
Dove tun0 è l'interfaccia tunnel sul NAS creata da OpenVPN server.


Tutto sto casino mi serve per permettere una connessione HTTP dal webserver del NAS a un server locale su 192.168.0.x, non visibile dall'esterno.