IPsec 上的 GRE 隧道與環回
我很難嘗試使用 GRE over IPsec 隧道建立 VPN 連接。問題是它涉及某種我不理解的“環回”連接——更不用說能夠配置了——而且我能找到的唯一幫助與配置 Cisco 路由器有關。
我的網路由一台路由器和一台執行 Debian Linux 的主機組成。我的任務是在 IPsec 基礎設施上創建一個 GRE 隧道，該隧道專門用於在我被允許配置的網路和遠端網路之間路由多播流量，我只為遠端網路提供一個包含一些設置資訊（IP IPsec 的地址和階段資訊）。目前，在這台主機和遠端網路之間建立通信就足夠了，但將來希望將流量路由到我網路上的其他機器。
正如我所說，這個 GRE 隧道涉及一個“環回”連接，我不知道如何配置。根據我之前的理解，環回連接只是一個本地偽設備，主要用於測試目的，但在這種情況下，它可能是我不知道的更具體的東西。
racoon我已經設法使用和正確建立 IPsec 通信ipsec-tools，並且我相信我熟悉創建隧道和使用 向介面添加地址ip，因此重點是 GRE 步驟。最糟糕的部分是遠端對等方不響應 ping 請求，並且由於流量的加密性質，一般設置的調試非常困難。涉及到兩對 IP 地址：一對用於 GRE 隧道對等連接，另一對用於“環回”部分。還涉及一個 IP 範圍，它應該是 VPN 內主機的最終 IP 地址。
我的問題是：如何（或是否）可以完成此設置？我是否需要一些特殊的軟體或其他守護程序，或者 Linux 核心是否處理 GRE/IPsec 隧道的各個方面？
如果有任何額外的資訊有用，請通知我。
任何幫助是極大的讚賞。
再一次，我設法解決了這個問題（但不會像原來的問題和這個答案那樣持續太久：）。我已經花了將近一個月的時間來研究這個問題的解決方案，我會把它記錄在這裡，以防萬一有人碰巧遇到同樣的問題。
實際上，環回介面實際上就是我所知道的：分配給機器上一個虛擬的、始終處於執行狀態的介面的地址。遠端 GRE 路由器和我的路由器之間的連接問題是由於另一個問題：GRE 保持活動數據包。
事實證明，遠端 Cisco 路由器實際上是通過隧道向我發送奇怪的 GRE 封裝數據包。這些數據包封裝了另一個GRE 數據包，另一方面，這些數據包攜帶的協議號為零。快速瀏覽表明這些數據包是GRE keep-alive 數據包，它們是定期發送的（在我的情況下，幾乎每 10 秒一次），如果對等方正確解封裝和重新路由，則應回顯給發送者，因為最裡面的目標地址包含發件人的源地址。
事實是 Linux 核心沒有正確地將解封裝的 keep-alive 數據包再次輸入到路由鏈中。如果是這樣，數據包將被重新路由回發送者，而不會產生進一步的複雜性。相反，它將數據包傳遞給使用者空間，因此可以編寫一個簡單的程序以原始模式監聽這些數據包，並將它們回顯給發送者。執行這個程序並將幾個數據包回傳到 Cisco 路由器，GRE 隧道在遠端端“啟動”，PIM 路由器交換了
hellos，我終於可以收聽我希望收聽的多播流量。我從這次經歷中學到了很多東西，特別是在處理晦澀難懂的協議（或者至少是晦澀難懂的協議特性）時，你不能簡單地指望同行知識。在這方面，沒有任何一位遠端網路分析師可以在任何方面幫助我，可能是因為這種行為沒有記錄在案。