Openvpn

將一個介面轉換為隧道介面

  • October 16, 2019

我有一台帶有 2 個 WAN 介面的伺服器,eth1並且eth2. 每個人都有一個連接的路由器,它為他們提供這些 IP:192.168.3.101192.168.1.101.

問題是我想完全避免流量通過eth1,而是創建一個tun0隧道,所有流量eth1都應該接收。

我可以完全控制我的程序應該使用哪個介面(MPTCP 將使用它可以訪問伺服器的所有介面),所以我準備了一個簡單的 OpenVPN 客戶端/伺服器配置(綁定到local 192.168.3.101),帶有伺服器 IP192.168.99.1和客戶端 IP 192.168.99.2。有了這個我有一個工作界面,我可以192.168.99.1毫無問題地發送/接收數據。

現在,當我想ifconfig.co使用 interface 向(例如)發送/接收數據時,問題就來了tun0。我雖然它會做的是將數據發送eth1到我的伺服器,然後我的伺服器將流量重定向到ifconfig.co,但這不是正在發生的事情。它只是斷開連接:

連接被拒絕

如果我嘗試使用介面eth1並且eth2一切都按預期工作。

我已經不間斷地閱讀/嘗試了很多東西大約 7 個小時,現在我真的迷路了。我不確定發生了什麼或我做錯了什麼。

我認為是路由問題,因為當我嘗試 tcpdump 上面的命令時,伺服器上什麼也沒有顯示。收到零個數據包。這就是我現在所擁有的:

在此處輸入圖像描述

在此處輸入圖像描述

在此處輸入圖像描述

我看到一切都彼此平等,但是eth0/eth1正在工作而tun0不是。

以防萬一,這是我的 OpenVPN 配置(一個簡單的點對點配置):

;SERVER
dev tun
ifconfig 192.168.99.1 192.168.99.2
secret /etc/openvpn/static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

;CLIENT
dev tun
remote XXXXXXXXXXXX
resolv-retry infinite
local 192.168.3.101
lport 0
ifconfig 192.168.99.2 192.168.99.1
secret /etc/openvpn/static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

注意:我知道 VPN IP 的約定是10.*,但我不顧一切地更改192.168.*為具有與其他 2 個介面類似的配置。

這一切的原因是解決這個問題的想法:https ://github.com/Ysurac/openmptcprouter/issues/670#issuecomment-533816813

您正在嘗試實現基於路由隧道模式的解決方案,但您的問題描述在我看來非常適合橋接分接模式。

OpenVPN 不僅可以隧道 IP 數據包。它還可以對整個乙太網數據包進行隧道傳輸。簡而言之,您可以將“mode tun”替換​​為“mode tap”,並刪除 OpenVPN 配置中的所有 IP 地址分配。同時刪除所有非預設路由規則。然後,在您的作業系統的幫助下,您可以在 eth1 和 tap 介面之間架起一座橋樑。

在 Debian (/etc/network/interfaces) 中:

iface eth1 inet manual

auto br0
iface br0 inet manual
   bridge_ports    eth1
   bridge_stp      off
   bridge_fd       0

接下來,我們需要指示 OpenVPN 在啟動後將 tapX 添加到 br0(這將轉到 OpenVPN 配置):

script-security 2
up up.sh

為什麼需要腳本安全性,請參閱https://community.openvpn.net/openvpn/wiki/OpenVPNBridging

up.sh 腳本:

#!/bin/sh
bridge=br0
brctl addif "$bridge" "$1"
ip link set "$1" up

它使用 bridge-utils brctl,因為這個配置是在 debian 7 上完成的。現代系統應該使用現代 iproute2 套件中的 ip 實用程序,而不是過時的 bridge-utils、iputils 等;我將把它留作家庭作業,如何使用 ip 向網橋添加介面,這並不難。

你看,我什至沒有配置任何 IP 地址。這是因為我的 OpenVPN 設備只會將乙太網數據包從物理介面橋接到虛擬介面並返回。在 OSI 網路模型中,這算作第 2 層橋接,即好像您有一個乙太網交換機。

執行 OpenVPN 的遠端系統(“CLIENT”)將具有其分接頭介面,就好像它被插入到“SERVER”的 eth1 被插入的同一乙太網交換機中一樣:

(LAN) - [switch] ---ethernet-cable--- [eth1 tapX] ---virtual-ethernet-cable--- [tapY]
                                       "switch"         OpenVPN tunnel          remote system

您可以在遠端系統 (“CLIENT”) 上執行 DHCP 客戶端,它應該從 LAN 中的 DHCP 伺服器接收 IP 地址。您也可以在那裡進行橋接,這就像您使用乙太網電纜連接您的遠端站點一樣。想像一下,就像您在一個站點到另一個站點之間執行一條長光路,並將這些網路與它連接起來。

如果你想讓“SERVER”也加入這個網路,你在br0本身上配置IP地址,為此你將“manual”替換為“static”甚至“dhcp”,這根本不會影響它的切換功能。

Linux Netfilter 設置(防火牆)需要特別注意。前段時間有一個 sysctl 變數控制橋接數據包是否通過“filter FORWARD”鏈傳遞,net.bridge.bridge-nf-call-iptables=1。在現代系統上,AFAIK,預設為 0。如果你有它,要麼將它設置為 0(在 /etc/sysctl.conf 中),要麼具有在交換機埠之間傳遞數據包的規則。請參閱 iptables 手冊中的“physdev match”。

請注意,您為系統指定的“伺服器”和“客戶端”名稱純粹是裝飾性的,並不反映它們的協議角色。從 OpenVPN 的角度來看,兩個系統是平等的,因為您將 OpenVPN 配置為“傳統”點對點模式。OpenVPN 中還有專用的“客戶端-伺服器”模式,其中確實有兩個不同的角色,多個客戶端可以連接到單個 OpenVPN 伺服器。我在這裡提出的想法也適用於該模式。

另外,請注意,OpenVPN 沒有始終使用 10.* 的約定。任何成熟的生產級 VPN 解決方案都不會有這樣的約定。您始終使用網路設計所需的網路編號。

UPD:在虛擬機內部測試網橋時,確保虛擬機管理程序允許在 VM 埠使用多個 MAC 地址。在 Hyper-V 中,該功能稱為 MAC Spoofing,應該啟用。

引用自:https://serverfault.com/questions/987999