Мостовые проблемы OpenVPN (не удается пропинговать сервер с клиента)

Question

Вот моя проблема:

Я пытаюсь настроить OpenVPN в своей домашней сети, использовать его в качестве безопасного туннеля для трафика из незащищенных сетей, когда он находится вне дома, а также для доступа к машинам в моей домашней локальной сети. Сервер OpenVPN в моей локальной сети - это компьютер под управлением Arch Linux, который отделен от моего брандмауэра, который в настоящее время работает под управлением M0n0wall. Клиент, который я хотел бы использовать, - это ноутбук, также работающий под управлением Arch Linux.

Я пытаюсь использовать режим моста, который даст моему ноутбуку адрес в моей домашней локальной сети, позволяя ему работать так же, как он был фактически подключен к моей локальной сети.

В настоящее время я пытаюсь проверить конфигурацию, поместив свой ноутбук за шлюз, чтобы он находился в отдельной подсети от моей основной подсети локальной сети (я делаю это, потому что у меня нет свободного доступа к внешней сети, и я ' Я предпочитаю устранять проблемы здесь, чем ждать, пока я не окажусь в отеле за несколько миль).

Соответствующие параметры:

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

Я использую скрипт запуска моста из http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html, чтобы настроить мост на сервере до запуска VPN.

Когда VPN не подключена, я могу нормально пропинговать сервер (192.168.77.203) с клиента (192.168.0.100), но как только я подключаю VPN, я теряю все подключения от клиента. VPN, кажется, подключена к серверу, но я даже не могу пропинговать сервер!

Вот вывод маршрута на клиенте при подключении 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

А вот вывод ip addr на сервер, когда VPN работает:

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

Таким образом, похоже, что пакеты, адресованные основной подсети ЛВС, должны проходить через туннель, но когда я запускаю tcpdump -i tap0 на клиенте при попытке пропинговать сервер, все, что я вижу, - это запросы ARP, без ответов. Я думаю, что я, по крайней мере, смогу пропинговать сервер, к которому я подключен.

Еще одна вещь, которая может быть полезной: в журнале клиента я вижу следующее:

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 он может переподключиться и начать весь процесс заново.

Я буду рад предоставить любую дополнительную информацию всем, кто думает, что они могут знать, в чем проблема.

Мостовые проблемы OpenVPN (не удается пропинговать сервер с клиента)

0

Знаете кого-то, кто может ответить? Поделитесь ссылкой на этот вопрос по почте, через Твиттер или Facebook.

Похожие