OpenVPN 桥接问题(无法从客户端 ping 服务器)

OpenVPN 桥接问题(无法从客户端 ping 服务器)

这是我的问题:

我正在尝试在家庭网络上设置 OpenVPN,以便在外出时用作来自不安全网络的流量的安全隧道,并访问我家 LAN 上的机器。我的 LAN 上的 OpenVPN 服务器是一台运行 Arch Linux 的机器,与我的防火墙分开,防火墙目前运行的是 M0n0wall。我想要使用的客户端是一台笔记本电脑,也运行 Arch Linux。

我正在尝试使用桥接模式,这将为我的笔记本电脑提供家庭局域网上的地址,使其表现得就像实际连接到我的局域网一样。

目前,我正尝试通过将笔记本电脑放在网关后面来测试配置,因此它位于与我的主 LAN 子网不同的子网上(我这样做是因为我无法轻松访问外部网络,而且我宁愿在这里调试问题,也不愿等到我到几英里外的酒店)。

相关参数:

Main LAN subnet:  192.168.77.0/24
VPN server IP:    192.168.77.203
Gateway:          192.168.77.2

Testing subnet:                192.168.0.0/24
Laptop (client) IP:            192.168.0.100
Testing gateway (to main LAN): 192.168.0.1

这是我的服务器的配置文件:

port 1194
proto udp
dev tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/caliborn.crt
key /etc/openvpn/caliborn.key  # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server-bridge 192.168.77.203 255.255.255.0 192.168.77.9 192.168.77.19
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 # This file is secret
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log         /etc/openvpn/openvpn.log
verb 4

以下是客户端的配置:

client
dev tap0
proto udp
remote 192.168.77.203 1194
resolv-retry infinite
nobind
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
ca /etc/openvpn/ca.crt
cert /etc/openvpn/rama.crt
key /etc/openvpn/rama.key
ns-cert-type server
tls-auth ta.key 1
comp-lzo
verb 4

我使用来自的 bridge-start 脚本http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html在启动 VPN 之前在服务器上设置网桥。

当 VPN 未连接时,我可以从客户端 (192.168.0.100) 顺利 ping 服务器 (192.168.77.203),但一旦连接 VPN,客户端的所有连接都会丢失。VPN 似乎已连接到服务器,但我甚至无法 ping 服务器!

以下是 VPN 连接时客户端上的路由输出:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    202    0        0 enp0s25
192.168.0.0     *               255.255.255.0   U     202    0        0 enp0s25
192.168.77.0    *               255.255.255.0   U     0      0        0 tap0

客户端的ip route结果如下:

default via 192.168.0.1 dev enp0s25  metric 202 
192.168.0.0/24 dev enp0s25  proto kernel  scope link  src 192.168.0.100  metric 202 
192.168.77.0/24 dev tap0  proto kernel  scope link  src 192.168.77.9 

连接时,客户端上的 ip addr 输出:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    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: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast     state UP qlen 1000
    link/ether 00:1c:25:93:93:50 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.100/24 brd 192.168.0.255 scope global enp0s25
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:25ff:fe93:9350/64 scope link
       valid_lft forever preferred_lft forever
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:21:5c:08:7d:37 brd ff:ff:ff:ff:ff:ff
17: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 8a:f4:df:21:a6:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.77.9/24 brd 192.168.77.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::88f4:dfff:fe21:a62d/64 scope link
       valid_lft forever preferred_lft forever                                           

当 VPN 处于启动状态时,服务器上 ip addr 的输出如下:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    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,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
    link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
       valid_lft forever preferred_lft forever
3: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 100
    link/ether 86:50:bb:c1:46:91 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::8450:bbff:fec1:4691/64 scope link
       valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.77.203/24 brd 192.168.77.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
       valid_lft forever preferred_lft forever

因此,看起来发往主 LAN 子网的数据包应该通过隧道,但是当我在客户端上运行 tcpdump -i tap0 并尝试 ping 服务器时,我看到的只是 ARP 请求,没有响应。我想我至少可以 ping 我所连接的服务器。

还有一件可能相关的事情:在客户端的日志中,我看到以下内容:

Thu Jul 11 20:54:18 2013 us=872367 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul 11 20:54:18 2013 us=872423 OPTIONS IMPORT: route-related options modified
Thu Jul 11 20:54:18 2013 us=872480 WARNING: --remote address [192.168.77.203] conflicts with --ifconfig subnet     [192.168.77.9, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this   warning with --ifconfig-nowarn)
Thu Jul 11 20:54:18 2013 us=877646 TUN/TAP device tap0 opened
Thu Jul 11 20:54:18 2013 us=877701 TUN/TAP TX queue length set to 100
Thu Jul 11 20:54:18 2013 us=877726 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 11 20:54:18 2013 us=877768 /usr/bin/ip link set dev tap0 up mtu 1500
Thu Jul 11 20:54:18 2013 us=878607 /usr/bin/ip addr add dev tap0 192.168.77.9/24 broadcast 192.168.77.255
Thu Jul 11 20:54:18 2013 us=880894 Initialization Sequence Completed
Thu Jul 11 20:56:18 2013 us=649132 [caliborn] Inactivity timeout (--ping-restart), restarting
Thu Jul 11 20:56:18 2013 us=649823 TCP/UDP: Closing socket
Thu Jul 11 20:56:18 2013 us=649917 SIGUSR1[soft,ping-restart] received, process restarting
Thu Jul 11 20:56:18 2013 us=649966 Restart pause, 2 second(s)
Thu Jul 11 20:56:20 2013 us=650168 Re-using SSL/TLS context
Thu Jul 11 20:56:20 2013 us=650308 LZO compression initialized
Thu Jul 11 20:56:20 2013 us=651988 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Jul 11 20:56:20 2013 us=652071 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 11 20:56:20 2013 us=652124 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Jul 11 20:56:20 2013 us=652192 Local Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,  comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Thu Jul 11 20:56:20 2013 us=652228 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,    proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Thu Jul 11 20:56:20 2013 us=652285 Local Options hash (VER=V4): '13a273ba'
Thu Jul 11 20:56:20 2013 us=652335 Expected Remote Options hash (VER=V4): '360696c5'
Thu Jul 11 20:56:20 2013 us=652377 UDPv4 link local: [undef]
Thu Jul 11 20:56:20 2013 us=652420 UDPv4 link remote: [AF_INET]192.168.77.203:1194
Thu Jul 11 20:57:20 2013 us=211669 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your    network connectivity)
Thu Jul 11 20:57:20 2013 us=211761 TLS Error: TLS handshake failed
Thu Jul 11 20:57:20 2013 us=211938 TCP/UDP: Closing socket
Thu Jul 11 20:57:20 2013 us=212012 SIGUSR1[soft,tls-error] received, process restarting

因此,除了子网冲突错误之外,客户端似乎还超时并每分钟重新连接一次。似乎连接到 VPN 会停止客户端与网络上任何其他主机之间的任何流量,并且 VPN 因此超时后可以重新连接并重新开始整个过程​​。

我很乐意向任何认为他们可能知道问题所在的人来说提供任何额外的信息。

相关内容