
嘿夥計們,這可能只是我錯過的一些愚蠢的事情,但我在設置用於我的 VPN 的網路命名空間時遇到了麻煩。奇怪的是,這個腳本/設定正在運行,但在過去幾週內突然停止了。
我的伺服器上有一個帶有靜態 IP 集的乙太網路接口,我想將其用於所有正常流量。然後,我使用網橋作為其主設備,並透過虛擬乙太網路將 VPN 連接到同一橋。由於某種原因,我的 VPN 介面可以成功回覆 ARP 請求,但似乎無法 ping 我的網關,因此無法連接到互聯網)。我覺得這可能是路由問題,但我似乎無法弄清楚。
網路計劃
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: false
addresses:
- 192.168.0.54/24
bridges:
br0:
interfaces:
- enp3s0
routes:
- to: default
via: 192.168.0.1
- to: 192.168.0.0/24
nameservers:
addresses: [1.1.1.1, 8.8.8.8]
設定 VPN 網路命名空間的腳本:
ip link add vpn0 type veth peer name vpn1
ip link set dev vpn0 master br0
ip netns add vpn
ip link set vpn1 netns vpn
ip link set dev vpn0 promisc on
ip link set vpn0 up
ip netns exec vpn ip link set lo up
ip netns exec vpn ip link set vpn1 up
ip netns exec vpn ip address add 192.168.0.53/24 dev vpn1
ip netns exec vpn ip route add default via 192.168.0.1 dev vpn1
VPN 位址/路由
root@sam-server:~# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
5: vpn1@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 06:9e:19:5a:a4:a5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.0.53/24 scope global vpn1
valid_lft forever preferred_lft forever
inet6 fe80::49e:19ff:fe5a:a4a5/64 scope link
valid_lft forever preferred_lft forever
root@sam-server:~# ip route
default via 192.168.0.1 dev vpn1
192.168.0.0/24 dev vpn1 proto kernel scope link src 192.168.0.53
普通地址/路線
root@sam-server:~# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
link/ether 88:d7:f6:78:91:72 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.54/24 brd 192.168.0.255 scope global enp3s0
valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e6:3d:5a:ce:a9:fb brd ff:ff:ff:ff:ff:ff
inet6 fe80::e43d:5aff:fece:a9fb/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:19:80:3c:94 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
6: vpn0@if5: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
link/ether 66:2c:f9:35:3d:0e brd ff:ff:ff:ff:ff:ff link-netns vpn
inet6 fe80::642c:f9ff:fe35:3d0e/64 scope link
valid_lft forever preferred_lft forever
root@sam-server:~# ip route
default via 192.168.0.1 dev br0 proto static onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev br0 proto static scope link
192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.54
從 VPN 名稱空間執行 Ping 操作(arp好像解決了,但是無法ping通網關)
root@sam-server:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3066ms
root@sam-server:~# ping 192.168.0.54
PING 192.168.0.54 (192.168.0.54) 56(84) bytes of data.
64 bytes from 192.168.0.54: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 192.168.0.54: icmp_seq=2 ttl=64 time=0.052 ms
64 bytes from 192.168.0.54: icmp_seq=3 ttl=64 time=0.052 ms
^C
--- 192.168.0.54 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.037/0.047/0.052/0.007 ms
root@sam-server:~# arp
Address HWtype HWaddress Flags Mask Iface
192.168.0.1 ether b0:95:75:8c:fe:80 C vpn1
192.168.0.54 ether e6:3d:5a:ce:a9:fb C vpn1
root@sam-server:~#
希望這是足夠的信息,如果需要,我可以發布更多信息。
答案1
嘗試按照此處的建議添加介面的 mac 位址Ubuntu 22.04 與 netplan 橋接不起作用
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: false
addresses:
- 192.168.0.54/24
bridges:
br0:
interfaces:
- enp3s0
routes:
- to: default
via: 192.168.0.1
- to: 192.168.0.0/24
nameservers:
addresses: [1.1.1.1, 8.8.8.8]
macaddress: 88:d7:f6:78:91:72
答案2
我已經找到我的問題的答案了。事實證明事情非常簡單。基本上,兩週前我已經安裝了Docker
.我不知道這一點,但 Docker 搞亂了iptables
.
root@sam-server:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP) <----------- PROBLEM IS HERE
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
由於 Docker 自動設定FORWARD
我DROP
的資料包沒有轉送到介面。我認為ARP
它可以工作,因為它不受 iptables 的影響。
修復方法只是重置策略以接受:iptables --policy FORWARD ACCCEPT