Назад | Перейти на главную страницу

Как диагностировать / исправить настройку OpenVPN, которая работает изнутри LAN, но не работает со стороны WAN маршрутизатора

Фирма, в которой я работаю, решила перейти на OpenVPN, чтобы заменить интенсивное использование ssh ( Правильный VPN для замены интенсивного использования ssh )

Я попытался настроить OpenVPN для мостовых подключений. Я могу подключаться через машины в той же сети, что и VPN-сервер. К сожалению, я не могу подключиться к VPN-серверу из-за пределов локальной сети; Соединения, исходящие из порта WAN, завершаются ошибкой. WSAETIMEDOUT сообщение об ошибке.

Я перенаправляю порт 1194 на моем маршрутизаторе (как для TCP, так и для UDP) на свой сервер OpenVPN на порт 1194.

Могу ли я использовать какой-либо инструмент (например, Netcat) и т. Д., Чтобы изолировать проблему и устранить неполадки в моей настройке?

Детали конфигурации

Ubuntu 10.04 LTS OpenVPN "Сервер" Частный LAN 192.168.10.0/24

Клиенты: в основном машины с Windows XP / Vista / Windows 7.

/ и т.д. / сеть / интерфейсы

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
    address 192.168.10.95
    network 192.168.10.0
    netmask 255.255.255.0
    broadcast 192.168.10.255
    gateway 192.168.10.1
    bridge_ports eth0
    bridge_fd 9
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off

auto eth0
iface eth0 inet dhcp

/etc/openvpn/server.conf

port 1194
dev tap0
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server-bridge 192.168.10.95 255.255.255.0 192.168.10.50 192.168.10.80
tls-auth ta.key 0
user nobody
group nogroup

client-to-client
duplicate-cn
keepalive 10 120

cipher BF-CBC        # Blowfish (default)
comp-lzo

persist-key
persist-tun

status openvpn-status.log
verb 6
mute 20

up.sh #! / bin / sh

BR=$1
DEV=$2
MTU=$3
/sbin/ifconfig $DEV mtu $MTU promisc up
/usr/sbin/brctl addif $BR $DEV

down.sh #! / bin / sh

BR=$1
DEV=$2

/usr/sbin/brctl delif $BR $DEV
/sbin/ifconfig $DEV down

client.ovpn

client
dev tap
remote 192.168.10.184:1194
ca ca.crt
cert maven-lunch.crt
key maven-lunch.key
tls-auth ta.key 1

ping 10
comp-lzo
verb 6
mute 10

** редактировать 20.09.2010, 18:00 EDT (@Zoredache) **

Я использую WAN-адрес (в данном случае 10.1.2.129).

Я вижу попытки подключения от моего тестового клиента (10.1.10.112)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:52:23.256396 IP 10.1.10.112.1638 > 192.168.10.184.1194: tcp 0
17:52:23.256415 IP 10.1.10.112.1638 > 192.168.10.184.1194: tcp 0

Просмотр системного журнала показывает, что соединение с отключенным тестовым клиентом в локальной сети отсутствует:

хвост -f / var / журнал / системный журнал

Sep 20 16:40:07 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 TUN WRITE [92]
Sep 20 16:40:07 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 TCPv4_SERVER WRITE [133] to [AF_INET]192.168.10.189:1754: P_DATA_V1 kid=0 DATA len=132
Sep 20 16:40:07 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 TCPv4_SERVER WRITE [181] to [AF_INET]192.168.10.189:1754: P_DATA_V1 kid=0 DATA len=180
Sep 20 16:40:08 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 TCPv4_SERVER READ [133] from [AF_INET]192.168.10.189:1754: P_DATA_V1 kid=0 DATA len=132
Sep 20 16:40:08 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 TUN WRITE [92]
Sep 20 16:40:08 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 TCPv4_SERVER WRITE [133] to [AF_INET]192.168.10.189:1754: P_DATA_V1 kid=0 DATA len=132
Sep 20 16:40:08 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 Connection reset, restarting [-1]
Sep 20 16:40:08 MavenVPNBox ovpn-server[1369]: maven-lunch/192.168.10.189:1754 SIGUSR1[soft,connection-reset] received, client-instance restarting
Sep 20 16:40:08 MavenVPNBox ovpn-server[1369]: TCP/UDP: Closing socket

Вы изменили свой client.ovpn использовать адрес WAN вместо 192.168.10.184 право?

Во всяком случае, что касается тестирования. Почему бы на вашем сервере просто не сделать tcpdump для udp / 1194 tcpdump -qni any port 1194. и посмотрите, действительно ли какие-либо попытки подключения попадают на сервер извне. В противном случае что-то не так с вашим брандмауэром или настройками NAT на вашем пограничном устройстве.

Также проверьте свой / var / log / syslog. Обычно записи журнала openvpn появляются там, когда клиент пытается подключиться.