Tengo un servidor privado virtual, que me gustaría ejecutar un servidor web mientras mi servidor está conectado a un servicio VPN
Cuando la conexión VPN a mi proveedor no está activa, puedo hacer lo que quiera con este servidor, ssh, scp, http, etc.
Una vez que openvpn se está ejecutando y conectado al servicio VPN del proveedor, no se puede acceder al servidor de ninguna manera y, por supuesto, por una buena razón.
La imagen es algo como esto:
My VPS ------------
+----------------+ / \
| | / Internet / 101.11.12.13
| 50.1.2.3|-----------------\ cloud /----<--- me@myhome
| | / \
| 10.80.70.60| / \
+----------------+ \ \
: \_____________/
: :
: :
: :
: :
+------------------+ :
| 10.80.70.61 | :
| \ | :
| \ | :
| 175.41.42.43:1197|..............:
| 175.41.42.43:yy|
| ..... |
| 175.41.42.43:xx|
+------------------+
Legend
------ Line No VPN connection present
...... Line VPN connection established
Cosas para aclarar:
- Todas las direcciones IP y números de puerto arriba y abajo son ficticios.
- Las líneas con los números de puerto xx, yy y cualquier cosa intermedia son mi suposición, no es algo que sepa con certeza.
- Configuré un trabajo cron que se ejecuta cada minuto haciendo ping a otro VPS mío, ejecutando apache2 En los registros de apache2, puedo ver que la dirección IP de origen cambia de 50.1.2.3 a 175.41.42.43, cuando VPN está activa, por lo que VPN funciona bien
Los registros de OpenVPN muestran estos:
UDPv4 link remote: [AF_INET]175.41.42.43:1197
[ProviderName] Peer Connection Initiated with [AF_INET]175.41.42.43:1197
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.80.70.60 peer 10.80.70.61
En este punto, me gustaría poder hacer ssh desde myhome
hasta My VPS
en la imagen, mientras la VPN está activa y usando PuTTY.
En el pasado, en uno de mis lugares de trabajo, me dieron una secuencia muy extraña para ssh en un servidor extremadamente seguro que tenía tres @
signos en la cadena. Entonces, estaba saltando de una caja a otra como imagino, pero dado que las cajas de salto ejecutaban alguna versión del sistema operativo Windows y una aplicación propietaria en ellas, no había visibilidad para mí para ver lo que estaba sucediendo en secreto. Entonces no le presté mucha atención. Ahora estoy empezando a darme cuenta, puedo estar en la misma situación o en una similar.
Usando las direcciones IP y los puertos en el diagrama y / o el fragmento de registro, ¿alguien puede decirme cómo puedo atravesar este túnel y acceder a mi servidor?
fuente
Esto puede ser un poco tarde, pero ...
El problema es que OpenVPN cambia la puerta de enlace predeterminada, y eso interrumpe su conexión SSH actual a menos que configure las rutas apropiadas antes de iniciar OpenVPN.
Lo que sigue funciona para mí. Utiliza iptables e ip (iproute2). A continuación, se supone que la interfaz de puerta de enlace predeterminada antes de iniciar OpenVPN es "eth0". La idea es garantizar que cuando se realiza una conexión a eth0, incluso si eth0 ya no es la interfaz de puerta de enlace predeterminada, los paquetes de respuesta para la conexión vuelven a eth0 nuevamente.
Puede usar el mismo número para la marca de conexión, la marca de firewall y la tabla de enrutamiento. Usé números distintos para hacer que las diferencias entre ellos fueran más aparentes.
===
ACTUALIZAR:
Lo anterior funciona bien para mí en Debian Jessie. Pero en un sistema Wheezy anterior, acabo de descubrir que necesito agregar "via" a la entrada de la tabla de enrutamiento:
Allí "12.345.67.89" debe ser la puerta de enlace no VPN original.
fuente