Veniamo al sodo. E' un problema banale di routing se vogliamo, ma non ne usciamo.
Ho un primo apparato, che fa un casino di cose, ma del quale in questa fase mi interessa solo la sua int Gi2/43. Questa interfaccia ha indirizzo 192.168.13.150 su una sottorete 192.168.0.0/20
Questa interfaccia deve raggiungere (e deve essere raggiunta) da un'altra sottorete (geograficamente distante) 172.18.16.0/20.
Per connettere queste 2 sottoreti si deve usare una connettività Fastweb nata con altri scopi e che connette parzialmente le reti. Spiego meglio.
Io sono l'azienda A, poi c'è l'azienda B che è quella con l'indirizzamento 192.168.0.0/20 e poi c'è l'azienda C con l'indirizzamento 172.18.16.0/20.
L'azienda B, ha al suo interno un PIX con 3 interfacce, la prima è 192.168.8.1 collegata appunto sulla 192.168.0.0/20, la seconda va all'esterno su una VPN verso l'azienda C (interfaccia 10.10.60.4) e la terza va verso una sottorete "server" 10.10.50.0/24.
La VPN tra l'azienda B e l'azienda C è stata creata per connettere la rete 172.18.16.0/20 dell'azienda C con la sottorete "server" 10.10.50.0/24 dell'azienda B. Il router presente nell'azienda C, il 172.18.31.254 conosce infatti le rotte solo per la 10.10.50.0/24 e non va da altre parti.
Ora, come in una sorta di film dell'enigmista, noi dobbiamo connettere l'azienda A con l'azienda C senza chiamare però Fastweb
Ok. Da parte mia ho fatto le cose facili, facili, banali, banali. Sull'apparato che connette la rete dell'azienda A (la mia) con la rete dell'azienda B ho detto chiaro chiaro che la rete 172.18.16.0/20 si raggiunge tramite 192.168.8.1
ip route 172.18.16.0 255.255.240.0 192.168.8.1
La cosa è facile facile, anche perché è proprio questo apparato ad avere l'interfaccia Gi2/43 con indirizzo 192.168.13.150.
Quindi ho fatto fare un primo test. PC posto nella rete C con indirizzo 172.18.16.1, wireshark a bordo del pc, registrazione del traffico ICMP e via di ping dal mio apparato. Risultato: il ping non va (ovviamente), ma vedo l'echo request su wireshark. Ne deduco che il problema è chiaramente il "ritorno" dell'echo reply.
Ora non potendo chiamare Fastweb per far fare la cosa più ovvia (ovvero insegnare al router nell'azienda C la rotta verso la 192.168.0.0/20), dobbiamo inventarci qualcosa.
Da alcuni test risulta che l'interfaccia del PIX dell'azienda B sulla VPN, con indirizzo 10.10.60.4 è raggiungibile dalla rete C. E' stato provato allora a fare questo: si è preso un client e si è aggiunta una rotta statica a questo client in questo modo:
Client1
IP: 172.18.16.1
SM: 255.255.240.0
GW: 172.18.31.254
route add 192.168.0.0 mask 255.255.240.0 10.10.60.4
la cosa non funziona. Nella route table infatti questa rotta ha la stessa metrica (1) della rotta predefinita, ma 10.10.60.4 è chiaramente irrangiungibile da 172.18.16.1
si è provato allora a fare route add 192.168.0.0 mask 255.255.240.0 10.10.60.4 metric 20 (ma anche 40, 50, ecc.)
ma non funziona lo stesso.
Consigli? Idee? Nuovi sistemi per martellarsi le palle alla Tafazzi?
Grazie anyway
giaconet
---EDIT---
Piccolo schema per capire meglio
