Одно из мест, из которых я работаю, - это блокирование всего трафика для "общеизвестных" служб VPN, включая службу VPN, которую я использую.
Теперь я хотел бы "перенаправить" трафик openVPN через / через / через мой собственный VPS (IP-адрес которого не заблокирован) на мой VPN-сервис - и обратно. Вот так:
|me| <-UDP-> |my VPS| <-UDP-> |VPN service| так что виртуальное / логическое соединение, подобное этому, инициируется: |me| <-UDP-> |VPN service| ,
У меня есть следующие правила iptables на работе (196.196.yyy.yyy - это IP-адрес сервера моего провайдера VPN):
iptables -t nat -A PREROUTING -p udp -i venet0:0 --dport 1194 -j DNAT --to-destination 196.196.yyy.yyy:1194
iptables -A FORWARD -p udp -d 196.196.yyy.yyy --dport 1194 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -i venet0:0 --dport 443 -j DNAT --to-destination 196.196.yyy.yyy:443
iptables -A FORWARD -p tcp -d 196.196.yyy.yyy --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Тем не менее, openvpn не может установить соединение (50.3.xxx.xxx - это IP-адрес моего VPS):
$ sudo /some/dir/sbin/openvpn --config /some/dir/hoppingvpntcp.ovpn --verb 6
(...)
Fri Sep 28 14:48:57 2018 us=785094 Attempting to establish TCP connection with [AF_INET]50.3.xxx.xxx:443 [nonblock]
Fri Sep 28 14:48:58 2018 us=785837 TCP connection established with [AF_INET]50.3.xxx.xxx:443
Fri Sep 28 14:48:58 2018 us=785887 TCP_CLIENT link local: (not bound)
Fri Sep 28 14:48:58 2018 us=785908 TCP_CLIENT link remote: [AF_INET]50.3.xxx.xxx:443
Fri Sep 28 14:48:58 2018 us=786112 TCP_CLIENT WRITE [86] to [AF_INET]50.3.xxx.xxx:443: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Fri Sep 28 14:48:58 2018 us=814033 Connection reset, restarting [0]
Fri Sep 28 14:48:58 2018 us=814157 TCP/UDP: Closing socket
Fri Sep 28 14:48:58 2018 us=814272 SIGUSR1[soft,connection-reset] received, process restarting
Fri Sep 28 14:48:58 2018 us=814373 Restart pause, 5 second(s)
^CFri Sep 28 14:49:01 2018 us=543743 SIGINT[hard,init_instance] received, process exiting
$
(полная вставка здесь).
Подключение напрямую (из другого места, конечно, но вышеизложенное также проверено из открытого местоположения) работает, поэтому внутренняя работа конфига и сети на обеих конечных точках, кажется, в порядке.