Ratiu Petru wrote:
On 12/9/05, Vali Dragnuta <[EMAIL PROTECTED]> wrote:
chiar nu e configurabila kestia asta ?
Ba da, vezi postul meu. Nu e windozarie. ipsec trebuie sa
stie ce impacheteaza si ce nu, altfel ai putea risca sa incerce sa-ti
impacheteze orice pachet (inclusiv alea pentru internet) si sa le faca
vint prin tunel in partea ailalta,ceea ce nu ar fi corect.
Desigur, poti oricind sa definesti rightsubnet mai "larg" sau chiar sa
pui rightsubnet 0.0.0.0
daca faci asta isi inchipuie ca e ruta default si arunca TOT traficul pe acolo.
merge, dar unica utilitate pe care o vad e cind ai un tunel intre ruterele A si
B si vrei ca reteaua din spatele lui B sa aiba ruta default PRIN tunel
(asta nu am incercat pina acum)
am facut-o eu. aveam o conexiune remote cu banda internet minima posibil (nimic
garantat) dar cu banda garantata pina la sediul central din bucuresti (care
avea banda internationala relativ mare). Tot traficul statiilor din reteaua
remote era adus prin tunel in bucuresti, de unde era apoi expediat inspre
marele internet
insa cu 0.0.0.0
s-ar putea sa se confuzeze putin si sa incerce sa impacheteze chiar
pachetele pentru celalalt vpn router...
ney. depinde cum definesti. logica mai completa (freeswan/openswan style) e asa
prevede posibilitatea a 4 tunele DISTINCTE
a) router A - router B
b) router A - reteaua din spatele lui B
c) reteaua din spatele lui A - router B
d) reteaua din spatele lui A - reteaua din spatele lui B
Nici unul dintre tunelele de mai sus nu se suprapune cu vreunul dintre
celelalte (prin router A resp B am inteles IP-ul public)
e ca si cum ai incerca sa iti
bagi tunelul in..propriul tunel (gindeste-te la un furtin caruia ii bagi
un capat in celalalt capat si apoi incepi sa impingi).
mai fain ar fi sa fie banda lui Moebius :))
Din ce stiam, kernelul consulta tabela de routare incepand cu rutele
cele mai specifice, asa ca daca ii dai o ruta explicita spre capatul
tunelului via interfata ethernet, o sa trimita pachetele de ipsec pe
acolo, si restul via interfata ipsec , adica la impachetare.
Ma rog, asta o spun din burta, n-am la indemana vreun sistem pe care
sa pot testa repede.
fenomenul e asa:
[EMAIL PROTECTED] ~]# ip r l |grep 192.168.30
192.168.30.0/26 via 82.208.174.129 dev eth3
[EMAIL PROTECTED] ~]# ip r get 192.168.30.0
192.168.30.0 via 82.208.174.129 dev eth3 src 82.208.174.130
cache mtu 1500 advmss 1460 metric10 64
in timp ce dau un ping care o ia prin tunel, pe interfata eth a ruterului se
pot observa atit pachetele incapsulate:
[EMAIL PROTECTED] ~]# tcpdump -i eth3 esp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 96 bytes
23:07:16.864254 IP nobug-fo.b.astral.ro > bv-er2-fe0-0.nobugconsulting.ro:
ESP(spi=0x554f5ce3,seq=0x1173)
23:07:16.877629 IP bv-er2-fe0-0.nobugconsulting.ro > nobug-fo.b.astral.ro:
ESP(spi=0xb37e423e,seq=0x104d)
23:07:17.864942 IP nobug-fo.b.astral.ro > bv-er2-fe0-0.nobugconsulting.ro:
ESP(spi=0x554f5ce3,seq=0x1174)
cit si cele NEincapsulate:
23:11:25.088330 IP router5 > wolfy: icmp 64: echo reply seq 53
23:11:25.995254 IP router5 > wolfy: icmp 64: echo reply seq 54
23:11:26.999366 IP router5 > wolfy: icmp 64: echo reply seq 55
23:11:27.996923 IP router5 > wolfy: icmp 64: echo reply seq 56
cel mai haios mi se pare ca pachetele echo-request NU se vad, doar reply-urile
:))
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
