一、背景
在ipsec VPN的驗證過程中發現公網網口會有內網數據數據包的現象，需要進一步分析為什么內網數據包會在公網網口。
二、驗證網絡拓撲和數據分析
1、網絡拓撲如下，并部署對應的ipsec vpn (strongswan)
VM1上VPN策略為：
2、從VM1的NS中ping VM2的NS，模擬兩個內網通過ipsec vpn互通
1）此時在VM1和VM2的eth1公網網口抓包發現，數據包除了公網的ESP報文外，也有以解封裝的內網報文，且內網報文都是收方向的報文
VM1的eth1抓包：
VM2的eth1抓包：
理論上公網接口應該只有ESP的公網報文才對，不應該有內網報文，進一步查看netfilter的日志看看怎么回事
2）Netfilter的日志
VM1的netfilter日志：
VM2的netfilter日志：
通過netfilter日志分析發現，ESP公網數據包在經過PREROUTING和INPUT鏈之后，數據包解封裝，之后的原始內網數據包確實又經過了PREROUTING和FORWARD進行轉發，難道這個ESP數據包在解包后又回到了公網網卡，理論上不應該，要進一步查看ipsec VPN的原理和機制。
三、IPsec VPN的網絡原理分析
1、IPSEC 和 XFRM
IPsec協議幫助IP層建立安全可信的數據包傳輸通道。當前已經有了如StrongSwan、OpenSwan等比較成熟的解決方案，而它們都使用了Linux內核中的XFRM框架進行報文接收發送。
由此可見IPSEC實現的基礎是內核的XFRM，XFRM框架接受IPSEC報文的流程如下：
從整體上看，IPsec報文的接收是一個迂回的過程，IP層接收時，根據報文的protocol字段，如果它是IPsec類型(AH、ESP)，則會進入XFRM框架進行接收，在此過程里，比較重要的過程是xfrm_state 1ookup(),該函數查找SA，如果找到之后，再根據不同的協議和模式進入不同的處理過程，最終，將原始報文的信息獲取出來，重入ip_local_deliver().然后，還需經歷XFRM Policy的過濾，最后再上送到應用層。
這里的流程是ESP報文在解包后送到應用層的過程，而該示例中的數據包是需要進一步轉發，需要看看XFRM和Netfilter有什么關聯性。
2、XFRM和Netfilter
從Netfilter的框架圖中可以看到ESP數據包在經過INPUT鏈后，會進行decode的解包，此時解包之后會clone原始數據包發送到接收網卡，這里是公網網卡，從而把原始數據包再一次經過netfilter并做路由，因此可以看到公網收方向不僅有ESP的公網報文也有原始內網報文。
實際從圖中看到XFRM的decode之后有兩條路線，一條是直接到netfilter，一條是clone到網卡，因為tcpdump抓包是在網卡數據包進入netfilter之前，而抓包又抓到了原始內網報文，因此應該走的是clone到網卡的路線。
