Newsgroup: it.comp.os.linux.iniziare
Titolo: Re: openvpn routed or bridged?

 [cut bla bla bla]
Il server e` anche il default gateway di quelle macchine?
http://openvpn.net/faq.html
 ->
I've successfully set up OpenVPN and can ping between both OpenVPN peers,
however I cannot reach any of the other machines on the remote subnet.
What's the problem?


gpg --keyserver 
pgp.mit.edu
 --recv-keys EEBB4D0D
Universita` degli Studi di Milano - Bicocca
Sistemi Informativi
Via Cozzi 53 - I 20125 Milano Italy
Tel. 
+39 02 6448 5526

 Questo per poter uscire tutti su internet.
E allora vedi la risposta nelle FAQ di OpenVPN che ti ho linkato prima.
O NATti o metti una route statica...perche` il pacchetto le macchine
dentro la rete lo vedono arrivare non "dal server",ma dal tuo IP
sulla VPN.
Pertanto la risposta la instradano sul gateway vero e proprio e finisce
nel nulla...

 nel nulla...
Scusa la mia abissale ignoranza ma:
la ruote table del server vpn e':
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.200.0.0      *               255.255.0.0     U     0      0        0 eth0
default         10.200.1.1      0.0.0.0         UG    0      0        0 eth0
quella del client da cui mi collego da remoto e':
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
192.168.100.1   *               255.255.255.255 UH    0      0        0 ppp0
10.200.166.0    10.8.0.5        255.255.255.0   UG    0      0        0 tun0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
default         192.168.100.1   0.0.0.0         UG    0      0        0 ppp0
le informazioni relative agli indirizzi 10.8... vengono inserite in
automatico dal demone openvpn sia lato client che lato server, io non
faccio assolutamente nulla.
Il 10.200.1.1 e' il default gateway dei client della lan.
Da quello che mi stai decendo dovrei aggiungere qui la route per i pacchetti
provenienti dagli indirizzi 10.8.0.x.
Tale route, scusami se dico cavolate, dovrebbe instradare le risposte alle
richieste provenienti da 10.8.0.x verso il 10.8.0.2 se non ho capito male.
Inoltre per poter gestire gli indirizzi 10.8.0.x dovrei aggiungere una
interfaccia al gateway dando un indirizzo facente parte della 10.8.0.x?

 gateway dando un indirizzo facente parte della 10.8.0.x?
No. Facciamo chiarezza e senza IP.
Tu mandi un pacchetto verso $IPDIMACCHINAINTERNA dal tuo client a casa tua.
Il pacchetto passa attraverso il tunnel perche` hai una route apposta
per quella subnet.
Il pacchetto ha come indirizzo sorgente $IP_CHE_HAI_TU_CLIENT_SUL_TUN
e *se* il server che tiene su la VPN fa forwarding nudo e crudo esso viene
diretto sulla macchina interna.
A quel punto la macchina interna,non avendo una route specifica per
quell'IP,manda le sue risposte sul default gateway che *non* e` il server
che tiene su la VPN e le risposte vanno perdute come lacrime nella pioggia.
Pertanto:
- sulle macchine interne che vuoi contattare metti una route che gli dica
"per rispondere a $IP_CHE_HAI_TU_CLIENT_SUL_TUN instrada verso
$IP_DELLA_SCHEDA_DI_RETE_SULLA_LAN_DELLA_MACCHINA_CHE_TIENE_SU_OPENVPN"
-fai SOURCE NAT,ovvero "mascheri" il pacchetto proveniente dal tunnel
sostituendo il source address con quello $IP_DELLA_BLABLA
cosi` che le macchine interne credano di parlare direttamente con "la
macchina che tiene su la VPN"
C'e` un capitolo apposta sullo SNAT qua:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Per il resto: tcpdump e tetheral sono tuoi amici,impara ad usarli per fare
debugging.

 
Quindi devo agire a livello di ogni singolo client?
Non potrei mettere questa route nel loro default gateway?

Braindead wrote:

Ho aggiunto la route sul default gateway dei clients.
Ora riesco a pingarli tutti, dovrebbe significare che e' tutto a posto.
Non riesco pero' ad accedere alle loro risorse condivise che pure ci sono.
Dalla mia macchina linux di casa un smbclient -L IPINTERNO va in timeout.

 Dalla mia macchina linux di casa un smbclient -L IPINTERNO va in timeout.
risolto, i client avevano quel cavolo di firewall attivo, purtroppo non
potevo saperlo se non facendo dei tentativi poiche' non posso recarmi in
loco.
Grazie mille per l'aiuto :-)