lonely wolf wrote: > > > 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 > multumesc pentru raspunsuri. o sa merg in continuare pe varianta b. pe mine nu configurarea initiala ma deranjeaza ci modificarile dese ale structurii retelei. si modificarile trebuiesc facute foarte rapid. in total sunt aprox. 70 locatii si vor fi in curand 120. deja sunt puncte in care reconfigurarea tunelelor dureaza 2-3 ore.
laurentiu
