Creé un contenedor Ubuntu 16.04 lxd y configuré el cliente Stunnel, Tinyproxy y OpenVPN en él.
El objetivo es conectarse a Tinyproxy a través de Stunnel y obligar a Tinyproxy a utilizar la interfaz de OpenVPN para conexiones salientes.
Stunnel -> Tinyproxy funciona bien: las páginas en el navegador se cargan como se esperaba; sin embargo, tan pronto como inicio el servicio OpenVPN, Stunnel en el lado del cliente falla con el tiempo de espera y el navegador sigue esperando respuesta.
Dado que Tinyproxy 1.8.3 (la versión más nueva para ubuntu 16.04) no admite una opción para vincular conexiones salientes a una interfaz específica, tuve que dejar que OpenVPN agregara las rutas predeterminadas a través de su tun0interfaz.
El cliente OpenVPN funciona según lo esperado: todos los paquetes del contenedor pasan por VPN. El host con el contenedor es un host remoto con IP pública. DNAT está configurado en el contenedor.
Realmente no estoy familiarizado con el enrutamiento interno, solo pude configurar SNAT/DNAT y filtrar con iptables. Por tanto, no puedo entender la raíz del problema.
Estos son los parámetros más importantes del medio ambiente:
ifconfig
$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:16:3e:5f:46:ba
inet addr:10.227.60.197 Bcast:10.227.60.255 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:fe5f:46ba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16291 errors:0 dropped:0 overruns:0 frame:0
TX packets:15632 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5044056 (5.0 MB) TX bytes:4171187 (4.1 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:2446 errors:0 dropped:0 overruns:0 frame:0
TX packets:2446 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:2483699 (2.4 MB) TX bytes:2483699 (2.4 MB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.3 P-t-P:10.8.0.3 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:252 (252.0 B) TX bytes:252 (252.0 B)
ruta
$ route -v -e
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
default 10.227.60.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 * 255.255.255.0 U 0 0 0 tun0
10.227.60.0 * 255.255.255.0 U 0 0 0 eth0
128.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
<vpn server IP> 10.227.60.1 255.255.255.255 UGH 0 0 0 eth0
stunnel.cong
...
accept = 10.227.60.197:8081
connect = 127.0.0.1:8080
...
tinyproxy.conf
...
Port 8080
Listen 127.0.0.1
...
vpnclient.conf
dev tun
proto udp
remote <vpn server ip> 1195
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
key-direction 1
verb 3
#route-nopull
...
iptablesestán vacíos.
Respuesta1
El problema estaba en la configuración de la tabla de enrutamiento.
Noté que al eliminar rutas agregadas por OpenVPN:
Destination Gateway Genmask Flags MSS Window irtt Iface
default 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
e intentando realizar ping 8.8.8.8 -I tun0y monitorear paquetes simultáneamente con tcpdump -nn icmp, responder las solicitudes icmp realmente llegan eth0pero no continúa más. Después de investigar un poco, descubrí que también debería haber una tabla de enrutamiento separada tun0y reglas, ya que el servidor tiene 2 interfaces.
Finalmente, actualicé tinyproxy a la última versión para poder especificar la interfaz de salida y deshabilité OpenVPN para impulsar rutas predeterminadas como la que eliminé anteriormente.
Luego, agregué la tabla a /etc/iproute2/rt_tables:
...
12 vpn
Se agregaron rutas a esta tabla y reglas:
ip route add 10.8.0.0/24 dev tun0 src 10.8.0.3 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn
ip rule add from 10.8.0.3/32 table vpn
ip rule add to 10.8.0.3/32 table vpn
Después de eso, todo empezó a funcionar como se esperaba.