Sledovani IPSec tunelu

[David Rohleder]

Michal Kubecek <mike na mk-sys.cz> writes:

> On Wed, Sep 22, 2004 at 01:34:13PM +0200, David Rohleder wrote:
>> 
>> mam drobny problemek s IPSec tunelem v novych jadrech 2.6 (nativni
>> implementace + KAME racoon). Potreboval bych vedet jakym zpusobem mohu
>> zjistit, ze paket skutecne vlezl do tunelu. Ve FreeS/WAN to bylo
>> jednoduche, stacilo si dat tcpdump na ipsec0. V nove implementaci
>> tento interface neni, takze bych potreboval vedet, nejakou metodu
>> alespon priblizne stejnou jako je pouziti tcpdump -i ipsec0
>
> Asi tak před půl rokem jsme to tady rozebírali. Výsledek byl takový, že
> je-li použit transport mode, vidíte pouze "nosné" (ESP) pakety. Jde-li o
> tunnel mode, vidíte u netfilteru v INPUT (OUTPUT) "nosné" (ESP) pakety a
> ve FORWARD ty "přenášené". Podobně je to v případě tcpdump (na vnějším
> rozhraní nosné, na vnitřním přenášené).

Jasne, to je naprosto pochopitelne chovani. Trochu jsem to zkoumal dal
a vypada to, ze kernel s racoonem pouzije jiny tunel nez by mel a
posle to do nej. FreeS/WAN na druhe strane to pozna a samozrejme ten
paket potom zahodi, protoze k nemu prisel pres spatnou SA. FreeS/WAN
rika:

 klips_debug:ipsec_rcv: SA:tun0x1025 na A.B.C.D, inner tunnel policy
 [192.168.6.0/24 -> E.F.G.H/29]
 does not agree with pkt contents [192.168.6.120 -> 192.168.1.252].


Tedy predpokladam, ze se paket chova nasledovne: prijde do smerovace,
tam se podle SPD nasmeruje na spravne SA a podle informaci v SA se
zasifruje (mezitim samozrejme projde routovanim a NATovanim).

Pokud mam jen jeden tunel, tak je to v pohode - jadro se nemuze splest
:-)

>
> Když jsem to ale zkoušel před pár dny, viděl jsem pomocí tcpdump i u
> transport modu vnitřní pakety, ale poničené - v pořádku byl jen samotný
> začátek hlavičky. Zkoušel jsem hledat na webu, ale našel jsem jen nějaké
> zmínky o tom, že je údajně zcela v pořádku, že jádro nechá na stacku
> "trosky" rozbaleného paketu a tcpdump je hloupý, že si jich všímá.
> Nějak se mi to nezdá, ale zdálo se, že autor toho příspěvku ví, o čem
> mluví.
>
>> Vsechno se totiz tvari v poradku SA i SPD jsou na svych mistech,
>> akorat paket nevyleze na druhe strane z tunelu - tak nevim, jestli do
>> nej vubec vleze. Na druhe strane je FreeS/WAN, takze tam si muzu dat
>> tcpdump -i ipsec0
>
> Především vyzkoušejte, jestli při odeslání (jakéhokoli) paketu tunelem
> odejde vůbec nějaký ESP paket (z vnějšího rozhraní) a jestli _tentýž_
> (co do IP adres zdroje a cíle) paket dorazí na druhou stranu. Je to
> mrtvé v obou směrech nebo jen Kame -> FreeS/WAN?
>

Mrtve pouze ve smeru Kame -> FreeS/WAN. Ping v klidu projde z jedne
strany az k cili, cil odpovi, ale uz se nedostane pres IPSec.

> Taky si zkontrolujte, jestli se náhodou na ty pakety, které jdou tunelem
> neaplikuje NAT; s tím jsem si taky pěkně naběhl, ladil jsem to asi půl
> hodiny, než jsem přišel na to, co se vlastně děje... :-)

Ty brany delaji NAT, ale jsem si jisty, ze se na tunelovane pakety
NATovaci pravidla nevztahuji.(zapnul jsem si logovani do iptables).

Zatim to vypada tak, ze na eth0 FreeS/WAN doleze paket se spatnym SPI
a tim padem ho uz pak nevidim pomoci tcpdumpu na ipsec0.



-- 
-------------------------------------------------------------------------
David Rohleder						davro na ics.muni.cz
Institute of Computer Science, Masaryk University
Brno, Czech Republic
-------------------------------------------------------------------------