Florin Veres wrote:
> ruta spre c din a inspre b, si din c spre a prin b nu merge?
>
> Florin
>
> On 8/25/05, Laurentiu Roescu <[EMAIL PROTECTED]> wrote:
>
>>am trei locatii a --- b --- c si am tunele ab si bc.
>>vreau sa conectez a cu c dar eu am garantari punct la punct deci trebuie
>>sa treaca prin b.
>>tunelele sunt facute cu freeswan 2.x, kernel 2.4.
>>se poate face lucrul asta fara sa mai ridic tunele suplimentare?
>>
tunelele in freeswan/openswan au o caracteristica suplimentara celorlalte
(gre,ipip): fac si o validare a pachetelor pe baza sursei si destinatiei,
astfel incit prin tunel NU TREC decit pachete care corespund unei descrieri de
tunel din ipsec.conf. Ca atare artificii de tipul
ip r a O.RUTA.OARE.CARE dev ipsecN
sau variatiuni pe tema data NU functioneaza.
Pentru problema lui Laurentiu exista 2 solutii
a) tunelele care descriu conexiunile a-b, respectiv b-c sa fie astfel concepute
incit pachetele care au sursa a si dest c (si invers) sa fie acceptate si ele.
Aceasta ar presupune gruparea claselor din A, respectiv C cu clasa din B.
Spre pilda, daca ai 192.168.0.0/24 in A, 192.168.1.0/24 in B si
192.168.2.0/24 in C, teoretic ai putea face tunele la modul urmator:
-- varianta curenta:
pe A:
conn AB
leftsubnet=192.168.0.0/24
rightsubnet=192.168.1.0/24
pe B
conn AB
leftsubnet=192.168.0.0/24
rightsubnet=192.168.1.0/24
conn BC
leftsubnet=192.168.2.0/24
rightsubnet=192.168.1.0/24
iar pe C, evident
conn BC
leftsubnet=192.168.2.0/24
rightsubnet=192.168.1.0/24
-- varianta noua:
pe A:
conn AB
leftsubnet=192.168.0.0/24
rightsubnet=192.168.0.0/23 <--- ca sa includa si clasa din C
pe B
conn AB
leftsubnet=192.168.0.0/24
rightsubnet=192.168.0.0/23
conn BC
leftsubnet=192.168.2.0/24
rightsubnet=192.168.0.0/23 <--- ca sa includa si clasa din A
iar pe C, evident
conn BC
leftsubnet=192.168.2.0/24
rightsubnet=192.168.0.0/23
NU garantez ca merge, data fiind suprapunerea claselor.
La un experiment rapid (adica a durat <2 min intrucit descrierea de tunel am
luat-o cu copy/paste de mai sus) facut acum 30 de sec, un tunel descris ca in
conn BC de mai sus s-a ridicat fara greturi.
b) cu tunele suplimentare:
pe A:
conn AB
leftsubnet=192.168.0.0/24
rightsubnet=192.168.1.0/24
conn AC
leftsubnet=192.168.0.0/24
rightsubnet=192.168.2.0/24
pe B:
conn AB
leftsubnet=192.168.0.0/24
rightsubnet=192.168.1.0/24
conn AC
leftsubnet=192.168.0.0/24
rightsubnet=192.168.2.0/24
conn BC
leftsubnet=192.168.2.0/24
rightsubnet=192.168.1.0/24
conn CA
leftsubnet=192.168.2.0/24
rightsubnet=192.168.0.0/24
pe C;
conn BC
leftsubnet=192.168.2.0/24
rightsubnet=192.168.1.0/24
conn CA
leftsubnet=192.168.2.0/24
rightsubnet=192.168.0.0/24
Stiu ca varianta b) nu e raspunsul dorit la intrebare, dar tunelele sint
ieftine. asa ca nu costa mai nimic, se pot ridica din mers (for i in AC CA; do
ipsec auto --add $i && ispec auto --up $i;done) si merg sigur, indiferent cum
arata clasele (care e posibil sa nu poata fi grupate)(experimentul de mai sus a
fost facut pe un ruter care are deja vreo 15 tunele functionale. Plus ca, dupa
cum spuneam, in anumite configuratii e posibil ca lui freeswan sa nu ii convina
perechile --sau mai bine zis imperecherile -- de clase. Sau sa nu iti convina
cum se imperecheaza. In situatia de mai sus de exemplu am fost obligat sa
includ si clasa 192.168.3.0/24. Intimplator acum nu e folosita ... dar ar putea
fi. Iar daca un istet va pune un IP din aceasta clasa pe undeva (in oricare
dintre sedii), va avea acces prin tunel (evident , daca un firewall pe parcurs
nu blocheaza clasa 'intrus').
Eu unul as mege pe principiul KISS si as implementa in productie varianta b.
Are avantajul ca iti lasa totala libertate de miscare in alegerea claselor din
A si C (in limitele impuse de freeswan/openswan, desigur) si ca poti face
ulterior modificari fara sa iti pese de ceea ce se intimpla in B. Ceea ce nu e
deloc neglijabil daca la un moment oarecare in viitor ai de facut extinderi /
renumerotari ale retelelor. Plus ca poti face experimente fara sa strici
tunelele existente a--b si b--c
--
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
