[Linux-Biella] OpenVPN

[andrea ferraris]

2009/2/17 leonardo buffa <leonardo.buffa a bilug.linux.it>:
> On Tue, 17 Feb 2009 10:30:30 +0100
> andrea ferraris <andrea.ferraris a gmail.com> wrote:
>
>> Grazie della risposta.
>>
>> 2009/2/17 leonardo buffa <leonardo.buffa a bilug.linux.it>:
>> > On Mon, 16 Feb 2009 22:11:27 +0100
>> > Andrea Ferraris <andrea.ferraris a gmail.com> wrote:
>> >
>> >> E' la prima volta che ci provo e ho un problema, apparentemente di
>> >> routing. Il tunnel crittato fra le due macchine si instaura, tanto
>> >> che da una riesco a pingare il device tun dell'altra e viceversa.
>> >>
>> >> Il problema e` quando dal vpn client cerco di arrivare all'ip
>> >> interno (DMZ) del gw del vpn server, da cui poi dovrebbe
>> >> proseguire per una LAN interna. Se faccio un traceroute dal vpn
>> >> client all'ip interno del gateway del vpn server i pacchetti
>> >> arrivano fino all'interfaccia tun del vpn server ma poi non
>> >> proseguono oltre.
>> >>
>> >> Ho abilitato l'ip_forwarding su entrambe le macchine.
>> >
>> > non sarebbe una cattiva idea postare il file di conf sia del server
>> > sia del client
>>
>> $ cat /etc/openvpn/client.conf
>
> client
> dev tun
> proto udp
> remote 88.253.178.244 1194
> ca ca.crt
> cert client1.crt
> key client1.key
> ns-cert-type server
> comp-lzo
> verb 3
>
>
>
>> $ cat /etc/openvpn/server.conf
>
> local 192.168.222.12
> port 1194
> proto udp
> dev tun
> ca ca.crt
> cert server.crt
> key server.key
> dh dh1024.pem
> server 10.8.0.0 255.255.255.0
> push "route 192.168.222.0 255.255.255.240"
> keepalive 10 120
> comp-lzo
> persist-key
> persist-tun
> verb 3
>
>
> a parte tanta fuffa inutile ho trovato un errore:
> non devi mettere push route redirect gateway insieme a un push route di
> un segmento di rete, il redirect gw instrada TUTTO il traffico
> direttamente sul tunnel, un'altra route e' assolutamente inutile
>
> cosi' dovrebbe funzionare

Grazie, ma non ha il senso del dovere.
Stesso problema. A questo punto, dato che fw sulle macchine Linux non
ce ne sono incomincio a sospettare che c'entri il fw e gateway del vpn
server, che non reinstrada i pacchetti indietro al client. Anzi, direi
che e` proprio cosi` perche' un tcpdump sul server vpn vede passare i
pacchetti verso il default gw 192.168.222.1 dal client vpn, ma non
vede tornare niente indietro.

Andrea Ferraris

---
it seemed like a good idea at the time
Brian Kernighan