我已经从 10 升级到 Debian 11。使用 Debian 10 openvpn 工作正常,现在我遇到了这个问题,我可以访问我的 vpn 服务器,但我无法 ping 或访问我的局域网远程,除了 vpn 服务器。这是远程端的防火墙配置
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere multiport dports 2991
ACCEPT udp -- anywhere anywhere multiport dports 2991
ACCEPT tcp -- anywhere anywhere tcp dpt:http-alt
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:cisco-sccp
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:2004
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:3000
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:37890
ACCEPT tcp -- anywhere anywhere tcp dpt:2124
ACCEPT tcp -- anywhere anywhere tcp dpt:5861
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:telnet
ACCEPT tcp -- anywhere anywhere tcp dpts:5900:5910
ACCEPT icmp -- anywhere anywhere icmp echo-reply
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT all -- anywhere anywhere
LOGGING all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
NFLOG all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp echo-reply
ACCEPT icmp -- anywhere anywhere icmp echo-request
Chain LOGGING (1 references)
target prot opt source destination
NFLOG all -- anywhere anywhere nflog-prefix "[iptables-drop]:" nflog-group 11
DROP all -- anywhere anywhere
root@vpn:/etc/openvpn#
这是 Openvpn 远程端的配置
port 2991
proto tcp
dev tun
ca /etc/openvpn/certs/keys/ca.crt
cert /etc/openvpn/certs/keys/vpn.******.priv.crt
key /etc/openvpn/certs/keys/vpn.******.priv.key
dh /etc/openvpn/dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
push "route 192.168.0.0 255.255.255.0"
client-to-client
keepalive 10 120
tls-auth /etc/openvpn/certs/keys/ta.key 0
data-ciphers-fallback AES-256-CBC
user openvpn
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 7
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
auth-nocache
这是客户端openvpn的配置(防火墙与远程相同,所以我避免发布)
client
dev tun
proto tcp
remote ****** 2991
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
cert /etc/openvpn/certs/keys/vpn.******.priv.crt
key /etc/openvpn/certs/keys/vpn.******.priv.key
dh /etc/openvpn/dh2048.pem
remote-cert-tls server
tls-auth /etc/openvpn/certs/ta.key 1
data-ciphers-fallback AES-256-CBC
auth SHA512
auth-nocache
topology subnet
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
verb 7
我在服务器上发现的唯一错误是这个..
ago 21 00:56:23 vpn ovpn-server[3791]: ******/*****:24545 GET INST BY VIRT: 192.168.0.12 [failed]
192.168.0.12 是 openvpn 服务器 ip,我可以访问它,但是 lan 192.168.0.02/24 中的每个 ip 都被阻止(没有 ping,没有 ssh,什么都没有)。
例如..
$ 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 ---
6 packets transmitted, 0 received, 100% packet loss, time 5133ms
$ ping 192.168.0.12
PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=166 ms
64 bytes from 192.168.0.12: icmp_seq=2 ttl=64 time=164 ms
64 bytes from 192.168.0.12: icmp_seq=3 ttl=64 time=84.9 ms
^C
--- 192.168.0.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 84.924/138.389/166.113/37.814 ms
找到解决方案。在 Debian 11 上,他们有一个坏主意(恕我直言),将经典的 eth0 重命名为 16 字符的长名称!这使得无法在 iptables 或桥接工具中使用接口(允许的最大网络接口长度为 15),否则会收到此错误“接口名称超过 15 个字符”所以我的 nat 转到一个不存在的设备(eth0 消失了)。但幸运的是,有一个简单的解决方案:
当然替换“YO:UR:MA:CA:DD:RES”
重新启动后,我看到旧的好 eth0 名称并且全部恢复工作