Я хочу настроить OpenVpn в pfsense для подключения к частной сети внутри виртуального сервера, я следую некоторым инструкциям и много читаю, и у меня такая же проблема, как и я:
Теперь проблема в клиенте - это рукопожатие, но я думаю, что проблема в брандмауэре pfsense, правило для управления портом vpn - 0/0, даже если я пытаюсь подключиться.
Если я просканирую порт с помощью nmap, я возьму это:
1194/tcp filtered openvpn
1194/udp open|filtered openvpn
Любые идеи?
Ну, openvpn.log покажет мне это
Dec 21 13:50:55 Firewall openvpn[6124]: OpenVPN 2.3.11 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jul 19 2016
Dec 21 13:50:55 Firewall openvpn[6124]: library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
Dec 21 13:50:55 Firewall openvpn[6222]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Dec 21 13:50:55 Firewall openvpn[6222]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 21 13:50:55 Firewall openvpn[6222]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Dec 21 13:50:55 Firewall openvpn[6222]: TUN/TAP device ovpns1 exists previously, keep at program end
Dec 21 13:50:55 Firewall openvpn[6222]: TUN/TAP device /dev/tun1 opened
Dec 21 13:50:55 Firewall openvpn[6222]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
Dec 21 13:50:55 Firewall openvpn[6222]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Dec 21 13:50:55 Firewall openvpn[6222]: /sbin/ifconfig ovpns1 10.0.0.1 10.0.0.2 mtu 1500 netmask 255.255.255.0 up
Dec 21 13:50:55 Firewall openvpn[6222]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1557 10.0.0.1 255.255.255.0 init
Dec 21 13:50:55 Firewall openvpn[6222]: UDPv4 link local (bound): [AF_INET]XX.XXX.XXX.XXX:1194
Dec 21 13:50:55 Firewall openvpn[6222]: UDPv4 link remote: [undef]
Dec 21 13:50:55 Firewall openvpn[6222]: Initialization Sequence Completed
Вы видите предупреждение, но я не понимаю, что такое, другой журнал, файл filter.log, показывает много информации, но я grep по vpn, 1194, и я ничего не получаю, что именно я ищу? извините за это, но это моя первая попытка с vpn, и я не уверен, что делать.
После попытки:
tcpdump -n -e -ttt -i pflog0
Я ничего не получаю через 15 минут, пробуя клиент openvpn:
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Но если сделать сканирование портов с помощью nmap, я возьму это:
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
00:00:00.000000 rule 5..16777216/0(match): block in on vmx0: IP8 bad-len 0
00:00:00.002001 rule 5..16777216/0(match): block in on vmx0: IP1 bad-len 0
00:01:09.092480 rule 5..16777216/0(match): block in on vmx0: IP10 bad-len 0
00:00:00.001754 rule 5..16777216/0(match): block in on vmx0: IP12 bad-len 0
8 packets captured
8 packets received by filter
0 packets dropped by kernel
Брандмауэр не получает никаких пакетов на порт 1194, где слушает сервер openvpn, как-нибудь проверить порт? или как-нибудь отправить пакет на порт 1194 и посмотреть, работает ли?
Ну, я проверил конфигурацию, и думаю, что все в порядке, это:
dev ovpns1
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local XXX.XXX.XXX.XXX #public ip
tls-server
server 10.0.0.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server1" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'Server_CRT' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 2
push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway def1"
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1.tls-auth 0
persist-remote-ip
float
topology subnet
Если выполнить sockstat | grep 1194 работает как работает:
root openvpn 84783 6 udp4 XXX.XXX.XXX.XXX:1194 *:*
Думаю, мы продолжаем, теперь в журнале openvpn, когда я пытаюсь подключить клиента, я вижу это:
Jan 14 22:30:16 Firewall openvpn[73374]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Jan 14 22:30:16 Firewall openvpn[73374]: MANAGEMENT: CMD 'status 2'
Jan 14 22:30:17 Firewall openvpn[73374]: MULTI: REAP range 176 -> 192
Jan 14 22:30:17 Firewall openvpn[73374]: MANAGEMENT: CMD 'quit'
Jan 14 22:30:17 Firewall openvpn[73374]: MANAGEMENT: Client disconnected
А в клиенте вижу вот такое:
Jan 14 22:31:14: UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Jan 14 22:32:14: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 14 22:32:14: TLS Error: TLS handshake failed
Jan 14 22:32:14: SIGUSR1[soft,tls-error] received, process restarting
Jan 14 22:32:15: UDPv4 link local (bound): [undef]
Jan 14 22:32:15: UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Лучший способ узнать, является ли это брандмауэр, - посмотреть его журнал.
Изменить: я имел в виду, что вы должны посмотреть журнал pf. pf должен регистрировать любые отклонения, которые он делает, и это может подтвердить или опровергнуть ваше подозрение, что это брандмауэр. Я не использовал pfsense, но просмотр журнала pf во FreeBSD выглядел бы так: tcpdump -n -e -ttt -r / var / log / pflog или вы можете смотреть его в реальном времени с помощью tcpdump -n -e -ttt -i pflog0 .
После разговора с моим серверным провайдером и проверки его сети все работает нормально, они использовали брандмауэр перед моим сервером, спасибо всем за помощь!