Sledovani IPSec tunelu

[David Rohleder]

David Rohleder <davro na ics.muni.cz> writes:

> 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].

Tak podle vseho je to znama "interoperability issue". Reseni je
jednoduche, v SPD misto zaklinadla require se musi pouzit zaklinadlo
unique. Vypada to, ze se to opravdu rozjelo. Akorat jsem nad tim
nemusel sedet cely den :-(

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