Newsgroup: it.comp.os.linux.sys
Titolo: Raggiungere un server remoto dal router IPSEC

Ciao a tutti,
ho questo problemino da risolvere:
- macchina Linux (Squeeze) con due schede di rete che funge da firewall e VPN
IPSEC (oltre che server DHCP e DNS) quindi:
- eth0 (192.168.1.254) è lato LAN
- eth1 (192.168.31.253) è lato Wan
Il default gw è 192.168.31.254 (router Telecom)
Sulla Squeeze ho iptables configurato per far navigare tutta la LAN 
(
192.168.1.0/24
) e collegare questa LAN con una LAN remota (
192.168.22.0/24
) 
tramite IPSEC (Racoon e accessori).
Tutto funziona alla grande (almeno sino adesso.....).
Quello che dovrei fare è questo:
- alla notte collegarmi, da questo router Linux, ad un server Windows sulla
LAN remota, attraverso IPSEC
- montare una directory presente sul server remoto, per esempio in questo modo:
- mount.smbfs //
192.168.22.110/bo
 /mnt -o username="user", password="segreto"
- copiare il contenuto di /mnt in una directory locale
- smontare la directory /mnt
- fine
Se tutto questo dovessi farlo da una macchina della LAN locale non ci
sarebbero problemi, mentre dal router Linux ho difficoltà poiché devo
"forzare" in qualche modo il sistema per raggiungere il server remoto
attraverso il tunnel IPSEC e non dal default gw.
Ho provato ad aggiungere una rotta così:
route add -host 192.168.22.110 gw 192.168.1.254 ma non funziona
e allo stesso modo non funziona (forse ovvio...):
route add -net 
192.168.22.0/24
 gw 192.168.1.254
 
Con iptables, non mi viene in mente niente.
Qualche idea ?
 
grazie
fulvio
 
 

 
 
con iptables potresti magari inventarti qualcosa con prerouting, ma
secondo me e' piu' un problema di routing che non di filtering. 
 
prova con qualcosa del tipo:
ip route add $Net/24 dev $IntName
 
c'e' di mezzo nat/pat/masquerading?
 
-- 
Paolo opg
 
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 route add -host 192.168.22.110 gw 192.168.1.254 ma non funziona
 
Imparare a buttar via 'route' e usare solo 'ip route' sarebbe un primo passo.
 

 c'e' di mezzo nat/pat/masquerading?
 
Questa è la prima cosa di cui accertarsi, ma quel che è necessario comprendere è qual
è il rapporto tra routing e policy ipsec.
 
 
$ ip xfrm policy ls
src 
172.20.0.0/27
 dst 
172.22.0.0/16
 
	dir in priority 0
	tmpl src 95.84.104.134 dst 82.173.205.88
		proto esp reqid 0 mode tunnel
 
src 
172.22.0.0/16
 dst 
172.20.0.0/27
 
	dir out priority 0
	tmpl src 82.173.205.88 dst 95.84.104.134
		proto esp reqid 0 mode tunnel
(gli ip pubblici sono fittizi, non perdeteci tempo. :-D)
 
 
Se dal router stesso su cui osservo queste policy faccio un ping verso 172.20.0.16, lo raggiungo
tranquillamente:
 
$ ping 172.20.0.16
PING 172.20.0.16 (172.20.0.16) 56(84) bytes of data.
64 bytes from 
172.20.0.16
: icmp_seq=1 ttl=63 time=11.2 ms
64 bytes from 
172.20.0.16
: icmp_seq=2 ttl=63 time=16.0 ms
64 bytes from 
172.20.0.16
: icmp_seq=3 ttl=63 time=10.8 ms
 
Il perché lo capisco con ip route:
 
$ ip route get 172.20.0.16
172.20.0.16 via 82.173.205.65 dev vlan53  src 172.22.55.253
    cache  mtu 1500 advmss 1460 hoplimit 64
 
Raggiungo 172.20.0.16 perché ho precedentemente impostato il src giusto.
Non bisogna affatto cambiare gateway, ma source, cioè scegliere con quale indirizzo
ci si vuol presentare quando voglio parlare con 
172.20.0.0/27
 (e verificare poi che non venga applicato
alcun nat)
In precedenza avrò probabilmente scritto qualcosa del genere
ip route add 
172.20.0.0/27
 via 82.173.205.65 src 172.22.55.253
 
Con questo accorgimento, quando mando un pacchetto a 172.20.0.16, lo mando con sorgente 172.22.55.253, a valle delle
decisioni di routing il sottosistema ipsec "vede" una sorgente e una destinazione che rientrano nelle policy previste e incapsula
i pacchetti.
 

 c'e' di mezzo nat/pat/masquerading?
 
Sì, eccolo:
 
iptables -t nat -A POSTROUTING -s 
192.168.1.0/24
  ! -d 
192.168.22.0/24
 -j 
MASQUERADE
 
Ed è qui forse che non è corretto o comunque non sufficiente.
Ora provo delle varianti a questa sopra e vedo se riesco.
 
Grazie
fulvio
 

 nelle policy previste e incapsula i pacchetti
 
Mille e mille grazie.
fulvio

 Ora provo delle varianti a questa sopra e vedo se riesco.
 
No, non centra un tubo, vedi la mia risposta sopra a whiplash.
 
 

 No, non centra un tubo, vedi la mia risposta sopra a whiplash.
           c'entra
 
 

           c'entra
 
"(e verificare poi che non venga applicato alcun nat)" :-)