[gl-como] Problemi di routing
Riccardo (SCASI)
r.penco@scasinet.com
Lun 27 Apr 2009 10:36:36 CEST
pirla ha scritto:
> Il giorno dom, 26/04/2009 alle 19.55 +0200, Incubus ha scritto:
>>> Mancano ancora le route dei client
>> Eccole:
> Bene, allora non ci resta che seguire il pacchetto di ping e vedere cosa
> gli succede:
>
>> == lan client @ VPN SERVER ==
>> IPv4 Tabella route
>> ===========================================================================
>> Route attive:
>> Indirizzo rete Mask Gateway Interfaccia Metrica
>> 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.187 20
>> 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
>> 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
>> 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
>> 192.168.1.0 255.255.255.0 On-link 192.168.1.187 276
>> 192.168.1.187 255.255.255.255 On-link 192.168.1.187 276
>> 192.168.1.255 255.255.255.255 On-link 192.168.1.187 276
>> 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
>> 224.0.0.0 240.0.0.0 On-link 192.168.1.187 276
>> 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
>> 255.255.255.255 255.255.255.255 On-link 192.168.1.187 276
>> ===========================================================================
>> Route permanenti:
>> Nessuna
>
> partiamo da questo PC e pinghiamo un indirizzo dell'altra LAN
> (192.168.51.28 per esempio).
> Il S.O. vede che l'IP di destinazione è su un'altra sottorete e quindi
> lo passa al default gateway, perché non sa come trattare gli ip della
> rete 192.168.51.x/24
> Il def. gateway è 192.168.1.1 che presumo sia il router e non il server
> VPN.
>
>> Faccio presente che sul gateway di questa lan ho impostato 2 route per
>> la classe 10.0.0.0/24 e 192.168.51.0/24 che redirigono i pacchetti a
>> 192.168.1.2 (vpn-server): di seguito lo stralcio di cfg inerente le
>> route sul gateway:
>>
>> Hellgate#show running-config | s route
>> ip source-route
>> ip route 0.0.0.0 0.0.0.0 Dialer0
>> ip route 10.0.0.0 255.255.255.0 192.168.1.2
>> ip route 192.168.51.0 255.255.255.0 192.168.1.2
>> Hellgate#
> Il pacchetto arriva al GW, il quale vede che la rotta giusta per
> 192.168.51.x/24 è quella di girare il pacchetto a 192.168.1.2 (che
> stavolta è il server vpn).
>
> Il server VPN ha le rotte (le prendo dalla vecchia mail)
> pribnowbox incubus # route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
> 10.0.0.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
> 192.168.1.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 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
>
> Quindi il server vede il pacchetto per la 192.168.51.x e dovrebbe
> mandarlo al default gateway perché non ha una rotta per la rete
> secondaria.
> Qui però dovrebbe intervenire prima il masquerading, che cambia il
> pacchetto in funzione delle due regole di masquerading. Ma come viene
> mascherato il pacchetto?
tieni presente che il mascheramento cambia _l'indirizzo_di_sorgente_ e
non quello di destinazione.
Se ho interpretato correttamente in questo caso il server rimbalza il
pacchetto al router che lo rimbalza al server e così via fino a che il
ttl arriva a zero, poi il pacchetto è scartato
>
> Qui mi fermo perché non so come vengono applicate le regole di
> masquerading in questa situazione, ma seguendo questa logica puoi vedere
> esattamente il pacchetto che strada fa (o meglio dovrebbe fare).
>
> Per seguire un po' se e come funziona questo giochino, usa traceroute a
> tutti i livelli e usa tcpdump (con gli opportuni filtri) per tracciare e
> seguire i pacchetti e scoprire dove si fermano o dove vanno in loop.
>
> Prova ancora e se hai bisogno scrivi in privato che magari facciamo
> insieme qualche prova. Oggi ho un po' di tempo a disposizione.
Maggiori informazioni sulla lista
gl-como