基於openswan klips的IPsec實現分析之數據發送
轉載請註明出處：http://blog.csdn.net/rosetta
Klips是openswan自帶實現IPsec功能的模塊，其主要實現數據加解密、安全關聯、密鑰管理、身份認證等功能，並以.ko模塊插入到內核中運行。
Klips對外出數據的處理流程如下：
相關函數調用過程如下:
ipsec_tunnel_start_xmit()
->ipsec_xmit_encap_bundle()
->ipsec_sa_getbyid()//獲取sa
->ipsec_xmit_encap_once()
->ipsec_alg_esp_encrypt()
->struct ipsec_alg_enc *ixt_e=sa_p->ips_alg_enc
->ixt_e->ixt_e_cbc_encrypt()//真正的加密處理
//此加密函數指針是在ipsec_xmit_encap_bundle()中獲取sa後賦的值。
// ixt_e=ixs->ipsp->ips_alg_enc;
->ipsec_tunnel_send()//發送數據
下面詳細分析從模塊初始化到數據加密發送的整個過程。
模塊加載時ipsec_klips_init()執行初始化工作，此函數主要包括以下內容：ipsec_proc_init()創建proc文件系統與用戶層交換數據，ipsec_sadb_init()初始化SADB，ipsec_radijinit()初始化SPDB(即eroute策略), pfkey_init()初始化與用戶層通信的PF_KEY套接字, ipsec_tunnel_init_devices()創建ipsec虛擬網卡，ipsec_alg_init()註冊可用的加密算法(3des,aes等)，openswan_inet_add_protocol()增加ESP、AH、COMP支持。
ipsec_tunnel_init_devices()創建ipsec虛擬網卡時會由註冊發送數據包處理函數ipsec_tunnel_start_xmit()，那麼這個函數就是klips發送數據（加密）的核心部分。此函數裏的ipsec_xmit_sanity_check_dev()對網卡設備狀態檢測，其中會判斷物理網卡是否已和虛擬網卡綁定，這兩者的綁定是需要由用戶層通過tncfg命令完成的； ipsec_xmit_sanity_check_skb()檢測skb數據包狀態，比如確保skb是一份拷貝的數據而不是原始數據，能支持的IP協議版本的判斷等；ipsec_tunnel_strip_hard_header()獲取鏈路層幀頭，並去掉幀頭獲取網絡層IP數據；ipsec_tunnel_SAlookup()查找是否有相應的SA，即比對目的IP、SPI、協議（said，所謂的三元組）；經過前面處理都正常的話就走到ipsec_xmit_encap_bundle()函數。
ipsec_xmit_encap_bundle()函數會根據SPI來決定數據包的去向：SPI_DROP、SPI_REJECT、SPI_PASS等(實際應用中沒遇到過？)，ipsec_sa_getbyid()由said查找SA放在ixs->ipsp中，接着第一次遍歷ixs->ipsp，判斷SA狀態是否有效，根據proto的值分別對AH、ESP、COMP、IPIP進行處理，主要是預留空間，如果是IPIP隧道模式和AH僅是分別留一個IP頭和AH頭大小的空間，如果是ESP那麼會把相應的加密函數取出。再一次遍歷ixs->ipsp，在ipsec_xmit_encap_once()中分別對proto的值做處理，這裏對之前預留出的空間填入對應的數據，比如IP頭，ESP頭或者AH頭等，並且對需要加密的原始數據進行填充，因爲加密前的數據長度需要等於算法分組長度的整數倍。
到這裏才由ipsec_alg_esp_encrypt（）對數據加密，並由ixs->ipsp->ips_authalg的值使用對應的哈希算法對數據做認證並把哈希值加到數據包尾部，如果是IPCOMP還會調用相關壓縮函數處理數據，最終由ipsec_tunnel_send()經物理口發出。