Re: vpn in cui mi fermo appena arrivato
Il giorno 11 giugno 2009 15.16, gisto85<gisto85@yahoo.it> ha scritto:
> Ciao, verifica se il kernel fa il ipforward dei pacchetti
>
> cat /proc/sys/net/ipv4/ip_forward in caso di 0 prova ad abilitarlo con
>
> echo 1 >> /proc/sys/net/ipv4/ip_forward
>
>
> 2009/6/11 Alessandro T. <tagliare3@yahoo.it>
>>
>> pac ha scritto:
>> > server pptp
>> > Destination Gateway Genmask Flags Metric Ref Use
>> > Iface
>> > 10.33.0.0 0.0.0.0 255.255.255.0 U 0 0 0
>> > eth0
>> > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0
>> > lo
>> > 0.0.0.0 10.33.0.60 0.0.0.0 UG 0 0 0
>> > eth0
>> >
>>
>> il server non sa come "routare" i pacchetti destinati al pc-casa, quindi
>> dovresti provare con un `route add -net 192.168.1.0 netmask
>> 255.255.255.0 gw 192.168.1."pc-casa" dev ppp0` ipotizzando che anche sul
>> server l'interfaccia ppt sia ppp0 .
>>
>> > Casa
>> > Destination Gateway Genmask Flags Metric Ref Use
>> > Iface
>> > 98.96.153.384 192.168.1.200 255.255.255.255 UGH 0 0 0
>> > eth0
>> > 10.33.0.139 0.0.0.0 255.255.255.255 UH 0 0 0
>> > ppp0
>> > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
>> > eth0
>> > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0
>> > ppp0
>> >
>> >
>>
>> questa tabella è un po bruttina ;-)
>> toglierei la seconda `route -del host 10.33.0.139 netmask
>> 255.255.255.255 dev ppp` e la quarta `route -del net 0.0.0.0 netmask
>> 0.0.0.0 dev ppp0`.
>>
>> aggiungerei `route -add net 0.0.0.0 netmask 0.0.0.0 gw 192.168.1.200 dev
>> eth0` per la navigazione classica, così non sei costretto a passare per
>> il tunnel.
>>
>> e ancora `route -add net 10.33.0.0 netmask 255.255.255.0 gw 10.33.0.139
>> dev ppp0` per poter raggiungere la rete remota.
>>
>> a questo punto, se non ho commesso errori, dovresti riuscire a pingare
>> dal pc-casa il server e viceversa.
>>
>> se non dovessi riuscire a pingare dal pc-casa le altre macchine della
>> rete remota dovresti aggiungere sul server `iptables -t nat -A
>> POSTROUTING -j MASQUERADE`
>>
>> spero di non aver commesso grossi errori.
>>
>> > L'indirizzo pubblico è stato da me modificato per ovvi motivi.
>> > Però da stamattina nonostante da quando ci siamo sentiti l'ultima
>> > volta non ho toccato neppure il computer, una volta collegato
>> > non mi si collega più a Internet.
>> >
>>
>> cioè non navighi? se è così è perchè tutto il tuo traffico passa per il
>> tunnel che non ha una "rotta inversa" per i pacchetti di risposta.
>>
>> Ciao
>> Ale
Ci sono però alcune cose che non mi sono chiare e altre che volevo specificare.
Prima di partire in tromba per seguire le tue istruzioni ho voluto
fare punto e a capo mi sono ricollegato e rifatto route -n
e a questo punto ho trovato quanto segue che differenzia da quanto ti
ho comunicato questa mattina
SERVER pptpd
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.33.0.250 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.33.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 10.33.0.60 0.0.0.0 UG 0 0 0 eth0
Mentre a casa trovo la stessa tabella di questa mattina ovvero :
98.96.153.384 192.168.1.200 255.255.255.255 UGH 0 0 0 eth0
10.33.0.139 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
La riga che mi dici di togliere dove troviamo 10.33.0.139 deriva dal
pptpd.conf del server dove troviamo queste due righe :
localip 10.33.0.139
remoteip 10.33.0.250-252
Nel server infatti troviamo con ifconfig un ppp0 così
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.33.0.139 P-t-P:10.33.0.250 Mask:255.255.255.255
mentre a casa trovo con ifconfig un ppp0 così
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.33.0.250 P-t-P:10.33.0.139 Mask:255.255.255.255
Visto anche il route -n diverso del server che ho messo all'inizio
vado avanti comunque con le stesse istruzioni ?
Scusa se ti rompo ancora :-)
Reply to: