View Full Version : OpenVpn su stessa rete
elpirata1981
14-02-2016, 19:50
Un saluto a tutti gli amici del forum,
avrei necessità di un vostro supporto, mi trovo ad interconnettere tre strutture che hanno la stessa maledetta classe di indirizzi ip, ossia 192.168.1.x
In una di queste strutture, ho messo in piedi un server ubuntu con openvpn, ho testato la comunicazione tra i client e funziona, la vpn instaura correttamente la connessione. Il mio problema è la connessione internet,
vorrei che ogni client uscisse su internet con l'adsl della propria struttura e non con la banda della connessione vpn.
In sostanza simuliamo che nella sede (A) ci sia una macchina client e un server openvpn con indirizzo tun0 10.1.1.4 e eth0 192.168.1.25 e connessione internet Fastweb ip pubblico 88.75.155.222
Nella sede (B) esiste una macchina client con indirizzo tun0 10.1.1.10 e eth0 192.168.1.15 e connessione Telecom ip pubblico 65.25.22.111
Ecco io vorrei che quando i client sono connessi in vpn, il client (A) esca su internet con ip pubblico 88.75.155.222 e il client (B) esca su internet con ip pubblico 65.25.22.111
Solo il traffico lan deve passare per la vpn quello wan no :muro:
Confido in voi
come hai configurato le rotte?
Se non cambi indirizzamento ad uno dei due siti l'unica cosa che puoi fare, per rendere vagamente utile la vpn, è il double nat.
elpirata1981
14-02-2016, 21:16
come hai configurato le rotte?
Se non cambi indirizzamento ad uno dei due siti l'unica cosa che puoi fare, per rendere vagamente utile la vpn, è il double nat.
Ciao Dane,
anzitutto grazie per la risposta,
per il momento non ho la possibilità di cambiare indirizzamento, ma ho necessità che le due sedi comunichino.
Queste sono le rotte del server vpn:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
10.1.1.0 10.1.1.2 255.255.255.0 UG 0 0 0 tun0
10.1.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Queste iptables server
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- 10.1.1.0/24 anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
Questo openvpn serve
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.1.1.0 255.255.255.0
push "redirect-gateway def1"
push "route 192.168.1.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS "192.168.1.1"
push "dhcp-option DNS 208.67.220.220"
Questo openvpn client
client
dev tun
proto udp
remote mioippubblico 1194
ca ca.crt
cert zona1.crt
key zona1.key
tls-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
verb 1
mi sono proprio perso ... :muro:
ok.
Senza le rotte sul client immagino che sia redirect-gateway a fregarti, ma non si capisce il problema.
Scusa un attimo.... ma come pensi di raggiungere i dispositivi da una parte all'altra? (intendo come indirizzamento)
credo si possa fare con qualcosa tipo source nat
oppure come dice Dane: https://it.wikipedia.org/wiki/Network_address_translation#Double_NAT
elpirata1981
15-02-2016, 00:06
Scusa un attimo.... ma come pensi di raggiungere i dispositivi da una parte all'altra? (intendo come indirizzamento)
Dane credimi sto da ieri su questo problema e non ci ho dormito la notte.
Quando attivo la VPN in sede (A) su macchina Windows collegata sulla stessa rete del server Linux openvpn al client Windows viene assegnato ip tun0 10.1.1.4 e eth0 statico 192.168.1.10
In sede (B) su macchina Windows con ip statico eth0 192.168.1.20 viene assegnato tun0 10.1.1.10
Se da (A) pingo (B) o viceversa sulle interfacce eth0 ottengo risposta (non si quelle tun0)
Il problema è che se l utente (B) naviga su internet lo fa passando per (A) e non dalla sua connessione e questa cosa mi satura la banda di (A)
elpirata1981
15-02-2016, 00:15
credo si possa fare con qualcosa tipo source nat
oppure come dice Dane: https://it.wikipedia.org/wiki/Network_address_translation#Double_NAT
Ciao mmiat,
grazie anche a te per l'intervento, ho letto il wiki e devo dire che non mi aspettavo tutti questi aspetti negativi.
In sostanza io ho un server in sede (A), su questo server gira un software gestionale a cui accedono 6 postazioni client sempre sede (A) adesso ci sono altri 3 client in sede (B) che devono accedere a questo gestionale.
Credimi sto impazzendo sul serio 😣
Dane credimi sto da ieri su questo problema e non ci ho dormito la notte.
Quando attivo la VPN in sede (A) su macchina Windows collegata sulla stessa rete del server Linux openvpn al client Windows viene assegnato ip tun0 10.1.1.4 e eth0 statico 192.168.1.10
In sede (B) su macchina Windows con ip statico eth0 192.168.1.20 viene assegnato tun0 10.1.1.10
Se da (A) pingo (B) o viceversa sulle interfacce eth0 ottengo risposta (non si quelle tun0)
Il problema è che se l utente (B) naviga su internet lo fa passando per (A) e non dalla sua connessione e questa cosa mi satura la banda di (A)
Posto che quanto affermi sul traffico tra le due sedi (benchè plausibile) è tutto da verificare (dump dei pacchetti), vedi che se ci dici cosa devi fare è più facile risponderti....
Secondo me, se devi solo collegarti sul gestionale, installerei il "server vpn" sul server che ospita il gestionale. Ci accedi dai client remoti usando l'indirizzo dell'interfaccia tun (sul server che ospita il gestionale).
Tuttavia il gestionale fa probabilmente traffico "ghirigori" tipo lan. Ovvero trasferisce parecchi dati. (Perchè se fosse un gestionale su web immagino che tu abbia già portforwardato il necessario....)
In tal caso piazza un terminal server nella sede con il gestionale e fai collegare i client remoti direttamente tramite rdp portforwardato. Se entrambe le sedi hanno ip statico ti togli dai piedi anche la vpn: basta usare filtraggio per ip sorgente.
Per avere un prototipo e vedere come funziona la cosa basta un windows7/8/10 pro patchato per l'accesso concorrente rdp. Ovviamente (licenza di win) non lo puoi usare in produzione.
Se è come ho ipotizzato (gestionale che fa parecchio traffico), la soluzione terminal server (o n pc in più nella sede con il gestionale) è l'unica praticamente percorribile, tenendo l'infrastruttura in casa.
Rinnovo la raccomandazione di cambiare indirizzamento. Se qualcuno fa fatica a comprenderne la necessità fatturagli le ore di non sonno.
Sogni d'oro! :D
Rinnovo la raccomandazione di cambiare indirizzamento. Se qualcuno fa fatica a comprenderne la necessità fatturagli le ore di non sonno.
concordo al 100%, se tu avessi 2 reti da centinaia di host potrei comprendere, ma per un paio di macchine conviene sicuramente fare ordine e sistemare gli ip.
Hanno già detto tutto sopra (cambia classe ip)
Se la cosa è veramente così impossibile, e hai necessità di accedere unicamente a un server, potresti ragionare di mettere un doppio ip su quel server (ovviamente di tutt'altra classe).
elpirata1981
15-02-2016, 15:49
Ragazzi che dire apparte un grazie immenso per l'interessamento e la presa a cuore della mia problematica.
Vengo subito al punto, seguendo i vostri consigli ho effettuato il cambio classe, adesso ho la sede (A) 192.168.1.x -----> sede (B) 192.168.20.x
tra qualche giorno testo la vpn
In sede (A) devo acquistare una workstation e installargli il gestionale che gira esclusivamente sotto (Win), mentre la openvpn l'ho installata in un semplice muletto con debian 14.04 server - scheda rete 10/100 - 1Gb di ram (ditemi se ho fatto male)
Ultima cosa poi metto il tanto ambito Risolto ... per non appesantire la Vpn vorrei far passare solo il traffico di "lavoro", mentre il traffico web-mail-ecc vorrei farlo passare dai rispettivi gateway delle sedi (A) e (B) non so però come istruire openvpn per questa cosa ...
Se entrambe le sedi hanno ip statico ti togli dai piedi anche la vpn: basta usare filtraggio per ip sorgente.
Le due sedi hanno ip pubblico statico con router telecom italia, ma non so gestire il filtraggio ip sorgente
Raga grazie ancora per il supporto :)
Dubito che tu abbia un tale carico per cui andrai ad appesantire le VPN, quindi non mi porrei il problema.
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.